It’s like Java bytecode in the sense that it’s a bytecode spec for a virtual machine, but otherwise quite different. Wasm doesn’t include a GC or support for OO out of the box. It doesn’t even have strings.
That’s great for compiling languages like C++ or Rust though, but makes compiling higher order langues like python or java to it.
It is like Java bytecode, but design geared more towards supporting C.
Wasm in many ways is dumb. They could have easily adopted CLR or JVM bytecode. But no, the web is too "cool" for that. It's better to have a brand new VM that's slower and missing GC and a standard library.
The WASM instruction set is a tiny fraction of the size and complexity of the JVM and CLR instruction sets. One of WASM's primary design goals was to be able to prove safety and soundness properties for the language spec from the very beginning, and they've accomplished that [1]. Subjectively, I'd also argue that it is a much cleaner and more regular instruction set compared to JVM/CLR.
Because it has a lower level of abstraction than JVM/CLR (which, for example, have a built-in notion of what an "object" is, and every other language that you compile to it must have its own semantics shoehorned into that), WASM was able to become a good target for C, C++, and Rust.
The ultimate promise of WASM is that (given the right bindings) you can bring any C/C++/Rust codebase into the browser. E.g. see their demo of Doom running in the browser, utilizing WebGL bindings.
Any popular VM inevitably becomes as complex as those. Look at V8, it's grown into a JVM sized beast.
It would save countless hours of human effort to just adapt what's out there. It will be a decade before WASM has the kind of support JVM and CLR do. By then it will have the same huge codebase that causes vulnerabilities
> It's better to have a brand new VM that's slower and missing GC and a standard library.
I can understand a desire to build something new and better suited for a particular goal.
Didn't Java execution in the browser(loosely speaking) used to be a thing? I remember that causing security issues, and JVM/Java seems like a large enough thing that trying to mold it into something it isn't seems strange to me.
As for the missing GC, I mostly work with Rust so that doesn't really bother me, although I could see how it would be an issue with other languages. Also, I believe WASI mentioned in the article is the standard library.
WASM needs to move beyond MVP state and get first-class support for DOM APIs in the browser and some kind of first-class OS-agnostic APIs for outside the browser.
They were developed with different goals. WebAssembly is a stripped down version of asm.js that does not need to be compatible with Javascript semantics and is slightly closer to the hardware. In particular it shares with Javascript a strong security model.
from website: WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.
asm.js
an extraordinarily optimizable, low-level subset of JavaScript
http://asmjs.org/
so, IMO WebAssembly is not a stripped down version of asm.js even if they sold it as that to js devs to foster adoption
Yes, you are correct. What I wanted to say is that webassembly is a continuation in that direction.
At the time asm.js was ideated the alternative were browser plugins like NaCl, Flash, or Java.
The problem with asm.js is that the requirement to be a subset of javascript meant that some optimizations were impossible. wasm is another step in that direction.
Is this correct?