Except now we have to drag an entire JVM worth of code across the network just to say hello world!

There are some important differences in approach. Java was never designed to be downloaded over a network, and didn't have a module format or JARs back then. This is part of what made it so slow. In contrast, efforts to make the encoding of modules as compact as possible started the moment WASM began. [1] It was based on past research in compactly encoding IRs, and the modules are often processed in parallel.

The IR is also a lot less opinionated than other VMs. It started out being similar to a stripped-down JavaScript in capability, but broadened. At the same time it remained easy for browser engines to process into native code. Compared to optimizing applets, it has a simpler task to solve. This does have the disadvantage that modules need to come with their own runtimes. Compilers for languages like C have to deal with the fact that their host languages expect to be running on a fully-featured OS instead of a browser.

Even though it is a binary blob downloaded over the web, browsers come with disassemblers that allow you to see what is actually running. This is a step up over applets, but this is one part of WASM I find particularly underwhelming. The messy development of the VM affected the text format the most, so it's more confusing than it really needs to be. Some docs expect you to write it like a Lisp, even though there's no parse tree encoded in WASM.

WASM has quite a few problems, but they're at least different problems than the ones applets had.

1. https://github.com/WebAssembly/design/blob/a19e4ccf9c250cc73...

There’s a crucial difference though. Applets required you to download and install the JVM, and it was never part of web standards. Wasm is a w3c standard and built into browsers.

But I see the similarity in terms of compiling your software down to another (supposedly universal, we’ll see) intermediate instruction set.