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.
I certainly would not say ‘more open’. It is newer, but that's a mark against it, not for it.
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).
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.
It seems like it's headed that way. At the moment, it's only really practical to generate WASM from compiled languages, or really small languages, like Lua. And your interfaces to the browser (and thus, the outside world) itself are pretty limited, so still lots of javascript involved.
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.
Yes, but for interpreted language 'X', are the created artifacts of a practical size to send down the wire for an actual production site? The idea being that as WASM adds higher level primitives, that size gets smaller.
I'm also trying to build a mental model of what wasm is so someone correct me if I'm wrong.
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.
Not really, whilst bytecode would be slightly harder to verify than an AST a paranoid interpreter wasn't that hard to craft.
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.
Comments
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.
I certainly would not say ‘more open’. It is newer, but that's a mark against it, not for it.
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...
Why do you say that WASI misses the point? (genuinely curious)
It seems like it's headed that way. At the moment, it's only really practical to generate WASM from compiled languages, or really small languages, like Lua. And your interfaces to the browser (and thus, the outside world) itself are pretty limited, so still lots of javascript involved.
Can confirm that Lua does run in WASM in the browser: https://github.com/vvanders/wasm_lua
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/
If your language is supported by LLVM, then Emscripten can compile it to WASM.
Yes, but for interpreted language 'X', are the created artifacts of a practical size to send down the wire for an actual production site? The idea being that as WASM adds higher level primitives, that size gets smaller.
Sorry, I misread your comment. I thought you wrote that only "small languages", or Lua, can be compiled to WASM.
I'm also trying to build a mental model of what wasm is so someone correct me if I'm wrong.
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.
Wasm lacks a lot of lower level system specific operations that the jvm offers.
In a way, but wasm is designed to be a lot better at sandboxing.
Not really, whilst bytecode would be slightly harder to verify than an AST a paranoid interpreter wasn't that hard to craft.
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...