1. speed is relative. it's possible for fast things to go faster. JavaScript as it stands is fast enough for a lot of tasks, ASM.js makes it faster in certain p

1. speed is relative. it's possible for fast things to go faster. JavaScript as it stands is fast enough for a lot of tasks, ASM.js makes it faster in certain places. This can only be a good thing. 2. The market isn't saying JavaScript needs to go, JavaScript skills are high in demand, more so than ever. 3. This is the crux of your misunderstanding. I agree it would be nice if browsers supported e.g. LLVM out of the box. But they don't. And for political reasons they won't. If a company as large and powerful as Google cannot push NaCl adoption at all in other browsers (and NaCl was announced in 2008, so we're already half way to 10 years), how will you get them to adopt $YourVMofChoice? This is where ASM.js really wins - it is a subset of JavaScript, so it already works in other browsers, albeit without the performance boost and it is much easier for browser vendors to implement support for ASM.js than it is a whole new VM. Being backwards compatible means more web developers are likely to use it which will put pressure on other browser vendors to implement it. No one is arguing that ASM.js is a better technical solution to the problem, but it is a much better practical solution to the problem. 4. So this is another thing. Most of the people who are against ASM.js seem to dislike JavaScript the language. But ASM.js would free you from JavaScript almost entirely. The only time you'd see it is when you're debugging the "bytecode", and surely human readable bytecode is nicer than whatever something like LLVM spits out? Anyway, it seems like slightly curious reasoning.