Thats the same thing as saying “You know that iPhone app won’t work in IE.” It’s a completely obvious statement.

The web is a platform just like iOS and Android are both platforms (obviously). I (and many others) consider the modern web to be a subset platform to the web.

It makes sense that if you’re creating a web app for the web then you need to support IE which is a major player on that platform. However if you are creating a web app for the modern web then you don’t even need to consider that platform because IE9 is still not a serious player and won’t be for quite some time.

Developers who create native applications for iOS and Android are not bound by what IE can support. They are able and expected to use the latest and greatest apis available. If you want your web application to compete with modern native apps then you must write modern web apps which means not even caring how it works in IE.

CAVEAT: You probably work for someone who isn’t as forward leaning as you and can’t make the complete leap of faith. That’s completely understandable. This message is more directed at personal projects that you want to see have explosive growth.

The engaged masses who will swarm your server like locusts from the cloud and push your app over the tipping point are not using IE—they are using a modern web browser. So meet them half way by building ridiculously kick ass web apps with modern apis.

No tags

In javascript conditional expressions are decided by the result of truthy or falsy statements. Here I intend to list all of the falsey values.

A way to test if a value is truthy or falsey is to run it through an if else statement and see which path it takes.

  if (condition) {
    console.log("truthy");
  } else {
    console.log("falsey");
  }

Here are a list of all falsey values. Please let me know if I missed any.

1. undefined
2. false
3. ”
4. 0
5. null
6. NaN

Open your dev console and then click on any of the buttons below to run that value through the above if statement to see whether it’s truthy or falsey.

• undefined
• false
• ”
• 0
• null
• NaN

No tags

I know that this has been documented many places before but I wanted to do it again to better help myself remember. Here are a few deliciously quirky things about javascript.

typeof(null)

There are 2 bottom values in javascript that don’t inherit from the object prototype. They are undefined and null. However when you check the typeof(null); it returns object.

console.log(typeof(null)); // logs object which is wrong

typeof(NaN)

NaN (not a number) is another bottom value in javascript. When you check it’s type in ultra counter-intuitive fashion you get “number.” Nice.

console.log(typeof(NaN)); // logs "number" which is epic

NaN == NaN && NaN !== NaN

When you compare NaN to itself with double equality operators you get false. When you confirm this by making sure NaN is not double equal to itself you get true.

Crockford recommends using the triple equality operator when comparing bottom values.

No tags

On the mysteries of HTML5 <audio>

In attempting to fully grok the potential of HTML5 audio I decided to further explore the API and document the behavior as much as possible. This series of posts will be that documentation. This post relates only to Chrome. I hope it serves you in some way.

I’ve already done a couple projects using the actual audio element but hadn’t actually spent any time messing around with the HTML5 audio API. The API is surprisingly robust and I look forward to hacking it.

Starting at the very beginning you can instantiate an audio object by calling the Audio(); constructor function.

var audioObject = new Audio();
console.log(audioObject);

Open your developer console and see an example here.

You’ll notice at this point the audio object doesn’t have a source. Kinda useless I know. We can fix that with one of two ways.

First we can access the audio object’s src property and change the value to be a path to an audio resource. Like so:

audioObject.src = "music/grace.mp3";
console.log(audioObject);

Open your developer console and see an example here.

Or we can accomplish this by passing in a path to an audio resource at the moment of instantiation. Like so:

var audioObject = new Audio('music.grace.mp3');
console.log(audioObject);

Open your developer console and see an example here.

There it is! If you look in the console you’ll see a pretty complex object. There is quite a bit going on there but right now we’ll just cover a certain property/value pair. Namely the networkState property.

The HTML5 spec describes the networkState as follows: As media elements interact with the network, their current network activity is represented by the networkState attribute. On getting, it must return the current network state of the element, which must be one of the following values:

NETWORK_EMPTY(numeric value 0)
The element has not yet been initialized. All attributes are in their initial states.
NETWORK_IDLE (numeric value 1)
The element's resource selection algorithm is active and has selected a resource, 
but it is not actually using the network at this time.
NETWORK_LOADING (numeric value 2)
The user agent is actively trying to download data.
NETWORK_NO_SOURCE (numeric value 3)
The element's resource selection algorithm is active, but it has not yet found a resource to use.

To start out I’d like to just explore this property a bit. To do that I created some code that creates a new audio object with no source and runs through a couple of the html5 audio api methods to check network state. Let’s explore this in detail.

window.onload = function() {
  // Create a new audio object with no source
  var audioObject = new Audio();
  console.log(audioObject);
  // Check the object's networkstate
  var audioInfo = audioObject.networkState;
  console.log("networkState with no src: " + audioInfo);
  // Give the object a source and again check it's network state
  audioObject.src = "music/grace.mp3";
  console.log("networkState with src: " + audioInfo);
  // Call the object's play method and again check it's network state
  audioObject.play();
  console.log("networkState playing: " + audioInfo);
  // Call the object's pause method and again check it's network state
  audioObject.pause();
  console.log("networkState after pause: " + audioInfo);
  // Get the button and give is a click event listener that logs the object's
  // network state to the console when clicked.
  var networkStateButton = document.getElementById("networkStateButton");
  networkStateButton.addEventListener("click",
          function() { console.log("networkState playing: " + audioInfo); }, 
          false);
}

But before we get there I’d like to point out the first oddity of the evening. If you’ve followed along you might have noticed that if you create the audio object and log it to the console outside of the anonymous function that is being assigned to window.onload then you will see the full object in the console.

If you create the audio object within the window.onload anonymous function and log it to the console you will only see the markup for the actual node. Why is this happening?

Moving on—if we remove the audio object constructor outside of the window.onload and run the script we notice that the first line in the console is:

<audio preload="auto" src="music/grace.mp3"></audio>

How did the console know what the source was when this console.log comes from line 4 and the audio objects source wasn’t assigned until line 9? The expected behavior is that at line 2 there isn’t a source so the element shouldn’t have a src attribute. Much less the actual file path as a value.

To make matters stranger we get the expected behavior if we go to the scripts tab and put breakpoints on lines 4, 7, 10, 13, 15. By the time you press the button to go past the last break point and then look at the console the first line DOES NOT show a src attribute and value. Strange.

Ok, remove those breakpoints and let’s get back to exploring the networkState property.

If you try the above code without passing in a source argument you’ll see that each time it logs to the console a network state code 0. This is telling us “The element has not yet been initialized. All attributes are in their initial states.”

Yet if you look at the audio object in the console you’ll notice that it’s network state code is reading 1. Another oddity.

We can however get our network state console logs to match the audio objects thankfully. When we pass in a source argument at object instantiation time it logs the correct network state code to the console—which is 1. YAY!

If we instantiate the object from within the window.onload anonymous funtion then it logs to the console a series of network state code 3s. It also changes the audio object that it logs out to just the markup of the node which prevents us from being able to check the actual audio object to see it’s network state property.

More soon.

audio