For one, no one needs to install WASM, nor are they going to run into versioning issues because the OS has a hard dependency on it. Every single person with a computer, from a smart phone to render farm workstations, will have WASM support because those devices will have a browser. The only browser that doesn't support it is the legacy IE line of browsers, of which only 11 is still supported, and which only runs on systems that will happily run Edge, instead.

Devs can rely on the fact that users won't need to install a single thing, and users can rely on the fact that they're not going to have to go through the insanity that is "trying to install the right version of Boobletech(tm) Meep(r)" or, hell: "trying to get their OS to even acknowledge that the preinstalled version of java is over a decade old and it needs to stop using it instead of the new version you installed".

If your compiler can target WebAssembly, and your users are on computers with operating systems that are still supported, your WASM application will work for them, because everyone has a browser.

Unless your user is using a iPhone.

Not unless your iphone is a hand-me-down from someone who themselves got it as a hand-me-down?

https://caniuse.com/?search=wasm

Safari has support for WebAssembly.

I’m not sure either. There are some technical differences. WASM is more low-level than JVM bytecode, which is important for some applications and makes it a more normal compiler target. It’s more integrated with the rest of the browser: it doesn’t come with its own rectangle like Flash and Java did, but instead manipulates the DOM just like (or at the moment, only through) JavaScript. And it’s a true open standard, not a corporate-controlled platform.

Do these differences really matter, or is it mostly just the timing?

WASM is definitely more low-level than JVM byte code right now... but I'm not sure it'll remain that way given the many proposals that are very likely to be implemented in the future (even though it's taking a long time for even simple ones, like multi-value returns, to get into the standard). For example, with WASI and GC, which will finally enable direct access to the DOM, how much lower-level will WASM be compared to JVM? Not much, I would say.

The big difference is that WASM, from the beginning, is supported by all the browsers natively (a consequence of it not being a proprietary technology, but an open standard), not as a plugin... If Java had started that way, the story would've turned out quite differently (but we know that at the time, the browser everyone was using was made by Microsoft, and Sun was a competitor so this would've never happened).

It starts immediately, while any embedded java applet took forever and looked really ugly. We've also done this with flash apps

The difference is that wasm is designed to be sandboxed, instead of the JVM which was designed to normalize disparate computing environments. In practice, this entails a lot of work to create runtimes to do anything interesting in wasm, but the behavior is secure by default (ignoring side-channel attacks, of course). Java applets run in a sandbox by default, of course, but the JRE itself has unmitigated access to the host system, so the security boundary isn't as well defined. Users can also be tricked to trust malicious applets, which is a built-in mechanism to escape the sandbox; browsers hopefully will not provide this feature for their wasm runtimes.

> the JRE itself has unmitigated access to the host system

As does the browser in which WebAssembly executes.

> Users can also be tricked to trust malicious applets

But the ability of applets to be trusted could have been eliminated entirely. To rewrite OP's question, then:

"If we had entirely gotten rid of trusted applets, couldn't we already do this with Java, 20 years ago?"

Of course, we didn't get rid of them, but that's still a valid question vs. inventing another technology.

Interesting thought experiment. However, you have to realize that Sun wasn’t a charity. At the time, platform vendors were were hoping to target intranet applications for the enterprise. Microsoft had a similar concept for trusted applications with IE’s “Active Scripting”, with very similar results in terms of (non)security.

Can't we just do this in sandboxed regular assembly running inside a virtual machine?!

/s

which assembly?