I think they might also see NaCl as helping drive Chrome's growth, when suddenly a browser can do cool stuff that other browsers can't.
EDIT: I'm old enough to remember the browser wars, but I really like most of the trends that Google/Chrome have introduced, from auto-updates to revving the JS engine to fallback-capable SPDY.
ActiveX's downfall was a lack of security and relatively high complexity (the two are often related). Google, so far, has had quite a good run in those areas.
No, ActiveX's downfall was that it wasn't part of the open-web. If ActiveX had bullet-proof security, it still would have failed because you'd still only have IE supporting it. In NaCl's case, Chrome will be the only browser to ever support it, which means it is just a nicer flavor of ActiveX, and likewise, I hope it lands flat on its face.
Native Client is completely open: the executable format is open and the source code is open. Right now Native Client is in its early stages, so it's premature to consider Native Client for standardization.
If it lives up to its promise, and Chrome is the only browser to support it, then it says more about the other browser vendors than anything.
Just because something is a standard in no way means one way or another that browsers should actually support it. For example... C# is a non-proprietary approved spec by ECMA, but you don't see that inside of a web browser.
If something is standardized and approved by the W3C or WHATWG, and no other browsers support it, then yeah, come back and we'll chat. But that's not going to happen anytime soon. Until that happens, it shouldn't be inside of a web browser and promoted as web technology.
WHATWG is a sock puppet for the browser vendors. So saying 'the browser vendors ought to support something only if WHATWG approves it' would effectively be to say that 'the browser vendors should support something only if the browser vendors collectively want to support it'. That's obviously an argument one could make, but it would be better if one started by dropping the fiction that WHATWG is some sort of neutral party or independent source of legitimacy.
In fairness, the argument you actually made is 'the browser vendors ought to support something only if WHATWG or W3C approves it', which expands to 'the browser vendors should support something only if the browser vendors collectively want to support it, or if W3C approves it'. But that leads to obvious questions. Why is W3C approval critical for technologies of which the browser vendors collectively disapprove, but of distinctly secondary importance for the technologies they collectively like? And when was the last time the browser vendors shown much sign of meekly accepting W3C-approved technologies of which they disapprove? It seems very much as if the WHATWG HTML coup was not only about adopting features which the browser vendors wanted but which W3C was slow to standardise, but also about stymieing features which the W3C approved of but which the brower vendors don't like (like RDFa, namespaces, and HTML modularisation). So setting the W3C up as an alternative gatekeeper here seems almost as cheeky as advancing the WHATWG.
The WHATWG strikes me as exactly what a standards org is supposed to be: enough vendors to form an industry consensus get together and agree to cooperate on certain things for their collective benefit. Or is that the point you were making?
WHATWG is certainly efficient at advancing the collective interests of the browser vendors. The problem arises when those interests conflict with the interests of the rest of humanity.
Yes. For example it may say that other browser vendors care about things other than x86/x86-64 and ARM (which are all Chrome cares about; it doesn't run on any other architectures).
Of course if you _want_ use of the Web to be tied to particular hardware architectures, then Chrome's push with NaCl is ok. But some people and organizations consider such ties to be a really bad idea.
ActiveX was a threat to the open web not because it used native code but because it depended on the Windows API, which was enormous and deeply coupled to the architecture of Windows. For this reason, implementing ActiveX on other platforms was not even an option.
It's the same story with every technology Microsoft tried to embrace, extend, and extinguish. It was Windows and its API that gave them the power, not any programming language or compile target.
In light of that, NaCl is not at all the same beast as ActiveX. It doesn't matter that nobody else is implementing it now, as long as they can implement it, should it one day become strategically important.
If Google has a secret weapon equivalent to the Windows API, it's their suite of cloud services. When you catch them using their browser to lever people onto Gmail and G+, that's when it's time to cry foul.
How is depending on the x86 and ARM hardware architectures significantly better than depending on the WinAPI? It still locks out some people who can currently use the Web just fine from using content just because of the computer hardware (or OS in the case of WinAPI) they've chosen to use. This is a still a bad thing, just like 10 years ago.
The difference is that NaCl applications can be trivially recompiled for a new architecture. There is a water-tight abstraction layer there. Windows programs, in general, can't be trivially ported to another OS because they are tightly coupled to Windows all the way up the technology stack.
That said, I wouldn't trust web developers to promptly recompile their apps for new architectures, so the LLVM approach is greatly preferred.
NaCl is not going to have the same ubiquity as the web proper. It's a way to deliver applications over the web, not web sites.
> The difference is that NaCl applications can be trivially
> recompiled for a new architecture.
Except they can't, in many cases. Recompiling for a new architecture is rarely trivial.
More importantly, there would be no impetus to recompile for a new arch with low market share, so its users would be just as locked out of NaCl stuff as if it _were_ trivial to recompile.
> so the LLVM approach is greatly preferred.
Except LLVM isn't architecture-agnostic, in general.... just doing LLVM lets you abstract away some aspects of architectures, but by no means all.
> It's a way to deliver applications over the web
Sure. But it would sure suck if you had to get Google to recompile gmail for your new architecture in order for your users to have access to it, as opposed to just writing a JS interpreter or JIT for your architecture!
And gmail and its ilk are _exactly_ what NaCl is trying to target.
"Chrome will be the only browser to ever support it"
Doesn't have to be that way It's only supported in Chrome because Mozilla is refusing to implement it for not
other reason than... I really don't know what their reasons are. There is even a plugin for firefox. Google has accepted a ton of Mozilla invention even killing some initiatives like O3D in favor of WebGL. And plenty of other such bridging moves. I'm not seeing the love from the other side but I might be reading the situation wrong. I have no internal info as too how the debate went over NaCL.
Also, NaCL is being use by Google for some scientific computing stuff where they put scientific code written by external scientist and run it in Google datacenters. I'm starting to think this could be kickass for cloud apps.
Please explain to me why it should die?
Now to be fair, Mozilla is going to have something similar in potentially WebCL. But it's not exactly the same thing but close.
...Mozilla is refusing to implement it for not other reason than... I really don't know what their reasons are.
Probably because NaCl blasts way beyond a leaky abstraction into hard-coded dependency on a specific processor. Mozilla (I'm guessing) wants the web to be a leak-proof abstraction. There are half a dozen different architectures on which one may want to run Firefox (x86/x86-64, PPC, ARM, Sparc, MIPS, etc.). NaCl requires in-depth security analysis and implementation for each platform, plus every web developer would have to compile and test a version of their code for every platform (or, more likely, they'll just support x86, maybe ARM).
PNaCl using LLVM would be slightly better, but WebCL is probably the best approach to number crunching in web apps. Security is also easier at a higher level of abstraction.
Surely you mean x86. Firefox Mobile for Android (ARM) has been out for months. And x86_64 builds are already in existence and are slated for Firefox 8.
Firefox has x86, x86-64, and ARM as tier-1 architectures.
It has a whole bunch of tier-2 architectures that are supported but to a lesser extent (e.g. a patch that breaks one of them doesn't automatically get backed out immediately). People are shipping and using Firefox on various of those architectures, including JS jits on at least Sparc and PPC.
XMLHttpRequest was pioneered by Microsoft Internet Explorer 5 in 1999. (Notably, it was in the form of an ActiveX control.) Mozilla first shipped an emulation in December 2000.
Popular ajax web applications were shipped as early as 2000 (Outlook Web Access) and 2002 (Oddpost). The term "ajax" was coined in Feb 2005, around the time of Flickr (2004), Gmail (2004), and Google Maps (2005). But of course the coining of term was a recognition of something that was already happening, not the spark.
The w3c standardized XHR in April 2006, but I think WhatWG may have spec'd it earlier. I can't find the history.
The same thing happened with the DOM, though much quicker. Something you'd recognize as the modern DOM was first shipped by IE 4, in 1997. The first bits of it were standardized by DOM level 1 in late 1998, with most of the rest coming from DOM level 2 in late 2000. The first Netscape implementation was shipped in 2000 (Netscape 6.0).
My point here is that many successful web technologies began just as NaCL is beginning. Technologies have frequently become part of "the open web" through this exact process.
While I believe NaCl is radically different in nature compared to the DOM or XHR additions, regardless, web standards development is a much different game today than it was 5, let alone 10 years ago. We aren't talking about Apple experimenting with some "webkit-" CSS additions, this is something that will essentially use HTTP to deliver C/C++ application code to computers. It's a big deal if it is to become part of the Open Web, and NativeClient has received zero interest thus far from other browser makers. Because of that, it will likely never be a WHATWG approved spec, and this is no secret to Google.
The point of my post that you originally commented to was that web technology needs to be supported, cross-browser, to gain a foothold. NaCl will not see that, yet Google is actively promoting it as part of the web (see announcement blog post).
EDIT: I'm old enough to remember the browser wars, but I really like most of the trends that Google/Chrome have introduced, from auto-updates to revving the JS engine to fallback-capable SPDY.