"Write in whatever language you want" - For languages that need a VM (most garbage collected languages for example) you would need to port the VM to asm.js. That's a job in itself. Then when a user hits your site they would need to upload all the asm.js for the VM at least the first time (think about that on a sketchy mobile connection). On top of that the performance of C++ to asm.js is about half native. The performance of e.g. a ruby interpreter running in a VM that was ported to asm.js could be a long way off native. The performance of e.g. Ruby might be acceptable on a server where you can throw more horsepower at it. But on a client? Client code is the most performance critical there is. The user expects instant feedback when they swype. Even if there was a native Ruby VM (for example) on the client it still might not meet your performance requirements not to mind one that runs in asm.js. It was the movement back to the server side with web programming that enabled the diversity of language use in the 90s. On the client the same old restrictions apply i.e. we would need something to make those VM's faster than their native versions, not slower.
Asm.js is not an alternative to JavaScript, though. It is JavaScript, just a really mangled and ugly subset of it.
cliveowen was clearly talking about "an alternative to Javascript" and "not [...] those things that eventually get translated to Javascript". Anything targeting Asm.js is merely targeting JavaScript.
The "half native speed" claim is quite dubious, at best. Even if it were realistic, that's still quite a horrible decrease in performance relative to native code. It's not as bad as the typically much worse disparity, but it's still not good at all.
Talk about JavaScript being replaced wholesale should be regarded as therapy. Therapy to dull the realisation that JavaScript is now immortal because it gained such massive reach and entrenchment. It's the web counterpart to C the immortal.
