Compiling to asm.js isn't the same thing as compiling to JS. asm.js is just a funny-serialized bytecode. Someday they can trade it out for a sane serialization and hardly anything will blink.
Worst case, I expect individual compilers will develop their own bytecode serialization format that generates asm.js on the client. There are various reasons to do it already (compression, debug vs release readability/minification concerns, etc) and future revisions of asm.js (like v2, which introduces Java/C#-oriented heap structures) will make it worthwhile.
Compiler -> Bytecode -> Normal JS/ASM.js is the long term strategy for asm support in JSIL, since it will depend on currently-experimental asm features and using asm+polyfills on all browsers would have obscenely bad performance characteristics.
Comments
Compiling to asm.js isn't the same thing as compiling to JS. asm.js is just a funny-serialized bytecode. Someday they can trade it out for a sane serialization and hardly anything will blink.
Worst case, I expect individual compilers will develop their own bytecode serialization format that generates asm.js on the client. There are various reasons to do it already (compression, debug vs release readability/minification concerns, etc) and future revisions of asm.js (like v2, which introduces Java/C#-oriented heap structures) will make it worthwhile.
Compiler -> Bytecode -> Normal JS/ASM.js is the long term strategy for asm support in JSIL, since it will depend on currently-experimental asm features and using asm+polyfills on all browsers would have obscenely bad performance characteristics.