WebAssembly adoption: Is slow and steady winning the race?

This quote from the end of the article is good:<p>&gt; With this in mind, maybe Wasm <i>is</i> mainstream. Spencer notes, for instance, that anyone who browses the web is likely to be interacting with WebAssembly on a daily basis.<p>I think that&#x27;s correct. Non-Web usecases are a more complicated story (that the article focuses on), but the Web side is largely complete and successful, and that was the original purpose of Wasm. In that sense it&#x27;s already succeeded.

&gt; “WASI preview two is a checkpoint of stable interfaces,” Spencer said. “The instability of preview one, [which] may have scared or prevented you from using Wasm in production, is now past us.”<p>I wasn&#x27;t aware a new version of WASI was out. I&#x27;ve been following it for years and its potential is still exciting.<p>Some quotes:<p>&gt; WASI 0.2 also introduces two distinct “worlds,” which describe different kinds of hosts that WebAssembly can run on. The first of these worlds is the “command” world, resembling a traditional POSIX command-line application with access to the file system, socket and terminal.<p>&gt; The second of these worlds is the “HTTP proxy,” which characterizes platforms, like Fastly, that can send and receive streaming HTTP requests and responses, serving as forward or reverse proxies. These worlds represent the beginning of a broader ecosystem, offering developers multiple avenues to explore and innovate, and more worlds will be added to WASI in the future.

The real value in Wasm is in the Web use case: bring to the most popular platform software that was impossible (or very difficult) to bring before.<p>Just look at Ruffle (Flash Player reimplementation), V86 (x86 virtual machine), Google Earth, ...<p>Wasm on the Server is a fad, and sadly it&#x27;s hijacking resources and design space from the real thing. WASI being a prime example: because of the &quot;Component model&quot;, any attempt at tighter integration with the Browser API stopped in the hope for a magical solution to all computing problems.

Web Assembly has (at least in the past) a business problem.<p>In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about.<p>Worse, it won&#x27;t ever work if you intended it to be a JavaScript replacement because it cannot integrate into the interaction of the surrounding page, because it is a sandbox without compromise. This line of wishful thinking instills false hope and just pisses off everyone else, which slows adoption among other languages. The Web Assembly effort has been very clear about this from the very beginning, but people believe what they want to believe even after this has been clarified dozens of times.<p>There are absolutely valid business cases behind Web Assembly though, here are some:<p>* circumventing iphone restrictions<p>* desktop application portability<p>* security<p>* partial docker alternative<p>* promoting adoption and access of applications written lesser popular languages

I really don&#x27;t see much of a value outside the browser, other than an avenue for startups to resell yet another bytecode based platform, as if we haven&#x27;t had enough since UNCOL (1958).<p>The ongoing attempts to bring back application servers, but with Kubernetes, WASM and plenty of YAML, is a kind of tragic irony.<p>And on the browser, if one needs performance it is better served with GPU code than WebAssembly, other than bringing existing libraries into the browser.<p>At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations.

&gt; “While obviously C&#x2F;C++ and Rust came to the ecosystem early on, other languages seemed to slowly put a ‘toe in the water’, first having limited support and then gradually investing more as usage takes off.”<p>This is the biggest limitation for me. I like WASM fine, but anytime I want to use it I have to turn back to Rust. I like Rust fine, but without support in other languages, it&#x27;s not necessarily worth diving into.

It’s just not very useful as you can’t interface with the external world much (yet). System calls are still very limited and even things like opening a UDP socket are highly experimental. So I’m excited for it but there’s a ton of stuff missing to actually make it useful for most real world use cases.

WASM doesn&#x27;t interest me for my development because it comes with what I consider large downsides without giving me any substantial benefits.<p>That&#x27;s not to say that I don&#x27;t see any benefit in it. I can see use cases for it, they just aren&#x27;t use cases that I have.

I haven&#x27;t been keeping up, can I write webpages that replace all javascript with wasm yet?

The assumption is that javascript is bad and that the solution is to not fix it. asm.js was another example.