Google wasted huge resources on an approach which it was obvious from the beginning would never lead to a Web standard. Mozilla people, including me, told Google people even before PNaCl appeared that introducing the whole new non-standard Pepper API was unacceptable.

> Google wasted huge resources on an approach which it was obvious from the beginning would never lead to a Web standard

Google has been doing this for a long time, I doubt it's unintentional. If there is functionality that they want which is not standardized, they go ahead and implement it. When a workable standard is ready or detailed enough, they switch over to it. The earliest instance of this that I can recall was Google Gears, which was deprecated by LocalStorage. There probably are earlier examples.

Sure but the asm.js/Wasm approach was always an option. They didn't have to go down the path they did.

NaCl predates asm.js/Wasm by 2 years: it wasn't always an option

Here's a timeline:

  2011-10-16: Native client released
  2013-03-21: asm.js released
  2013-06-25: Firefox 22 released with asm.js support
  2013-07-17: Chrome 28 released with optimizations for asm.js
  2015-06-17: WebAssembly released
  2017-06-30: Google announces switch to Wasm.

When do you think was a Good time for Google to switch tracks?

Was it an obvious option? I don't think I'd give the asm.js and WebAssembly developers so little credit.

Mozilla people and Google people talked to each other long before those releases.

> If there is functionality that they want which is not standardized, they go ahead and implement it.

... in a non-standardizable way.

Why not try to help create a standard instead? What's the benefit of starting with a dirty approach and deprecating it later?

It's best to have couple of working/competing implementations first before defining a standard.

> Why not try to help create a standard instead?

They do that as well, it's not one or the other. Google had employees working on WebAssembly (along with Mozilla, Apple and Microsoft). Standards take time to be developed and finalized.

Google had a lot of people working on NaCl and PNaCl for a long time before they started working on WebAssembly.

> Google had a lot of people working on NaCl and PNaCl for a long time before they started working on WebAssembly

That's probably because NaCl(2011) and PNaCl predate WebAssembly (announced 2015). Google was optimizing Chrome for asm.js as far back as Chrome 28 (July 2013) - less than 5 months after asm.js was announced.

Because people prefer something broken now then something good later.

> Google wasted huge resources on an approach which it was obvious from the beginning would never lead to a Web standard.

But it did lead to a web standard, even if it didn't become one. And in the interim, it provided utility to Google.

> Mozilla people, including me, told Google people even before PNaCl appeared that introducing the whole new non-standard Pepper API was unacceptable.

Yeah, you've mentioned that quite a few times. So what? Unacceptable nonstandard moves are a big part of what stimulates standards progress.

If spending any amount of resources to get any amount of utility counts as success, then there is no such thing as failure.

Google makes money from the web. Massive amounts of money. Something like 93% of their revenue. If WebAssembly leads to the decline of mobile apps, the amount of resources that Google spent on PNaCl is so tiny compared to the amount they will make by continuing to own the world of online advertising.

Just so I get your argument straight, you're saying that launching a proprietary competitor to the standard means you're helping the standard?

Because then we owe Microsoft and Apple a shitload of thanks.

> Just so I get your argument straight, you're saying that launching a proprietary competitor to the standard means you're helping the standard?

No, I'm saying that launching a nonstandard solution to a problem without a standard solution or where there are discontents with the standard that are not being addressed is the usual way new standards are motivated, whether the new standard is based on the nonstandard solution or developed in reaction to it.

Standards (and even moreso, standards that are actually implemented rather than being mere paper triumphs) somewhat backward-looking rather than out-of-the-blue.

A commitment to standards isn't about not implementing nonstandard things, it's about engaging in the standards process to help get to a robust standard and then implementing it (replacing nonstandard solutions, if any) when it is clear what the consensus standard will be.

(And I use "nonstandard" rather than "proprietary" because standard/nonstandard is a different axis than open/proprietary.)

> Because then we owe Microsoft and Apple a shitload of thanks.

Well, yes, a lot of current web standards were originally either nonstandard solutions from Microsoft or Apple or alternatives developed in response and motivated by such nonstandard solutions, so, sure, they've driven a lot of the progress. I think they've generally been less good about (at last, slower) participating in standardization of an alternative when their original solution isn't acceptable to other players, but they have definitely been change drivers.

Actually a commitment to Web standards does mean a commitment to not launching nonstandard extensions to the Web platform, usually. Many of Chrome's own Web standards people would tell you this. For PNaCl and some other features Google's official excuse was to designate them "not part of the Web platform" ... which doesn't really make sense from anyone's point of view other than Google's.

In this case, the desirability and feasibility of running C/C++ code on the Web was not something that needed to be demonstrated by enabling PNaCl for Web content. In fact, uptake of Web-PNaCl has been extremely low --- fortunately. If significant Web-PNaCl uptake had been a prerequisite for WebAssembly, then WebAssembly probably wouldn't have happened!

This is very close to "4D chess" reasoning

The problem was precisely the Pepper, a pile of API that Google thought they could force on everybody, not PNaCl per see. If the initial NaCl implementation just exposed the pre-existing Web API into the native code sandbox without adding anything extra, the story can be rather different and a version of PNaCl could be standardized.

That's true, although NaCl's design made that difficult because the native code sandbox had to be a different process so interacting with the page's DOM would have required IPC.

I am curious what made it necessary to run NaCl in a different process? I thought the main idea behind NaCl was to allow the same-process native sandboxes.

According to https://static.googleusercontent.com/media/research.google.c... NaCl does not sandbox loads, relying on address-space separation to ensure secret data is not leaked. Obviously this only works with a single sandboxed application per address space. (And even then you'd have to be pretty careful!)

This is only for NaCl on ARM or AMD64. The original NaCl for x86 uses the segment registers for isolation allowing to restrict both loads and stores only to the permitted addresses. That, as far as I understand, does allow to embed into 32-bit process without compromising secretes.

So as a speculation in an alternative world where Google has not developed Pepper, but bridged web api into x86 NaCl, the latter designs for x64 and ARM would restrict loads only from the allowed address space.

https://static.googleusercontent.com/media/research.google.c... shows that the original NaCl-x86 only allowed one sandboxed application per process. So to support pages with more than one plugin, IPC would have been needed.

Sure, (P)NaCl could have been implemented differently in a way that allowed multiple sandboxed applications per process, and then DOM access would have been easier and maybe Pepper wouldn't have been necessary, though there would have been slightly higher overhead I guess.

That's all history now.

Probably for the same reason Chrome runs V8 in a different process: planning for inevitable vulnerabilities in the implementation.

Chrome doesn't run V8 in a different process from the page DOM. That's the difference: NaCl/PNaCl _does_ run in a different process from the page DOM, so interacting with the DOM gets complicated.

Reminds me of Cunnigham's Law: "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."

I love that law. I've been putting it to use ever since I read that.