That would be true if asm.js were just a faster interpreter, but it isn't. It's not even really a separate language: "use asm" is just a hint to the JavaScript

That would be true if asm.js were just a faster interpreter, but it isn't. It's not even really a separate language: "use asm" is just a hint to the JavaScript runtime that the code follows a particular set of conventions that, it so happens, are very easy to optimize. An asm.js-supporting runtime which sees this hint can run that code through a different compiler that takes maximum advantage of the available hardware (i.e. whatever it's running on, with the asm.js code doesn't need to know or care about). A runtime that doesn't support asm.js will just run the code like it did before. My point is that asm.js is every bit as capable of fully optimizing for the host as NaCl. It has two big advantages over NaCl, though. One is that it's architecture-independent: the host knows what architecture it uses, and (assuming it has the compiler, which an asm.js-supporting runtime has by definition) can act accordingly, taking full advantage of its own features. The other advantage is that there's a fallback even in case the runtime doesn't support asm.js: it's no faster than ordinary JavaScript in this case, but at least it does no harm.