So what is so exciting about a bytecode format, created out of the political war between PNaCL and asm.js, without any big news for anyone that actually cares about bytecode formats invented since 1958 with the introduction of UNCOL and subsequent attempts?
Compared to other bytecode formats, it has lots of advantages. Browsers support it, LLVM targets it, people are using it.
I don't really see the point of using WebAssembly (or any other bytecode format) outside the browser, though. It just seems like a way to throw away performance for no benefit.
Browsers support it because Mozilla refused to adopt PNaCL, which was also targeted by LLVM, WebAssembly is a political compromise, not any kind of technical achievement as it keeps being celebrated for.
Mainframes and midrange computers have used bytecode formats since the early 60's as hardware independence mechanism, where you AOT compile at installation time, or have an hardware interpreter implemented as part of a micro-coded CPU.
It has allowed those kind of computers to advance their hardware to modern times, while keeping the applications unchanged.
The same idea is widely used on embedded platforms, as it gives OEMs flexibility designing hardware, while reducing software development costs even further.
I honestly do not see the point you are arguing "for" here. I understand you find wrong the hype about webassembly and many of you comparison are adequate.
You say that wasm is a political "bastard" born out of mozilla refusal for PNaCL. I disagree, but it is a way of looking at history.
But then my stance would be that to satisfy the w in wasm it Needs to be a political chimera, the whole web is predicated on the model of vendors fighting political and technical battles over standard. PNaCL lost that battle, Java lost miserably that battle, every other portable assembly ever never even participated.
Not a technical achievement so much as a different point in the design space. Two key differences. First, NaCl was originally designed to run in its own process, for a few different reasons:
- The original 32-bit x86 implementation fundamentally required it because, due to how it used %ss, a crash in the sandboxed code would crash the whole process. [1] Avoiding that issue would have required a different model that had performance overhead (and was more complicated). Ironically, the 64-bit version had no such requirement, but by then NaCl's design was already well-established.
- AFAIK it was originally developed separately from Chrome, so there was less motivation to deeply integrate it with JS.
- It was apparently conceived as a replacement for plugins (originally using NPAPI, before PPAPI was invented), which Chrome had run in a separate process anyway.
But WebAssembly is designed to run in the same process as DOM/JS, giving it two key advantages: it can reuse Web APIs rather than needing a whole separate set of APIs (PPAPI), and it can directly call and be called from JS. Both make life easier for developers; reusing web APIs also makes life easier for implementers.
The second key difference is that NaCl leaks much more information about the native environment than WebAssembly. Even with PNaCl, the native text segment, the native stack, and certain bits of implementation code were all accessible within the sandboxed address space. If you were up to shenanigans, you could even do things like jump into the middle of a native function, completely breaking the portability abstraction. Was that a problem? I don't know. It was conceptually secure; you couldn't break out of the sandbox without finding a vulnerability, just like WebAssembly. But it was a lot less isolated. In contrast, WebAssembly makes none of those things accessible and enforces full control flow integrity. You can't even tell which architecture you're running on, aside from indirect observations by benchmarking instructions or checking for memory ordering violations.
That difference is certainly responsible for some of the performance gap between NaCl and WebAssembly. Is it responsible for all of it? I don't know. I don't even know how big the gap is in the first place; the PDFTron benchmark makes it look major, but I haven't seen any other benchmarks, and I'm not sure if anyone has investigated what exactly is causing the overhead in the PDFTron benchmark, especially since the code isn't open source.
