Also neither the JVM nor the CLR even seriously attempt to offer the security when executing untrusted code that WASM does. WASM has been deployed for over a year in all the major browsers, making vulnerabilities in its implementations very valuable. Yet we haven’t seen some huge explosion of CVEs due to its addition, unlike the early history of the JVM and CLR’s attempts to implement robust software sandboxes (before they both threw up their hands and stopped trying to market their sandboxing features as suitable for running untrusted code).
Is this a fair comparison? JVM and CLR allow general purpose programming and syscalls across several platforms. What can you do with WASM today? Only whatever is allowed by browsers.
It just happens that the technology is still in its infancy and, because initial support was deployed in browsers, the web is currently the primary focus of developer interest.
And, unfortunately (to me) the most likely means of "native" deployment for WASM applications is going to be in Electron, but that's due to a limitation of the initiative of developer culture, not WASM itself.
That said, nothing stops a WASM embedder from offering system calls, and you can already use whatever system resources you want via Node as easily as you can use the DOM in a browser.
You can take your Java/Rust/.Net/Haskell/etc/etc apps and compile them down to WASM, much like you would if you were using LLVM to compile down to assembly.
At least with WASM if it takes off, it can at least path the way for a more better and more appropriate (LLVM, AoT CLR, etc) universal machine code later down the line. That’ll never happen if we’re chained to JS though.
As for LLVM as the underlying target for machine code, it is already a thing, nothing new here.
I don't know why you think the situation would improve with WASM.