That said, I'm somewhat excited about this, but also discouraged by the lack of commonality between major browsers in this regard. Now Firefox has asm.js, Chrome has NaCl, and Microsoft has ??? and Opera has ???. Uugghh...
Still, anything that stands to make the web experience faster and more useful is a good thing, I guess..
That's good to know, then. Hopefully this makes things better for everybody!
If Firefox is the only browser that implements asm.js, it'll have about the same issues as Dart or NaCL. That is, Dart also compiles to JS, but if Dart2Js were 6x slower on Firefox than Chrome, no one would be cheering, and in fact, this is a complaint Mozilla themselves raised in the beginning.
If I'm writing a game in C and compiling it to asm.js, and it's gonna run 6x slower everywhere else, I'm effectively developing it for Firefox only no differently than if I had compiled C to NaCL/PNaCL.
For this to be effective, it has to be cross browser. At least, Mozilla and WebKit/Chrome.
That's already a problem with many things web though, different browsers have different performance profiles already and things leading to smooth 60fps in one browser may not do so in an other one.
The flip side for asmjs might be this: you manage 60fps on Chrome, Firefox is also at 60fps but uses less resources (since it's got special support) so you save wee birdies. That's cool.
However, I don't think we will see a 6x slowdown here. JavaScript engines are already very fast on compiled code, because they have already been optimizing for typed arrays and so forth for a while now. Google even added a compiled C++ benchmark to Octane, for example.
In current benchmarks, asm.js gives you a speedup of anywhere from 1x (where normal JS optimizations already got us very close to native) to 6x. So 6x is the worst case, and there are plenty of cases in the middle. A 2x-3x difference is not big enough to make something a false sense of portability, the web has tolerated 2x-3x speed differences for a long time now, and these things also change a lot in terms of who is fastest, on what, and by what.
Furthermore, I would not expect a 2x-3x difference to last very long, again, because browsers have been competing on performance of this type of code for a while now (Octane, etc.), and will continue to do so.
For Dart, I don't know enough about how the VM works.
But in general, a language like Dart could work. For example, LuaJIT or PyPy could be ported, the C parts compiled into asm.js, and the JITs would need a new backend that emits asm.js instead of x86 or ARM. This could potentially make a language like Lua, Python, Dart, etc. very fast on the web. However, how feasible it is would depend on the VM architecture.
I hope to work on this kind of stuff later this year.
Also, if you consider something like the Java Virtual Machine, it's practical to make it work on NaCL, but JS doesn't support blocking/synchronous calls, and how earth would you make all of those synchronous APIs, and multithreaded APIs work in that context?
asm.js is not isomorphic to NaCL in terms of feature set, but asm.js + something like OpenCL could probably work well for games.
Multhreading is another concern, if you want shared state (with the JVM would need). It can't currently be done, but again, is worth thinking about and perhaps new web APIs could enable it some day.
So Firefox has JavaScript, Chrome has JavaScript, Microsoft has JavaScript, etc. Firefox can just run it a hell of a lot faster if you add "use asm" to the top of your function.