> The problem in the browser wars was that they were trying to be incompatible, which is not really the case with Google. (Remember, Microsoft's model was not "Embrace, extend, evangelize.")
This is sometimes the case for Google's technologies as well. PNaCl is pretty much impossible to embed into other browser engines because of the dependency on Pepper, which is very Chromium-specific and there has been no attempt at all that I'm aware of to standardize it. (Pepper even has undocumented stuff that Flash uses!)
Honesty, if there was an attempt to standardize it, what would Mozilla's reaction have been anyway? Mozilla seems completely invested in JS for everything and hostile to any competing technology for execution in the browser. It seems the result would be pretty much the same.
It's not like Mozilla doesn't do things for expediency when they need ability to iterate quickly, e.g. The WebAPIs effectively ignoring the existence of similar DAP efforts, and then having to turn around and rationalize them with the previous work. If you need to ship a physical phone with Firefox OS, and the manufacturers are waiting, are you going to block on W3C, or ship with proprietary or un-ratified device APIs?
We pretty seriously looked at PPAPI back when Adobe announced effective end of life for NPAPI Flash on Linux.
If PPAPI were not as tied to Chrome's internals as it is, we might in fact have implemented it.
As far as being invested in JS, I think it's more being invested in managed code. Our experience with NPAPI is that you end up with the unmanaged code depending on all sorts of implementation details because it can. The classic example is that all NPAPI Flash instances across have to be in a single process, because they assume they share memory. And the browser can't do anything about it, since it's not involved in the memory sharing bits in any way. Similarly, the fact that NPAPI plug-ins can do their own network access makes them hard to align with CSP and the like. Managed code can start to depend on internals in weird ways too (e.g. sync access to cross-origin window bits), but you have more chances to pull the wool over its eyes in some way (e.g. blocking cross-process proxies).
Once you accept managed code, JS seems like as good a place to start as any, with at least the benefit of being there to start with. ;)
There are, of course, obvious drawbacks to the all-JS approach, starting with the fairly lacking parallelism story. At least now we've grown Workers, and there's work on things like SIMD, ParallelJS, etc. Then again, the one major language addition to a browser VM recently (Dart) didn't exactly address this need either....
I worked on Adobe's Flash Player team when Chrome was pushing PPAPI. Adobe engineers were strongly opposed to PPAPI because it was complex and incomplete (and it was only implemented by Chrome). The only reason a Flash PPAPI plugin exists for Chrome is because Google did the work.
> Honesty, if there was an attempt to standardize it, what would Mozilla's reaction have been anyway? Mozilla seems completely invested in JS for everything and hostile to any competing technology for execution in the browser. It seems the result would be pretty much the same.
There was a thread on plugin-futures about Pepper way back in 2010, when this effort was getting underway. Every other browser manufacturer suggested using the Web APIs instead of Pepper. Google ignored the consensus and did Pepper anyway. Looking back, from everything I saw the other browser manufacturers were right—asm.js now has an advantage in that it can use the standardized Web APIs. If Google had listened to the other browser manufacturers, it might have turned out better for PNaCl.
Seems like they had legit reasons at the time, given the goal of getting games written for it, and the fact that the WebAPI didn't support multithreading nor synchronous for some common operations.
I don't know what the reasoning then was, but it seems to me that if you goal is to get games to port C code, it's a lot less re-engineering if you have threads and blocking ops. I've ported multithreaded apps to the web and de-threading them is a major headache.
Again though, if there were no pepper, do you really think Mozilla would have adopted NaCL?
On a side note, Firefox 27 finally killed the last vestige of NPAPI exports that we needed to make GWT Dev Mode work (side side note: Chrome killed us first deprecating NPAPI). Here's a case where WebAPI equivalents don't work. Not even PPAPI can work. GWT Dev Mode very specifically relied on synchronous access to JS APIs. Point is, shoe-horning everything in the browser event loop is not the ideal location or design for every API. Sometimes you do need something outside the WebIDL bindings.
I agree, that's one case where the criticism is probably right on the nose. But I don't think it can be generalized to everything Google does. PNaCl is the odd one out, not so much the norm.
This is sometimes the case for Google's technologies as well. PNaCl is pretty much impossible to embed into other browser engines because of the dependency on Pepper, which is very Chromium-specific and there has been no attempt at all that I'm aware of to standardize it. (Pepper even has undocumented stuff that Flash uses!)