> That's true but for the first part, it's mostly due to a lack of interest by other vendors.

The lack of interest by other vendors is because NaCl isn't an appropriate technology for the open web, not just random lack of interest. (First and foremost, because it is CPU-specific, while the web is supposed to run everywhere.)

> For the second part, isn't the nacl team working on a protable version of nacl?

A research project called PNaCl, yes. But it is a different technology than NaCl despite the similar name. One is based on gcc, the other llvm, one ships CPU-specific machine code, the other bitcode, etc. So it is at this point too early to tell if PNaCl will achieve good portability+speed, NaCl's speed doesn't mean PNaCl will be fast too. Adopting NaCl because of the promise of PNaCl doesn't make much sense.

Yes I believe they're using a subset of LLVM for PNaCl. The whole idea is to define the semantics of how LLVM should be targeted there for it, since it normally does include some system specific things (how structs and things end up aligned when compiling C and the like). I think they're working on some "sane" defaults for all of those kinds of things so that they can target that subset with their compilers and then in theory run anywhere supported by LLVM. It's a very very interesting idea and if it does actually get anywhere it'll mean that there's a subset of LLVM that could be targeted by "native" applications for a similar effect, e.g. no need for a fat binary, just use the portable subset of llvm bytecode.