This is profoundly false and I would have hoped you'd know better than to make an argument like this. There's an enormous gap between the CLR and (even bleeding

This is profoundly false and I would have hoped you'd know better than to make an argument like this. There's an enormous gap between the CLR and (even bleeding-edge) asm.js, not only in standard library feature set but in language feature set. MSIL is dramatically more expressive and the runtime offers a bunch of capabilities that still aren't available in the browser. At present if you want to actually run a typical .NET application in the browser, you will have to boot and run an entire CLR implementation in asm.js, specifically because asm.js is not expressive enough to map typical CLR code to it. This includes things like reimplementing garbage collection because the browser still doesn't offer basic primitives like weak references. Even once you do that, there are specific things you won't be able to do - for example, weakly hold references to the DOM, or handle cross-language reference cycles. For the record: I am the author of a .NET -> JS translator with near-complete CLR feature support, including unsafe code (pointers) and p/invoke. This stuff is not trivial, and much of the difficulty is a direct result of how anemic asm.js is as a compilation target, not to mention how pathetic the ES5 stdlib is. I'm also a participant in the WebAssembly spec process and I think you've misrepresented what it currently offers. The web has a bright future but pretending it doesn't have problems does no good. It's honestly quite insulting for someone to claim that everything is OK here when I've been fighting hard for years to get the ecmascript and HTML5 feature sets moved forward so that the web can actually compete with .NET.