Hacker News Reader

Comment by ithkuil | Hacker News Reader

NaCl solved that long time ago

NaCl was CPU specific, and the way they solved this problem with PNaCl (by using a subset of the LLVM IR) was more or less a hack which most likely involved at least as much machinery in the browser as a WASM runtime (and it compiled slower and also performance wasn't any better than even the first WASM runtimes, the only thing that PNaCl had going for it was straightforward multithreading support, which took far too long to materialize in WASM - on the other hand, Spectre/Meltdown would also have affected PNaCl hard).

Having worked with asm.js, NaCl, PNaCl (plus a couple other long forgotten competitors like Adobe's Alchemy/Flascc) and finally WASM: WASM is the natural result of an evolutionary process, and considering what all could have gone wrong if business decisions would have overruled technology decisions, what we got out of the whole endeavour is really pretty damn good. It's really not surprising that Google abandondend PNaCl and went full in on WASM.

Yeah, WASM was the result of taking a look at NaCl, realizing it could never be specified and independently implemented, and writing a spec for something better that could.

WASM is superior in pretty much all ways to NaCl other than being a bit more time to go through the whole specification and implementation process. NaCl was a great prototype, and WASM is a much more polished result because of it.

Ooh, I'd love to know a few more details about both.

What kept NaCl from being independently implemented? And what did WASM learn from NaCl?

Edit: ah, someone already mentioned NaCl being CPU-specific.

(P)NaCl was just too close to the past, roo many memories of activeX, flash and other crap still loomed heavy in people's hearts and they wanted a clean cut with the past, an open web, free from the dictat of corporations etc.

I do understand why people wanted something different and rejected (p)NaCl. But the reason is not technical, it's political (in the broad sense). Any technical issues could have been solved by fixing and extending (p)NaCl, but everybody involved understood it was not going to work

I used to work in the Native Client team at Google, both on regular NaCl and pNaCl. It failed for technical reasons too. And maybe, mostly for technical reasons.

pNaCl's biggest mistake was using LLVM bitcode as a wire format (see, for example, [1]). Another problem was trying to use glibc, instead of newlib. That resulted in a lot of low-level incompatibilities, as glibc itself is too target-specific. And implementing shared objects between portable and native world was really messy.

asm.js appeared as a simpler alternative to NaCl, and then it was quickly replaced by wasm, developed mutually by Mozilla, Google and others.

1. https://groups.google.com/g/native-client-discuss/c/h6GJ8nQd...

it solved it so well that nobody outside of chrome ever implemented nacl, and chrome's nacl team became their webassembly team

That's perfectly compatible with the claim that from a technical pov pnacl solved the issue.

There were other good reasons why that wasn't ultimately the road taken, but they largely were know technical reasons.

Context for anyone that's unfamiliar - this is referring to e what Wikipedia calls "Google Native Client" [1], not the cryptography library.

[1] https://en.m.wikipedia.org/wiki/Google_Native_Client

Reply on news.ycombinator.com