[AyanamiKaine]

I really hate wasm, not because of the idea or concept but because it gets bloated.

The first idea was computation heavy algorithms to be written in a language like C/C++/Rust and to be compiled to wasm.

Now it gets marketed as something to write sandboxed code/compontents for every language to be consumed by a wasm runtime.

Then there is the problem with the types of wasm. While it was seen to be something run on the web/browser. Its types are way more similar to rusts. For example strings in JS are fundamentally UTF-16 while wasm/rust is utf-8.

We need to constantly convert between them. I always hoped that wasm would simply allow for faster code on the web not here is my program completly sandboxed from the outside world you cant interact with other programs on the same machine.

[jonex]

Didn't it start with asm.js, a subset of javascript serving as a way to compile C code to be run in a browser? Then browser makers figured that it'd be better to have a dedicated target for this. So while it can be used to achieve performance in specific scenarions, it's largely designed with the goal in mind to be able to run non js code in a browser. The wasm toolchain Emscripten encompasses this notion quite clearly as it emulates things like filesystems etc. If the main goal was faster execution, they would probably have gone a different route. PRobably even gone for a new language altogether.

I'd like a toolchain better targeted for the pure acceleration use case though. Emscripten adds a lot of bloat and edges just to serve out of the box posix compatibility. Which is nice for quick demos of "look I can run Doom in the browser"-kind. But less useful for advanced web app usage, where you anyways will want to keep control of such behavior and interact with the browser apis more directly.

[flohofwoe]

> Didn't it start with asm.js

It started even much earlier. At first Emscripten compiled to a plain Javascript subset, after this demonstrated 'usefulness' this JS subset was properly specificed into 'asm.js' which browsers could specifically target and optimize for. The next evolutionary step was WASM (which didn't immediately bring any peformance improvements over asm.js, but allowed further improvements without having to 'compromise' Javascript with features that are only useful for a compilation target).

[pjmlp]

Even earlier, it started with NaCL, then PNaCL. With an SDK that supported C, C++ and OCaml.

Mozzilla not wanting to jump into Google's boat came up with asm.js.

This naturally ignoring all the other plugins.

[pjmlp]

The irony is all those Java and .NET haters, jumping into startups selling the dream of doing application servers packaged in Kubernetes pods.

Plus, having to watch talks selling the idea as if no one had ever done it before.

This even ignoring operating systems where the whole userspace was bytecode based.

[DonHopkins]

My Apple ][ ran Sweet 16 and UCSD Pascal.

[pjmlp]

Yeah, for example.

[shevy-java]

The even bigger issue is that this will remain a niche thing.

Things that are a niche, will often sooner or later just die - and nobody will even notice this. I don't understand the wasm committee. Why design something that is bound to fail due to barely anyone using it?

[hobofan]

I think you overestimate how niche it really is. In the browser it's an essential part for many creative/productivity tools, e.g. Figma or Miro. On the backend it's used quite regularly as sandboxing mechanism or plugin system, e.g. Istio, Helm or OPA (so generally a high prominence in the CNCF ecosystem).

There are a lot more niche web standards that have a lot less usage that stuck around for a log time (e.g. the recent debate around removal of XSLT)

[flohofwoe]

I mean... don't believe the hype, doh? ;)

WASM is "just" another virtual ISA, everything else is just marketing. If you manage expections (in the sense of "it's just another ISA / bytecode VM") then WASM can be incredibly useful, e.g. all my C/C++ projects are running automatically in browsers thanks to WASM (for instance these home computer emulators: https://floooh.github.io/tiny8bit/).

[twoodfin]

I think you’re discounting the embedding model, which opens up many interesting use cases for WASM.