1. This is still a plugin. NaCl uses the Pepper plugin API. That it is bundled in Chrome doesn't make it not a plugin (Chrome also bundles Flash, and that is still a plugin.)
2. The Unity3D plugin will at least work in multiple browsers, while using NaCl will only work in Chrome.
3. It is true though that, as you say, having a plugin pre-installed as in Chrome is less scary for users. However, it still has all the other problems that plugins have, and as mentioned that it is Chrome-specific.
That's already possible with the Flash plugin using Alchemy. There are demos of several of those game engines running in it.
It is also possible to compile those technologies to JavaScript and run them without plugins at all (using Mandreel or Emscripten), but the experience would be less uniform (results would be different in different browsers), which is probably why it hasn't been done yet.
And, recently, started with NACL.
Games are extremely performance-intensive. Its simply crazy to pick a platform that is any factor slower when you have a faster alternative to hand.
NACL is a whole new level of possible. I think its going to succeed technically where Flash and plugins failed.
But consider that Alchemy will run in 98% of web browsers (because that is how much range Flash has), while NaCl will only run in Chrome. So there is a difference of about 4X in market share.
I'm not saying Alchemy is a perfect solution. Each option in this area (Alchemy, NaCl, JS) has different advantages and disadvantages.
Is 3-4X slower than native code "too slow"? Those are the results right now. And it will be much faster as JS engines continue to improve.
Think about it this way: "4x slower than native code" means that 80% of the CPU's cycles are being spent on the platform.
With NaCl, it becomes possible to instead spend most of those cycles on extra application richness without sacrificing the customer experience by requiring an installer or plugin.
Often a game will be GPU-bound, in which case the JS, Flash and NaCl versions will all have the same bottleneck, GPU shaders (in fact for this reason more and more is done in scripting languages in game engines these days). If that is the case, you might as well use JS, since it will run in many more places than Flash or NaCl.
But again, there are situations where you are CPU bound, and in that case CPU speed does matter - you are very correct in those cases. Currently JS is indeed at a disadvantage compared to NaCl in that area, however, I believe that it will match it in time (through a combination of API additions like Intel's RiverTrail, and further improvements to JS engines like static analysis). The real question is then, will NaCl fix its problems (portability, adoption in browsers other than Chrome) before JS fixes its problem (speed). My bet is on JS.
There is, to some extent; hardware acceleration for canvas. But I don't expect that to be at all comparable to native OpenGL for awhile yet. JS has certainly had some significant advances in speed over the last few years, but there's only so much optimization you can do. It's still running in a VM, so there will always be that overhead.
Another important thing to consider is that the native API will always have to exist before a Javascript abstraction can. Many triple-a titles will use brand new GPU features to sell the newest line of graphics cards. That won't work if they are making a browser game and the required interface to do those things doesn't exist yet. Javascript will always be chasing the tail of native.
If shaders are the bottleneck, and not graphics calls, then NaCl and JS will be the same.
If graphics calls are the bottleneck, then sure, NaCl will be faster - but likely you need to do more batching in your GL code.
> JS has certainly had some significant advances in speed over the last few years, but there's only so much optimization you can do. It's still running in a VM, so there will always be that overhead.
NaCl is essentially also running in a VM: It's sandboxed, so it has performance limitations. There are types of code that run slowly in NaCl, just like in the JVM. However, VM code can be fairly fast in general, the JVM and NaCl are speedy on a lot of code.
The point though is that JS can be fast too - once it has as many years of effort put into it as the JVM and native compilers has, it will be. It's just still very new. "Being in a VM" is not the issue.
The point is, by default the user does not need to install or enable it. Let's not underestimate how important a factor this is.