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. Th

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/a19e4ccf9c250cc730afa9941944f377a7c87dcd/BinaryEncoding.md https://github.com/WebAssembly/design/blob/a19e4ccf9c250cc73...