W3C recommends WebAssembly

As if that's not already happening today with obfuscated and minified javascript

Also, the use cases for javascript and webassembly don't overlap enough for one to replace the other in most cases. Javascript is a text-based scripting language you can write in any editor (the sprawling morass that is the current js development ecosystem notwithstanding,) but WASM requires knowing another language and having a compile step, which adds friction and complexity. You can't really replace a language with a bytecode.

It may mean that other languages can be deployed in the browser as easily as javascript, which may or may not be good depending on your point of view.

I personally look forward to the day when Hacker News embeds the Arc runtime as WASM and replaces all of their javascript with Arc code.

* Sandbox. WASM is a sandbox. Think of WASM as a language agnostic replacement for Flash. It is an island in a webpage isolated from that page. This is great for security so that the opaque binary running in that WASM island cannot modify the page in such ways as to violate the same origin policy, such as turning a button into a hyperlink with a user's personal details attached as query parameters on a malicious third party URL. It also means code executing in WASM cannot interact with the surrounding page, which means it isn't a JavaScript replacement. The developers of the WASM standard have been very clear that WASM will not ever be a JavaScript replacement.

To be fair there is work being done, several years in the making, to provide web-like technologies to WASM instances, such as a DOM. This enhancement eases some concerns of overhead, see the next bullet point, but they won't break security or escape the sandbox. This enhancement might go so far as allowing the containing page interaction with the WASM instance, but I suspect this would be limited, if at all, and only cross the sandbox barrier in one direction. There is huge interest in WASM and page interaction, but this is all coming from developers who want alternatives to JavaScript. There is no prevailing business interest in advanced WASM interaction.

* Overhead. Since WASM is a self-contained sandbox the incoming binary needs everything an application binary would otherwise need to execute as an application. For example if a WASM instance wants to pretend to be web page instance then it has to include its own DOM library, interaction code, presentation, and absolutely everything else. If accessibility is a concern you would likely have to reinvent how that works in your WASM instance. While this is of great interest for developers who hate JavaScript there isn't a lot of business value in that.

* Performance. So far WASM has not been able to significantly outperform JavaScript. In many cases WASM code performs slower than JavaScript. Without a large performance differentiation there is little business justification to invest in WASM. Flash's claim to fame is that for most of Flash's life it did significantly outperform JavaScript by an order of magnitude. JavaScript never got faster than Flash, but it did almost completely close the performance gap. Once JavaScript got fast Flash started dying.

---

There is potential business value in WASM, but you have to be willing to abandon any consideration that you are executing in a web page. Selling the idea to business owners that you are executing in a web page, but you need to imagine that you aren't is a tough sell. Here are some ideas that might work better in WASM than the typical web environment:

* Document interaction with digital signatures from physical tokens.

* Streaming media players with embedded DRM.

* Certificate negotiation for an end-to-end encrypted messaging tunnel transmitted via web page.