Just like with TIMI, MSIL, EM, ADF, TendDRA, PNaCL among others.

> What you're saying is that every vendor shipped their software with source code and only used cross platform APIs. Is that right?

Rather that this is nothing new, and the formats listed above, already offered the same capabilities, without the same marketing.

https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/

And it doesn't offer any significant security improvements, in spite of its marketing, compiling Heartbleed into WASM is still possible.

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.

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.

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.

Are you criticizing wasm or the open web?

- 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.

[1] https://static.googleusercontent.com/media/research.google.c...

That is how it has always been done and is still done.

Yes, you can do it differently with an IL, but that isn't new either (Java, .NET, etc.).