WASM was designed with the intent that it run in the web as well as natively[0].
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.
IOW, JVM/CLR wanted primarily to support locally run, trusted application code and gave up on browser sandboxing. WASM is primarily run on browsers and hasn't attempted yet to support full applications. Apples vs. oranges.
I don't think it's apples and oranges, I think it's approaching the same destination from different starting points.
Re:Universal Binaries Using WASM
by johncolanduoni on Tuesday February 26, 2019 @09:46PM
(#19260435)
I wasn’t claiming that they don’t have distinct feature sets; WASM for example can’t currently do any kind of shared memory concurrency, let alone provide a GC with shared memory concurrency. The claim that it’s just a recapitulation of the JVM however is equally innacurate. Nobody would seriously consider running multiple mutually-untrusted JVM programs in the same process, but WASM is offered in that manner in every major browser.
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.
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.