I'm a newer dev so pardon my ignorance. Is webassembly the new, more open JVM? Feels like that write once, run everywhere but this time with any(most) mainstream language.
It lacks most of java's ‘batteries’—there are projects like WASI that try to resolve this at a low level, but they miss the point somewhat. On the other hand, wasm is saddled with fewer assumptions about the type of code that will run on it. Wasm has generally poorer performance, which is mostly (though not entirely) an artifact of its design, and hence not easily rectifiable[0]. It's not clear to me the extent to which the jvm suffers similarly[1].
Socially, I think wasm is not as interesting as java. Write-once-run-anywhere was solved in practice not by java but by open source; by compatibility libraries like sdl; by standards, like posix and opengl; and by static linking. (Yes, it's not quite as convenient as just plopping in a jar, but it's close enough.)
I don't think we're ever going to see a desktop full of wasm apps. Despite stated goals, the point of wasm was always to be an evolution of the web as a platform for applets. The Birth and Death of Yavascript[2] has many insights thataways (even though it failed to predict wasm as such).
0. https://www.usenix.org/system/files/atc19-jangda.pdf
1. It's also difficult to directly compare the performance of the two systems in their current state. A number of proposals for both (gc for wasm, value types for java, simd for both) are yet pending and are likely to change the runtimes' respective performance profiles.
2. https://www.destroyallsoftware.com/talks/the-birth-and-death...
I sometimes wonder what the world would be like if Lua had zero based indices and saw a bit broader adoption. It's such an easy language to embed/extends although QuickJS looks like it's going to give it a run for the money in the long term given the similar goals on ease of embedding.
I wonder if anyone has compiled QuickJS to WASM and run it in the browser.
Fabrice Bellard actually did it himself here: http://numcalc.com/
As I understand, the JVM adds a thick layer of abstraction between incoming bytecode and output machine instructions. A wasm "runtime" OTOH adds a much thinner abstraction between incoming wasm and outputted machine code. It's a fairly 1:1 transformation.
However, I think you're correct in that, in order to serve as a host for GC'd and/or web-API-aware scripting languages (DOM, etc), a wasm runtime will need to become more JVM-like. How will wasm remain "web assembly" while doing that? No idea. This is where my mental model breaks down.
Iirc J2ME impls could be fairly secure (barring bugs since many were written in an age before security became a focus), and I think the spec even mandated pre-computed stack-frames (the expensive part of verification that is easy to post-validate for correctness).
Another part of J2ME was because like wasm/web, the runtime API was fairly small and all code could be contained within the sandbox with only API-extensions allowed to be native functions. (This restricted API and it's quite sad UI capabilities was probably part of why Apple ignored it entirely for iPhones)
What was much worse however was the mainline JVM and the Applets, Applets had from day 1 relied on all kinds of mainline JVM features and this featureset kept growing.
Features were encouraged to be written as much as possible in Java but many still had more or less large native parts. This is in addition to the core that allows for quite a bit of code loading,etc (that was allowed from applets).
All these features and loading that could allow for insecure behaviour was secured by a security policy system, sadly there was so many features that were exposed that used powerful dynamic features (the because they were whitelisted) allowed for untrusted code to behave or do stuff only trusted code should.
https://docs.oracle.com/javase/7/docs/technotes/guides/secur...