The failure of pnacl isn't primarily technical, it's political. I think the core tech (verifiable secure native code) is awesome. Many people in high places in non-Google browsers object to pnacl on several fronts. The crux of which seems to be that there is not a smooth transition story from JS->PNaCL. Getting JS and PNaCL to inter-operate, share implementation/memory/APIs is a problem. A bigger problem is the need to get all of the browser vendors (including IE and Safari) in agreement and on board synchronously to avoid years of "works only in Chrome and X".

Asm.js "cheated" by creating a path forward that did not require consensus. Mozilla used it to innovate without needing to argue with anyone else. For other vendors, asm.js would technically "work" without other vendors putting in any technical or political investment. But, the hook was that if they didn't get on board eventually, their browsers would start to look bad if they ran asm.js sites poorly.

WebAssembly is the outcome of Mozilla's trick. Now that all of the vendors have slowly become convinced over a period of years that there is a smooth, gradual path forward over the next several years that does not involve any technical or political chasms to cross, they are starting to work together to make it happen.

I think the main issue was it's reliance on the Pepper Plugin API. Which several people have said was mapped closely to Chrome's software architecture.

Technically it was a plugin for Pepper and the only difference between it and Flash was that it was open source and only available to Chrome.

In discussions of objections, Pepper comes up a lot. I don't understand the situation well enough, but that always seemed to me like throwing the baby out with the bathwater. The secure, native, binary executable is the big deal. The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable. Not "flip a switch" fixable, but "Let's work together to figure out a better API" fixable. But, the idea that the huge, Chrome-specific API would be required to be incorporated into every other browser as-is and could not have been replaced in the last six years seems to be assumed as a fact of life.

> The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable

Agreed. Web Assembly is the solution :)

Portable Native Client is a really huge project that takes a lot of PhD-level talent to implement correctly, and it requires a very specific type of organization that has the requisite "will" and "way" to make it happen.

Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large sums of money for long periods of time... which is obviously something that Google can afford to do.

I think everyone has always known that NPAPI was eventually going to have to be completely overhauled or even replaced. For anyone to constantly harp on the idea that "all that matters is the open web" when they come from the very same organization -- although going by a different name -- for which the original binary plugin architecture was named (Netscape Plugin API) is just patently absurd.

There is so much quality, freely available C/C++ code in this world that it is pretty mind boggling, and the purely technical achievement of allowing this code to be efficiently used by end users through the web platform is, again, a fairly mind boggling idea.

I'm not saying that this web assembly concept won't have any use cases whatsoever in the future, but I am saying that the proven PNaCl technology that exists right now is way, way too powerful for any web-based applications developer worth his or her soul to pass up very easily.

> Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large sums of money for long periods of time... which is obviously something that Google can afford to do.

And implementing a modern JS engine isn't? Or developing Rust? Come on.

The objections that many other browser vendors have to integrating PNaCl into the Web platform have been detailed repeatedly and have nothing to do with "X browser vendor doesn't have the talent on staff to implement the technology".

If Adobe Flash was a failure, I only hope I can fail as well and as strongly in my life...

Yeah, I was referring to pnacl (as in Portable Native Client), but that is a very good point about a technology that is obviously still going strong all these years later.

Either he's mixing narratives here or he's using standard web development practices as the context of it failing.

Today using Ajax is better practice because it integrates better with the browser and it'll work on mobile.

Supported by a single browser and based on a single (and the same) vendor's spec, which needlessly duplicates about half a web browser's functionality using a brand new API, and with no support due for other browsers any time soon

False.

From the Native Client wikipedia page:

As of 13 May 2010, Google's open source browser, Chromium, was the only web browser to utilize the new browser plug-in model.[28] Mozilla has announced that they are "not interested in or working on Pepper at this time."[29] As of 2015, Pepper is supported by Chrome, Chromium and Opera.

All of which are functionally the same Blink-based browser, so you're splitting a really fine hair.

Okay, so let's examine the remaining browsers, shall we?

Safari and IE/Edge automatically don't matter because they are exclusive to their respective [proprietary] host operating systems.

That leaves Firefox.

Does anyone really think there is legitimate competition between Chrome and Firefox anymore?

I mean don't get me wrong, Firefox was a godsend in the bad old days of M$IE domination...

But this is 2015, and Google is basically Skynet, while Firefox is not much more than a warm, fuzzy memory.

Seriously... does anyone really want to turn this into a battle between Google and Mozilla?

What? Whether or not a browser matters depends on the amount of people using it, not on whether you can install it on several operating systems.

If someone is trying to turn this into a moral discussion about the positive value of the so-called "open web" to humanity, then the question of whether the actual codebase is open-source, and runs on every platform is of primary importance.

My original reply was to a part of the article that talked about the "evil" non-open nature of web-technologies that are not humanly readable, textual HTML/CSS/JS. Then someone replied that PNaCl is only supported by a single vendor. Then I said that was a factually incorrect assertion, with the response being that I was engaged in hair splitting.

So then, I suggested that we should examine the rest of the vendors. In the morals based context of this entire subthread, I think it is plainly obvious that Safari and IE/Edge don't have any place here, when it comes to the question of whether PNaCl is a "good" technology, based simply on the question of the proportion of vendors that happen to support it.

If you are instead talking in a purely pragmatic, capitalist sense... then of course all that matters is brute numbers. But then there is no real discussion to be had, because in the cold, hard business world, whoever wins is just whoever wins. A equals A. It's a mere tautology.

If the measure is moral rectitude, how is Firefox a "fuzzy memory", while Chrome isn't despite Google being "basically Skynet"?

Your whole line of argument is confusing.

And we used to think x86 was a bad design of native code.

PNaCl is no more a Google-proprietary feature than XMLHttpRequest is a Microsoft-proprietary feature. Anyone else is free to implement it, and then Google would have no more control over the "spec" of PNaCl than Microsoft has control over the evolution of AJAX.

Last I looked into this, the (P)NaCl codebase was heavily enmeshed with Chromium. Documentation on how any of it fit together was spread out across a multitude of wiki sites and mailing list archives, with conflicting descriptions of the exposed interfaces in varying states of obsolescence. The "spec" was, effectively, this big tangled ball of code in the Chromium tree.

The one method of running NaCl programs on their own relied on thousands of lines of Python code spread across a nested hierarchy of frameworks just to generate command line arguments to pass to the main runner binary -- and this used completely different interfaces into NaCl from Chromium's implementation. And all of this, being tightly integrated into the Chromium codebase, was subject to change at any point with no guarantee of API stability.

Maybe things have changed since then, but at the point when (P)NaCl was receiving the most attention I found it entirely impenetrable. Though the code may have been open source, the knowledge needed to integrate it with a new system was entirely proprietary. And anyone doing so would have ended up with an implementation bound to the evolution of the Chromium internals.

Note that I'm not talking about integrating "Google's PNaCl" into another browser (that code is Google-proprietary, for your listed too-much-of-a-mess reasons if nothing else.) Mozilla et al wouldn't use Google's NaCl engine in Firefox any more than they would use Google's Javascript engine, or any more than they would have integrated ActiveX into Firefox just to call XMLHttpRequest.

I'm instead talking about implementing one's own LLVM-bitcode-compiling zero-install plugin architecture with safety guarantees derived from static analysis (i.e. what you get by implementing the whitepaper[1]), providing a similar API to plugins to NaCl's PPAPI.

The result would just be an ecosystem of "Native-binary Sandbox engines" and an API working group that is to {portable LLVM IR ISA, PPAPI} as the ECMA is to {Javascript, the browser DOM}.

[1] http://static.googleusercontent.com/media/research.google.co...

For a feature to not be proprietary in the modern browser landscape, it has to have multiple parties able to participate in the design. Including the core design decisions of "should we use JS as a basis" (the consensus solution) vs. "should we use LLVM as a basis" (the PNaCl solution).

PNaCl allows me to run vim and python natively in my browser.

Thanks.

(Shout out to my boys, Sam Clegg, Brad Nelson and company!)

Finally catching up to Firefox 1.5, eh? :) https://brendaneich.com/2005/09/python-for-xul-scripting/