Last week, I was giving a lecture on HTML5, starting with the origins of the Web, HTML, and the "browser wars." I indicated that the browser wars were an attempt by two companies (Netscape and Microsoft) to add tags without checking with anyone else, in the hopes of getting market share.
As I got to this point in the lecture, I paused, and realized for the first time that Google is often playing a similar game with Chrome.
Everyone agrees that standards are time-consuming, bureaucratic, and prone to all sorts of compromises. But the goal of standards isn't the speed of the process, but rather the inclusiveness of the process. (And yes, you can make a case for the W3C not being so inclusive...)
It's great that Google is interested in treating Chrome as a laboratory for new Web technologies, but I think that some added humility would be in order. It's one thing to say, "We think that this might work well, and are throwing it out there to see what will stick, keeping the good stuff and throwing out the bad." But instead, they seem to be saying, "We think that this is good enough for a standard, never mind the process." And that can't be good for the Web.
That is how roughly all progress on the Web ever has happened. The existence of HTML5 is a testament to that — the W3C was lost in the woods for years and years trying to make XHTML 2 with nothing to show for it. Meanwhile, the browsers were coming up with their own ideas. So the WHATWG came along and specified what the browsers were already doing, as well as a few simple improvements. I think we can all agree HTML5 was a good thing. Well, if you think so, then you agree that progress coming from the browser implementers is often a good thing.
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.")
> 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.
As I got to this point in the lecture, I paused, and realized for the first time that Google is often playing a similar game with Chrome.
Everyone agrees that standards are time-consuming, bureaucratic, and prone to all sorts of compromises. But the goal of standards isn't the speed of the process, but rather the inclusiveness of the process. (And yes, you can make a case for the W3C not being so inclusive...)
It's great that Google is interested in treating Chrome as a laboratory for new Web technologies, but I think that some added humility would be in order. It's one thing to say, "We think that this might work well, and are throwing it out there to see what will stick, keeping the good stuff and throwing out the bad." But instead, they seem to be saying, "We think that this is good enough for a standard, never mind the process." And that can't be good for the Web.