3 ms·
The reason for not using LLVM bitcode or ASM.js is already covered in detail here https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/We
by n00b101 10y ago
The reason for not using LLVM bitcode or ASM.js is already covered in detail here https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md
I am unsure how JVM or CLR are relevant. WebAssembly is not a virtual machine byte code (and neither is LLVM, despite the name). As the name "WebAssembly" suggests, it is like an assembly language level target for "the web" (more precisely, for JavaScript interpreters found in web browsers).
It is true that there is a lot of unfortunate duplication of effort and fracturing of technology happening here, due to historical legacy issues with web browsers. JVM and CLR are indeed highly mature and presumably secure VMs today. If we were to wave a magic wand and rewrite the history of the web browsers, perhaps it would be much better if JavaScript never existed and browsers used an off-the-shelf, standardized VM like JVM or CLR and we wrote web apps in C# or Java (or, at our discretion, F#, etc). This wouldn't solve the problem that WebAssembly is solving (i.e compiling native code, eg C++, for execution in the browser), but then maybe we wouldn't have needed that today if everyone (native and web) had standardized on a single VM target. But that's just not how things turned out, browsers created their own parallel technology stack from scratch so things like WebAssembly need to be created from scratch to work within the constraints that we are stuck with.
- zigzigzag 10y agoI wrote more on this above, so I won't repeat myself in this comment, but yes WebAssembly is a "virtual machine byte code". It is literally a bytecode language that doesn't target physical machines. It bears no resemblence to x86 or ARM so it has to be JIT compiled or interpreted. Saying it doesn't target a VM because it targets "the web" is meaningless.
- n00b101 10y agoFair enough. You are correct, WebAssembly is a bytecode for the underlying machinery of current ECMAScript/JavaScript engines. I think you raise a very good question, why did the WebAssembly committee decide to implement their own stack machine bytecode instead of re-using an existing bytecode like JVM or CLI (which, interestingly, is an ECMA standard)? It's troubling. The closest explanation I could find is: "Why not a fully-general stack machine? The WebAssembly stack machine is restricted to structured control flow and structured use of the stack. This greatly simplifies one-pass verification, avoiding a fixpoint computation like that of other stack machines such as the Java Virtual Machine (prior to stack maps). This also simplifies compilation and manipulation of WebAssembly code by other tools. Further generalization of the WebAssembly stack machine is planned post-MVP, such as the addition of multiple return values from control flow constructs and function calls." [1] [1] http://webassembly.org/docs/rationale/ http://webassembly.org/docs/rationale/
- n00b101 10y agoI found the relevant discussion on this: https://github.com/WebAssembly/design/issues/960 https://github.com/WebAssembly/design/issues/960