That link is misleading in the context you present it. Those are microbenchmarks, which a JIT can optimize relatively well. But if you look at the very next slide at http://kripken.github.io/mloc_emscripten_talk/#/28 you will see that for a larger application, non-optimized asm.js performs abysmally, as does JS in general. A performance penalty of ~1000% of native is what you should expect for a nontrivial JS application, and asm.js does not do much (if anything) to alleviate that unless you run odinmonkey.
I was purposefully linking to that slide + the one after it.
Yes, there is a factor of around 4x slowdown between asm.js optimizations and without them, on the next slide. But even 4x slower than asm.js is quite fast, it's enough to run the Epic Citadel demo for example (try it on a version of firefox without those optimizations, like stable release - as others reported in comments, it runs ok). A lot of the work in Epic Citadel is on the GPU anyhow, say it's about half, so the difference is then only something like 2x.
2x is not that much, we have similar differences on the web anyhow because of CPU differences, JIT differences, etc. That's within the expected range of variance.
It's faster than "handwritten JS" because it's using a subset of JS that's already tuned to near the peak level of performance that you can achieve in JITting JS, which is tightly looped arithmetic with everything inlined working on SMIs. In V8, that's ~2.5x slower than the equivalent C code with optimizations. That's basically best case.
The problem is that it's still dynamic, and at any point a null can come along and force you to throw away a JITted function, so you have to have these checks everywhere just in case. Further, ECMA compliance does not require JIT compilation, which means to expect performance, especially on the web, is dubious at best. I can see merit to expecting performance metrics in something like Node.JS since it assumes V8, but the web does not have 1 JS engine, and the standard does not require such performance metrics.
The "benefits" of building a bytecode in that's represented in some subset of JS are essentially red herrings since they're effectively lies and the downsides are a lot more significant, IMO. Instead, we should be focusing on actually building a bytecode for the web such that all implementations are expected to have certain performance metrics.
