[lxgr]

> if one needs performance it is better served with GPU code than WebAssembly

What? No! Would you suggest replacing e.g. the Linux kernel (parts of which are very performance critical) with GPU code too?

WebGPU is great for, well, GPU-like compute! That's not nearly all performance-critical compute. One example: Stockfish, a top chess engine, is exclusively CPU-based, and runs perfectly in WASM.

> At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations.

Couldn't disagree more. Flash, ActiveX and Java were unpopular because they all came with their own weird/non-native-feeling GUI toolkits and UI paradigms (e.g. breaking right clicks and text selection, Ctrl+F etc.). Flash and ActiveX were also closed source and only available on some platforms. ActiveX was also very badly sandboxed on top of all of that.

WASM is none of that. The only thing you'd notice e.g. about a site bringing its own media codec, game engine etc. in WASM instead of JavaScript is better performance.

[pjmlp]

Linux kernel isn't supposed to run in the browser.

Indeed WASM is nothing like yet bytecode being capitalised by startups, in search of the next Java goldmine, by folks that enjoy bashing about it. /s

App servers bad, Kubernetes with WASM, "oh boy that is soooo cool!".

[lxgr]

I think many people like the idea of bytecode, but not the implementation of Java/the JVM (especially if they have an existing codebase or don't want to start a new one in Java), and I think that's pretty fair.

[emporas]

"Write once, run everywhere" is pretty important goal to achieve. When a project has to be written for a platform, and then ported to other platforms, then some ports or all of them turn out to be pretty bad.

Essentially the program runs only on one platform well. The ports also may turn out to be a significant burden depending on the size of the project, which usually grows over time.

Take Adobe as an example. It's port of Linux was pretty much unusable, only many years later to be revealed that only 2 programmers were responsible for maintaining the codebase.

[pjmlp]

And just like multiple times since 1958's UNCOL, WASM write once run anywhere will reveal itself as not really true, specially when going beyond bare bone computations, using multiple runtimes and competing WASI implementations, that will never make it to the browser, and are cloud vendor specific.