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.
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.