This is profoundly false and I would have hoped you&#x27;d know better than to make an argument like this. There&#x27;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&#x27;t available in the browser.<p>At present if you want to actually run a typical .NET application in the browser, you will have to boot and run <i>an entire CLR implementation</i> in asm.js, <i>specifically</i> 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&#x27;t offer basic primitives like weak references. Even once you do that, there are specific things you won&#x27;t be able to do - for example, weakly hold references to the DOM, or handle cross-language reference cycles.<p>For the record: I am the author of a .NET -&gt; JS translator with near-complete CLR feature support, including unsafe code (pointers) and p&#x2F;invoke. This stuff is not trivial, and much of the difficulty is a <i>direct result</i> of how anemic asm.js is as a compilation target, not to mention how <i>pathetic</i> the ES5 stdlib is. I&#x27;m also a participant in the WebAssembly spec process and I think you&#x27;ve misrepresented what it currently offers.<p>The web has a bright future but pretending it doesn&#x27;t have problems does no good. It&#x27;s honestly quite insulting for someone to claim that everything is OK here when I&#x27;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.