Web assembly has never had anything to do with the web.

At least that's been my experience whenever I find it in production.

It definitly had to do everything with Web, it was the agreement between Mozila going with asm.js, Chrome pushing for PNaCL, Adobe with CrossBridge, Sun with Java, Microsoft with ActiveX,....

Then some folks rediscovered UNCOL from 1958, all the systems influenced by it, and started to sell the dream of the bytecode that was going to save the world.

This is retconning the history of WASM. While WASM was designed to be also be usable outside browsers, nobody could really predict at the time what this usage would look like exactly.

That's were it came from but it's perfectly able to run in environments that don't have anything to do with the web.

The web part is the security model and the tradeoffs between security and performance. PNaCL was in browsers but not "web" for this reason.

Like the assembly part means low-level and meant as a compilation target, not CPU instructions.

So websssembly is an assembly language for the web, like webgl is opengl for the web and webgpu are gpu APIs for the web. And behold none of those can access DOM APIs

> So webassembly is an assembly language for the web.

But is isn't, at most WAT is (the WASM text format). WASM itself is a bytecode format. Nobody calls CPU machine code 'assembly' (nitpicking, I know, but the 'web' part of the name makes a lot more sense than the 'assembly' part).

At least the 'web' part makes more sense than the 'assembly' part ;)

WASM was designed as a successor to asm.js, and asm.js was purely a web thing. While non-web-platforms were considered as a potential use case (in the sense of "using WASM outside the web should be possible", it wasn't clear at the time what the successful usages outside browsers would even look like).