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.
