It was game over long before NaCL, which is why I'm not bullish on this particular browser plugin: very, very few information problems people need solved require native code, and those few problems are already pretty well represented. If this was a killer problem, the JVM applet plugin would have evolved faster.
This could be a huge boon to casual multiplayer gaming. You may be able to implement games that are as fast as desktop clients, but which require zero installation. (Once the plugin is installed the first time, of course.)
The same benefits would also be a huge boon to browser office apps.
Actually, this is the architecture that should be used to distribute plugins, period.
You say that as if you knew it to be true. But we don't really even know if it's going to work; it's a new x86 verification scheme, and if it's somehow broken, it won't work at all.
I see how a near-native-performance plugin interface is valuable, but it's still just not clear to me why, if this was that important, it wouldn't be in the Java applet plugin's bailiwick. The same CS disciplines that make NaCL possible can also drastically accelerate the JVM.
It's also not totally clear that, when NaCL is actually fielded, the end user experience will be that much better than the applet plugin. NaCL forks off a seperate process and sets up a special runtime with a sidecar debug monitor; once it's up in steady state, I'm sure it's faster than Java, but the big issue with Java is setup time.
Your referents are a bit vague: "You say that as if you knew it to be true."
Are you referring to my first paragraph, where I say could?
Are you referring to my second, where I say would? (Would if it works like it's supposed to.)
As for my last paragraph, this is an opinion based on personal experience with the "security" of ActiveX and other plugins I've run into in my professional life. Web plugins and other downloaded executables should be sandboxed for security.
Also, the fact that it's not a virtual machine, but virtualized machine code will help with setup: the X86 ISA seems to change much less often than the JRE.
When I said "that", I think I meant, "all of it". ;)
ActiveX vs. NaCL is a false comparison, obviously. You can't do worse than ActiveX, and nobody promotes it.
I don't understand your last paragraph; setup time isn't going to be based on the X86 ISA, but rather the time it takes to fork a process, monitor it in a debugger, set up the system call interface, and then do whatever UI goop NaCL wants to do to give native code a window context. It could be faster than the Java applet plugin. It could be slower. And applets could get faster.
So your "that" referent consisted of two hypothetical parts and a 3rd statement that you agree is trivially true.
I meant setup from a user standpoint. I suspect that once such sandbox software was stable, updates would be less frequent than updates to the Java plugin. You meant setup time in terms of getting code JITed and actual execution.
