> There's a BIG difference between "no one else will implement" and "no one else CAN implement."
That's true, but is it the right question?
Browsers could also have implemented ActiveX, back in the day. There was nothing stopping them - except that it would have been very bad for the web and for non-Microsoft OSes. Thankfully, other browsers did not implement ActiveX or else it would have still been used today.
The real issue is that no one but Google thinks NaCl is good for the web. In that sense it is similar to Microsoft with ActiveX. Of course, there are big differences too - NaCl is open source, so it would be easier to implement, if another browser changed its mind. Still, that is just a matter of technical convenience - if NaCl were closed source, the other browser vendors could still reimplement it. But again, the issue is that only Google thinks it is worth implementing in a web browser.
Kudos to Google for making it open source, but open standards are just as important for the open web.
> The real issue is that no one but Google thinks NaCl is good for the web.
Are you sure about that? I like NaCl. I don't know about depending on x86 instructions, but I like the idea of NaCl. I think it's pretty clear that the web needs some kind of low-level VM that's closer to the metal than JavaScript. It's been argued that LLVM isn't the answer, so maybe PNaCl is on the way out, but overall I think NaCl makes sense in Google's strategy: they want to see web apps take over. They want the web to replace Windows and OS X. Therefore it's natural that they want to download native or near-native code to the browser, and NaCl is just a way to do it safely. It's _not_ the same thing as ActiveX, I really believe that. However, it's clear that it's necessary to be extremely careful, and I'm not convinced they need to go 100% native -- I think a solution like PNaCl is more along the right lines. Web apps and games are not going away, and I think it's clear that we need something easier to statically optimize than JavaScript as the runtime system for the web.
Sorry if I wasn't clear before, when I said "no one but Google thinks NaCl is good for the web", I was talking in the context of browser makers. I meant the fact that Google is the only browser maker that thinks NaCl is good for the web.
> Web apps and games are not going away, and I think it's clear that we need something easier to statically optimize than JavaScript as the runtime system for the web.
We can do that in a portable, standards-based way without a complete break like NaCl with its downsides.
Consider what the PyPy compiler does to RPython: It compiles RPython, a subset of Python, down to C, by statically discovering all the types and so forth. The same can be done for JavaScript, since the performance-sensitive code people are writing is almost always statically-typed (but implicitly, without writing types) anyhow, just like RPython.
In fact we are already moving towards that now, with technologies like the global type analysis in SpiderMonkey TI. With a few more years of work, that approach should make performance-sensitive JavaScript as fast as we need it to be. There is no technical impossibility here, it just takes time - we are half-way there, with things like RPython showing this is definitely feasible.
