The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.
In theory you could use Javascript as that thing, but it wouldn't be very efficient. On the other hand, what you could do is create a compiler that compiles to both bytecode and Javascript, and then give the Javascript to older browsers that don't support bytecode yet.
Shoe horning technologies into roles they weren't intended for could describe the entire scope of why the Web sucks (e.g.: HTML mixing presentation with semantics).
http://mozakai.blogspot.co.at/2013/05/the-elusive-universal-...
Now-a-days that "thing" is "javascript" and it has implementation nuances that depend on browser/runtime environment.
I'm even getting worse startup times for a "cold start" for the same code compiled to native OSX then for starting the same demo as emscripten version, (presumably because the native version first needs to load a lot of DLLs).
I can take PNaCL today and deploy it on alternative stacks, irrespective of the web stack. I can inter-operate cleanly with alternative libraries and environments, I can adopt efficient host platform ABIs, I can run it with a sandbox or without. I could even use it as a generic cross-platform sandboxed in-kernel driver layer.
Moreover, should NaCL/PNaCL be successful, there exists the possibility for optimization on the silicon-level via the introduction of new instruction sets that optimize for in-process sandboxing of untrusted code, much in the same way that trap-and-emulate VMs led to much higher performing silicon-implementations of the same ideas.
Issues of performance can be solved given a well-designed system that applies only as much complexity as is needed, at the level that it is needed. asm.js is a hack inserted at an inappropriate layer of the technology stack; NaCL/PNaCL is a coherent compositionally-sane design that opens the door to later optimizations and significant improvements of the underlying technologies on which it rests.
Writing in a language appropriate to the task is almost always the right tradeoff.
But why would you actually do that as a long-term solution? JavaScript isn't an ISA. It's not hard-coded into anything. You don't have to throw away all the existing JavaScript code to start supporting something else in addition to it. All you would have to do is write code to support whatever bytecode you actually want to use and contribute it to the major browsers.
To me, asm.js looks like a bad kludge -- and a great road ahead, just extend it a little bit over the next decade with the stuff compiler writers will clamor for.
Am I missing something?
Compiling other languages to JavaScript is a tolerable transition mechanism while browsers that don't support something better are still popular, but trying to improve the ability of browsers to interpret compiled-to-JavaScript code from other languages is farcical -- if you're going to update the browser then update it to support something better than JavaScript, not to improve the performance of the horrible legacy transition kludge.
But I'm cynical about the possibility to get a new bytecode standard out, without e.g. MS sabotag... extending it. Half the value of asm.js should be that if there is a working system already in place, the motivations for such shenanigans lessens.
The way to handle Microsoft in a situation like this is to ignore them. Support the same IR on Firefox, Chrome and Safari and then Microsoft can play along or go home. At that point the worst they could do is implement an extended version that allows sites made for all browsers to work with IE but then encourage developers to make sites using Windows-specific features that won't work on other platforms. That's effectively what they tried with Silverlight and you see how far that got them.
http://mozakai.blogspot.com/2011/11/code-size-when-compiling... suggests otherwise in a head-to-head comparison: C code compiled to both a platform-native binary blob and JavaScript, then both gzipped (standard practice for any large JS file on the web).
And if you're talking platform-dependent machine code, that's likely _worse_ on the wire in practice, because unlike a platform-independent representation you can't do edge caching or other sorts of intermediate caches. But maybe you meant a virtual machine (i.e. what people ask for when they want a common bytecode)?
You still need a nontrivial runtime (a la PNaCl) if you're going to provide the sort of sandboxing guarantees for the code people want for code that runs without explicit user opt-in. Or is that a non-goal in your case? In that case, I'd like to understand the problem you're trying to solve, since it sounds different from the one JavaScript in web browsers is solving.
I agree that things like asm.js have a performance hit compared to just running an unsafe binary blob. So does PNaCl (though the hit there is different from the asm.js hit: it has somewhat faster steady-state, but worse startup performance). Again, if you're not talking about something that has the same safety guarantees as JS and PNaCl you're comparing apples to oranges.