it's an open spec and the main implementation
is open source
Actually, the implementation is so complicated that whatever spec exists is completely useless. And the existence of an open-source implementation does not guarantee a spec, quite the contrary, the spec will be the implementation itself.
You may think that the lack of a complete spec is not a problem, however I disagree. It hinders other implementations from scratch, which you may want because you disagree with the license or because you want to make it a lot better than it is (like what Google did with V8, when they could have gone with SpiderMonkey or with Nitro or whatever). Also, ask yourself why nobody could implement an alternative Perl interpreter and it wasn't because there was no need for it ;)
It's also a problem because the potential for abuse (embrace, extend) is huge. Suddenly the spec will contain implementation bugs that you cannot fix as long as the reference implementation doesn't. This even happens with Javascript, which is severely fragmented and holden back with concerns over backwards compatibility of scripts that are using the broken behavior. And do note that the ECMAScript standard is properly defined and quite simple to implement by comparison.
except without the near native performance of NaCl.
Which is why it was created
People have only scratched the surface of optimizing Javascript VMs and performance was never Javascript's biggest problem - there are other more pressing concerns, like freaking security, which is still inadequate and I have my doubts that NaCL will ever be secure, no matter how well it is sandboxed.
I see no reason why this is nefarious.
We have fought for years against the death grip IExplorer had on web standards. If other browser implementors don't want to implement NaCL, then Google should not try to push it down on people's throats. People could very well argue that ActiveX was a good thing. It gave birth to AJAX after all. That doesn't mean it wasn't an awful idea (even if it was done with good intentions).
Slightly off-topic, but I've been hacking IndexedDB lately, and while I'm grateful to Mozilla from saving us a future of writing SQL in the browser, IndexedDB is not what I would call friendly. Anything you do against it requires 4 or 5 callbacks. The first thing a JavaScript programmer will do is write an abstraction layer around it. That's a sign an API is too complex. Why on earth a transaction is required to do a get (or even a put, for that matter) is something I don't understand.
To my knowledge, IndexedDB is specifically intended as a low-level B-tree API that most developers will access via a high-level library of some sort [1].
See for example the rationale behind Mozilla's decision to prefer IndexedDB instead of Web SQL Storage: http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-... (tl;dr - because SQLite doesn't have a spec besides the SQL Manual).
You may think that the lack of a complete spec is not a problem, however I disagree. It hinders other implementations from scratch, which you may want because you disagree with the license or because you want to make it a lot better than it is (like what Google did with V8, when they could have gone with SpiderMonkey or with Nitro or whatever). Also, ask yourself why nobody could implement an alternative Perl interpreter and it wasn't because there was no need for it ;)
It's also a problem because the potential for abuse (embrace, extend) is huge. Suddenly the spec will contain implementation bugs that you cannot fix as long as the reference implementation doesn't. This even happens with Javascript, which is severely fragmented and holden back with concerns over backwards compatibility of scripts that are using the broken behavior. And do note that the ECMAScript standard is properly defined and quite simple to implement by comparison.
People have only scratched the surface of optimizing Javascript VMs and performance was never Javascript's biggest problem - there are other more pressing concerns, like freaking security, which is still inadequate and I have my doubts that NaCL will ever be secure, no matter how well it is sandboxed. We have fought for years against the death grip IExplorer had on web standards. If other browser implementors don't want to implement NaCL, then Google should not try to push it down on people's throats. People could very well argue that ActiveX was a good thing. It gave birth to AJAX after all. That doesn't mean it wasn't an awful idea (even if it was done with good intentions).