I'm still not sure why a compact, concise, standardized bytecode format isn't being pursued. Perhaps minified, gzipped asm.js encoded JavaScript is as close as we'll ever get.
This is the point I think the author and a lot of people are missing. It's not always about what is the best possible design, instead it is often "what we will get". Politics, ideology, and timing can often come in the way of "the best design".
I would love to use NaCl (I was cheering for it up until recently), but if only Chrome is implementing it then it's about as useful as a screwdriver that doesn't fit any screws.
asm.js is already a stronger candidate because I can use it right now and it will work everywhere. Obviously the browser vendors has to create asm.js specific optimizations for it to be truly great, but that is like fuzzing over the handle, grip and material of the screwdriver. It fits the screws, it gets the job done, it actually works.
What does it matter how great your technology is if it doesn't work? What does it matter if NaCl is ten times faster if I can't actually use it? From what I see, Mozilla isn't very hot on the idea of adopting NaCl, and Microsoft will probably not even touch it in this millennia.
If a client wants me to produce something, I can't use NaCl, because it won't actually run in non-chrome browsers (without installing plugins).
To me it appears that the choice is either asm.js or nothing. NaCl just isn't happening.
You would probably want some sort of layer to abstract away the NaCl API so you can call the equivalents for asm.js, but I don't actually know that asm.js has equivalents.
This is fundamentally not true. We tend to think of "better perf" as not being breaking the web, but that isn't always the case. Imagine a game written using asm.js. Plays beautifully at 30fps on Firefox. Great! And it runs on every browser, right?
Well, if it runs at three FPS on Safari, then as far as the game developer and the player are concerned, no, the game doesn't run on Safari.
I don't recall many websites at the time only being effectively usable for perf reasons in Chrome, but my memory is a bit hazy. Certainly, there were fewer very JavaScript heavy sites, and most of HTML5 hadn't been created yet. That meant there were fewer opportunities to build web apps that required fast JS. Also, Chrome wasn't as fast as it is now.
But, yes, if people were building apps then that said "only in Chrome" then that would imply that to some degree Chrome was breaking the web. Fortunately, in that case, the other browsers caught up quickly and resolved that tension.
Two reasons:
1. Backwards compatibility.
2. We've had such a thing since the 1990's. It's called Java. Nobody likes it and nobody uses it [1], so that's a good enough reason.
[1] Nobody uses Java in the browser, that is. When was the last time you remember seeing a Java applet?
If JavaScript was a plugin it would be just as annoying and useless as an "applet".
Maybe this is why people are terrified of the idea.