What I meant to say was not to use asm.js as target for compilation, but rather implementing performance-critical module in asm.js subset and get the extra performance out of V8. Sort of like how Rusha[1] did it.
Calling asm.js code is not free either, it's worth mentioning. I measured it at (very) roughly 2ms/call for the code I posted yesterday. (At asmjs.org they mention they intend to address this.)
It's not a no-op, it has to check types and maybe convert representations, much like a C/C++ FFI (but with more freedom for the implementor, who's not committed to the C ABI, so there's potential to go faster than a C FFI).
But I agree it needs attention, and apparently so do the Firefox devs. In http://wry.me/hacking/Turing-Drawings/ the asm.js version ran much slower than the regular JS version, until I adapted it to make fewer calls. The slowness also makes some other uses I've thought of impractical.
(The figure I gave was not carefully measured; just enough to say "yep, that'd account for why this is amazingly slow".)
It could help solve the cross platform extension problem. Windows users often get left out. This would make node.js more like java as a write once run anywhere platform.
Probably, but why? asm.js is supposed to be a target for compilation, but if you can run Node, you have a better target: actual machine code.