[jeroenhd]

> The alternative is that we have some specification for intermediate code which is low level enough to be a universal compile target but abstract enough to be possible to compile to essentially any CPU architecture. That's what WASM is.

Isn't that exactly what Java did years ago? And what Microsoft's .NET bytecode did when they had to remove the Microsoft JVM?

Standard WASM is stack based, unlike every real computer out there. It also explicitly supports unaligned memory which is terrible for native execution performance. It was designed for the limitations of the browser sandbox as an evolution on a backwards compatible Javascript library.

I don't know why you'd need tk shop different versions for different instruction sets, that's exactly the problem Java, and to a lesser extent dotnet, solves. The runtime is platform dependent, the binary isn't. You can build a JAR and run it on anything from old MIPS server to a Windows 11 machine or an M2 Mac if your code targets a runtime old enough. You don't need to compile separate versions for each platform at all.

Building platform independent executables has already been solved by Java and very few people actually use it. I'm not against an alternative to Java, or anything else tainted by Oracle for that matter, I just don't see the use cases outside the browser for platforms precompiling WASM.

[mort96]

Sorry, I was responding to this:

> what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code?

That's where the proliferation of instruction sets and instruction set versions is relevant. My comment wasn't trying to address the Java/.NET part of your question.

My response to "Why not Java bytecode" is here: https://news.ycombinator.com/item?id=32743910. I don't know enough about the design of the CLR to comment. In any case, neither Java bytecode nor CLR bytecode are proper open standards, so they seem like bad fits for the web unless Microsoft or Oracle wanted to lead an effort to turn them into web standards.

I don't have enough experience with compiler back-end theory to respond intelligently to what sort of challenges and benefits a stack-based IR represents, but I know that you can view a stack language as a language with arbitrarily many registers, which you can translate into SSA form, which lets you do efficient register allocation, so I imagine the stack-based nature might be okay? I agree that allowing unaligned memory access seems like an issue, but I suppose the alternative there is to have different alignment requirements per architecture, which hurts interoperability. I'd love to hear from WASM implementers whether this causes problems in practice or not.

[miohtama]

I feel the JVM bytecode was not universal compile target where WebAssembly is. JVM target was hand-in-hand with Java the language, both owned by Sun, later litigation happy Oracle. Java was a political problem, plus also a security problem due to its various exploits. Thus, I feel it is incorrect to say Java the compile target solved anything (thought the language found a niche use case at server software later).

Some use case outside browsers are edge computing and distributing binaries (for computation efficiency) with NPM packages. For example, distributing cryptographic libraries as Wasm instead of error prone reimplementation in JS.

[dgolubets]

Both Java and .NET use garbage collection with all the upsides and downsides of it. They also have heavy runtimes with slow startup times. WASM is different is these aspects.