> asm.js was Mozilla’s response to the question posed by NaCl and PNaCl: how can the web run code at native speeds?

Had it been today, Chrome would have just pushed NaCl and PNaCl no matter what, and then everyone would complain why Safari and Firefox aren't keeping up with "Web" standards.

▲

xyzzy_plugh 3 hours ago | parent | next [-]

I still maintain the notion we're in the wrong timeline, one where PNaCl died and instead of a worthy, timely successor we end up being boiled alive in a soup of Electron apps.

I really thought, for a time, that we'd be doing everything in the browser. And in a way that's increasingly true, but it all just feels worse than ever. I like WASM and I want to like WASM but the rate of maturity within the ecosystem is incredibly abysmal.

What's worse is that we should all be running our untrustworthy AI tools and their outputs in precisely such a sandbox, and companies are selling the reverse: hosted sandboxes, hosted JS-based VMs.

I guess that was always the problem: there was never any money in a client-side sandbox.

▲

alex7o 2 hours ago | parent | next [-]

I do understand why NaCL and PNaCL are undesirable and why wasm is much better, but as a student the NaCL ssh app had saved my computer science homeworks more than once, and this is something that still doesn't have an alternative although I rarely would need it nowadays.

▲

hoppp an hour ago | parent | prev | next [-]

Its like natural selection, maybe not the best traits win overall but one that is the most popular choice because everyone is a webdev.

▲

tardedmeme 3 hours ago | parent | prev [-]

What are the key differences between PNaCl and WASM?

▲

flohofwoe 2 hours ago | parent [-]

There were 3 systems, all with interesting differences.

The original NaCl was a 'validated subset' of native CPU machine code (e.g. actual x86 machine code with some instructions and instruction sequences disallowed which would allow to escape the sandbox).

The next iteration was P(ortable)-NaCl which replaced the native machine code with a subset of LLVM bitcode, which was then compiled at load time. Unfortunately with this step NaCl lost most of its advantages. Startup time was atrocious because it was basically the second half of the LLVM compilation pipeline (from LLVM-IR to machine code). LLVM-IR also isn't actually great as CPU-agnostic bytecode.

WASM was designed from the ground up as CPU agnostic bytecode that's also much easier and faster to validate.

The only major advantage of PNaCl vs early WASM was that PNaCl supported shared-memory threading right from the start (this is still knee-capped in WASM because of the COOP/COEP response header requirement).

...apart from Emscripten => asm.js => WASM, and Google's NaCl/PNaCl there was also a system by Adobe (Flascc/Alchemy(?) I forgot all the names this went through) to compile C and C++ code into Adobe Flash bytecode.

I have an ancient blogpost from 2012 which compares the three (and where I have been flabbergasted by how well Emscripten actually worked - and this was even before asm.js - the linked demo is unfortunately no longer up):

https://floooh.github.io/2012/10/23/mea-culpa.html

▲

Randomno an hour ago | parent | next [-]

> (Flascc/Alchemy(?) I forgot all the names this went through)

Crossbridge was its third and most recent name.

Pepper.js is another interesting project from around this time that didn't pan out.

https://github.com/google/pepper.js/

▲

Yoric an hour ago | parent [-]

Wasn't pepper the P in PNaCl?

▲

Randomno 44 minutes ago | parent [-]

The P in PNaCl is Portable.

Pepper was a pun on Native Client (since NaCl = salt). Pepper Plugin API (PPAPI) was Google's more secure version of NPAPI (Netscape Plugin API). Flash Player was essentially the only thing using NPAPI/PPAPI by the end of its life.

	▲	jcranmer 22 minutes ago \| parent [-]
		The most common plugins were Flash, Silverlight, Adobe Reader, and the Java applet plugin, and I think all of those were in mildly common use when plugins were on their last legs.

▲

bawolff 2 hours ago | parent | prev [-]

> The only major advantage of PNaCl vs early WASM was that PNaCl supported shared-memory threading right from the start (this is still knee-capped in WASM because of the COOP/COEP response header requirement).

Presumably that is because PNaCl predated spectre (?)

	▲	flohofwoe 2 hours ago \| parent [-]
		Indeed, NaCl and PNaCl would have been hit by Meltdown/Spectre at least as badly as SharedArrayBuffer.

▲

benced an hour ago | parent | prev | next [-]

You mean Chrome would have pushed it, Apple would have filibustered it by refusing to comment (via lack of investment in the WebKit team), and then gullible folks on the internet would defer to them.

(I will note that Apple seems to have upped WebKit investment this decade since their regulatory problems started in earnest - so it's possible this would end differently today)

▲

lmkg 2 hours ago | parent | prev [-]

I mean that's still basically what they tried to do at the time. They were trying to get them through web standards committees and everything.

IIRC a big reason it didn't end up working was because NaCl was such a "big" technology and asm.js such a "small" one that asm.js was able to reach production-ready first despite starting work several years later.

	▲	pjmlp 2 hours ago \| parent [-]
		The big difference was that they lacked the market share they enjoy nowadays, with their forks and Electron crap.