4 ms·

Publicly they have stated that it's because they think JS is fast enough. I think that they have some private issues regarding a plugin controlled solely by th

by Jimmie 14y ago

Publicly they have stated that it's because they think JS is fast enough. I think that they have some private issues regarding a plugin controlled solely by their browser competitor who wants NaCl apps to be purchased through the Chrome Webstore.

simonster 14y ago
NaCl constrains the CPU architectures that the web can run on. No one is going to compile for anything but x86 and ARM. Some people might not even bother to compile for ARM. This seems bad. (If NaCl were widely adopted 5 years ago, the web would be much less accessible to mobile devices.) PNaCl makes things a little better by using LLVM IR instead of machine code, but one of the LLVM developers has publicly stated that "LLVM IR is a poor system for building a Platform" (http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...).
- Jimmie 14y ago
  "If NaCl were widely adopted 5 years ago, the web would be much less accessible to mobile devices." I don't agree with this. From what I've read NaCl isn't even getting auto-run by default. It is not trying to replace JS just sit alongside it as an application language. It lets developers target CPU architectures instead of Operating Systems which makes a lot of sense to me. Also it's C/C++, any popular app would be easily ported to mobile devices. Look how far JS has come in 5 years, imagine how for NaCl could have come. On your PNaCl point, it may not be optimal but I love the idea. "Compile to javascript" is an awful concept, "compile to IR" is better for a number of reasons that I won't go into right now.
  - simonster 14y ago
    > I don't agree with this. From what I've read NaCl isn't even getting auto-run by default. It is not trying to replace JS just sit alongside it as an application language. It lets developers target CPU architectures instead of Operating Systems which makes a lot of sense to me. Even if it's not trying to replace JS, if it works well enough, a lot of sites will use it to replace JS, whether because they want to add functionality that's not as easy to implement in JS, because they don't want to expose their source, or just because their programmers don't know/like JS. We have already been through this with ActiveX, which was a similar idea, but poorly executed. > Also it's C/C++, any popular app would be easily ported to mobile devices. Only if the developers care. There's a chicken-and-egg problem here. If your mobile platform can't interact properly with a large proportion of the web, no one is going to buy it, and so no one will bother to port their site to it. > "Compile to javascript" is an awful concept, "compile to IR" is better for a number of reasons that I won't go into right now. Possibly. If you absolutely have to run C/C++ app on the client side, I agree that something like PNaCl (but actually architecture-independent) is a better solution than something like emscripten. But I think it would be even better to 1) run it server side or 2) write it in JavaScript.

by Jimmie 14y ago

simonster 14y ago

NaCl constrains the CPU architectures that the web can run on. No one is going to compile for anything but x86 and ARM. Some people might not even bother to compile for ARM. This seems bad. (If NaCl were widely adopted 5 years ago, the web would be much less accessible to mobile devices.) PNaCl makes things a little better by using LLVM IR instead of machine code, but one of the LLVM developers has publicly stated that "LLVM IR is a poor system for building a Platform" (http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...).

Jimmie 14y ago
"If NaCl were widely adopted 5 years ago, the web would be much less accessible to mobile devices." I don't agree with this. From what I've read NaCl isn't even getting auto-run by default. It is not trying to replace JS just sit alongside it as an application language. It lets developers target CPU architectures instead of Operating Systems which makes a lot of sense to me. Also it's C/C++, any popular app would be easily ported to mobile devices. Look how far JS has come in 5 years, imagine how for NaCl could have come. On your PNaCl point, it may not be optimal but I love the idea. "Compile to javascript" is an awful concept, "compile to IR" is better for a number of reasons that I won't go into right now.
- simonster 14y ago
  > I don't agree with this. From what I've read NaCl isn't even getting auto-run by default. It is not trying to replace JS just sit alongside it as an application language. It lets developers target CPU architectures instead of Operating Systems which makes a lot of sense to me. Even if it's not trying to replace JS, if it works well enough, a lot of sites will use it to replace JS, whether because they want to add functionality that's not as easy to implement in JS, because they don't want to expose their source, or just because their programmers don't know/like JS. We have already been through this with ActiveX, which was a similar idea, but poorly executed. > Also it's C/C++, any popular app would be easily ported to mobile devices. Only if the developers care. There's a chicken-and-egg problem here. If your mobile platform can't interact properly with a large proportion of the web, no one is going to buy it, and so no one will bother to port their site to it. > "Compile to javascript" is an awful concept, "compile to IR" is better for a number of reasons that I won't go into right now. Possibly. If you absolutely have to run C/C++ app on the client side, I agree that something like PNaCl (but actually architecture-independent) is a better solution than something like emscripten. But I think it would be even better to 1) run it server side or 2) write it in JavaScript.