4 ms·

Native Client Adoption by all browsers would be awesome for the gaming market and would also provide alternatives to Javascript, which many people would like i

by kayoone 14y ago

Native Client Adoption by all browsers would be awesome for the gaming market and would also provide alternatives to Javascript, which many people would like i guess.

azakai 14y ago
In the short term, sure. But since NaCl doesn't run on all CPUs and is not standardized, it would lead to problems in the long run. Regarding alternatives to JavaScript, you can compile pretty much any language into a form that can run on the web, right now: C++, C#, Java, etc. (That form happens to be JavaScript.)
- wickedchicken 14y ago
  > But since NaCl doesn't run on all CPUs The PNaCl project[1] aims to distribute LLVM bitcode, solving this problem. You also gain the advantage that all programs can be JITed to exactly your processor spec. [1] http://www.chromium.org/nativeclient/pnacl http://www.chromium.org/nativeclient/pnacl
  - azakai 14y ago
    It aims to do that. It isn't finished and it is not clear what the final product will look like in terms of portability and performance.
- quonn 14y ago
  I would really like to see that all NaCl apps have to ship at least a PNaCl binary (and possibly ARM as well). Browsers should verify this and refuse to run apps that are x86 only. If all NaCl apps would contain PNaCl/x86/ARM binaries I don't see a disadvantage compared to compiling other languages down to JavaScript (which is just as unreadable/proprietary). Also it's certainly an improvement over native plugins that not only lack a sandbox, but are also tied to the OS in addition to the CPU. In fact, I suggest that browsers should adopt NaCl at least for plugins, maybe even allowing unrestricted access to the file system, camera, etc. and gradually phase out conventional plugins. Even without the security benefit this still gives us portable plugins.
  - azakai 14y ago
    > If all NaCl apps would contain PNaCl/x86/ARM binaries I don't see a disadvantage compared to compiling other languages down to JavaScript (which is just as unreadable/proprietary). Even if PNaCl worked today, and even if it gave good performance and portability, it would still not be standardized. The only way to get PNaCl into a new browser would be to use the current implementation (which defines what it is). Having that implementation open source is a good thing. But it isn't as good as JavaScript which has a standard and multiple independent implementations. If you want to write a JS engine in Haskell, for example, you can do that. You can't do that with NaCl or PNaCl, you must use the existing code as is.
    - drivebyacct2 14y ago
      So write another new implementation? That's like saying (the first JS engine) is the only one that exists, so every other browser must also use it.
      - azakai 14y ago
        There is a standard for JavaScript, a spec to implement. And new features in the JS language evolve out of a standards process that involves all the browser makers (as well as others). As a result, you can write a new implementation of it, and people do. There is no standard or spec for NaCl, PNaCl or PPAPI. Those things are still being developed, and they change a lot (talk to people that develop for that API to get an idea of how things can change with each 6-week update of Chrome). To implement those, you need to basically "do what Google's implementation does." Trying to track that large and complex - and changing - implementation is practically impossible.
- haberman 14y ago
  PNaCl targets LLVM bitcode, so can be supported on any modern CPU: http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client http://www.chromium.org/nativeclient/pnacl/building-and-test... Compiling other languages to JavaScript imposes an unacceptable speed penalty. C++-to-JavaScript is not a viable platform for real applications, especially anything performance-critical.
  - gsnedders 14y ago
    Except, of course, LLVM bitcode isn't meant to be distributed: it's designed as a compiler IR, and merely an intermediary form. It's also not portable: the existence of types like x86_fp80 and ppc_fp128 make this quite clear.
    - azakai 14y ago
      Yes, and it also implicitly includes assumptions on endianness, stack size, alignments, etc. It is very hard to make it portable. It's a great compiler IR though! This isn't a criticism of LLVM bitcode.
    - haberman 14y ago
      I suggest reading the PNaCl paper, which addresses how they make LLVM bitcode distributable and portable. Because believe it or not, they have thought about these problems, and solutions to them have been designed and implemented. It's not a force-fit either. LLVM is designed to be a form from which machine-specific code is generated. The problem is only that different platforms have different conventions. But any modern 32-bit platform can use a given set of conventions if you want it to.
  - azakai 14y ago
    See comments below - PNaCl is not finished, and we don't know what performance and portability it will provide when it is. It is also not close to being standardizable since it is in flux. Do you have numbers for the "unacceptable speed penalty" JavaScript imposes on compiled code? That's an honest question, I am curious to see benchmarks about that.
- trentmb 14y ago
  C++ to JavaScript. That won't be hell to debug.
  - drivebyacct2 14y ago
    emscripten already exists and has a lot of... frankly unbelievably amazing demos to show for it.
  - azakai 14y ago
    It is actually easier to debug than C++ to x86 in my experience.
darkstalker 14y ago
Better not. It's giving too much power to the browser, and it's just reinventing native apps
- modeless 14y ago
  Giving too much power to the browser? What does that even mean? Native Client runs in a very similar sandbox as JavaScript, so the only extra "power" it has is the ability to run faster. Why could it possibly be bad for the browser to be faster?

by kayoone 14y ago

Native Client Adoption by all browsers would be awesome for the gaming market and would also provide alternatives to Javascript, which many people would like i guess.

azakai 14y ago

In the short term, sure. But since NaCl doesn't run on all CPUs and is not standardized, it would lead to problems in the long run. Regarding alternatives to JavaScript, you can compile pretty much any language into a form that can run on the web, right now: C++, C#, Java, etc. (That form happens to be JavaScript.)

wickedchicken 14y ago
> But since NaCl doesn't run on all CPUs The PNaCl project[1] aims to distribute LLVM bitcode, solving this problem. You also gain the advantage that all programs can be JITed to exactly your processor spec. [1] http://www.chromium.org/nativeclient/pnacl http://www.chromium.org/nativeclient/pnacl
- azakai 14y ago
  It aims to do that. It isn't finished and it is not clear what the final product will look like in terms of portability and performance.
quonn 14y ago
I would really like to see that all NaCl apps have to ship at least a PNaCl binary (and possibly ARM as well). Browsers should verify this and refuse to run apps that are x86 only. If all NaCl apps would contain PNaCl/x86/ARM binaries I don't see a disadvantage compared to compiling other languages down to JavaScript (which is just as unreadable/proprietary). Also it's certainly an improvement over native plugins that not only lack a sandbox, but are also tied to the OS in addition to the CPU. In fact, I suggest that browsers should adopt NaCl at least for plugins, maybe even allowing unrestricted access to the file system, camera, etc. and gradually phase out conventional plugins. Even without the security benefit this still gives us portable plugins.
- azakai 14y ago
  > If all NaCl apps would contain PNaCl/x86/ARM binaries I don't see a disadvantage compared to compiling other languages down to JavaScript (which is just as unreadable/proprietary). Even if PNaCl worked today, and even if it gave good performance and portability, it would still not be standardized. The only way to get PNaCl into a new browser would be to use the current implementation (which defines what it is). Having that implementation open source is a good thing. But it isn't as good as JavaScript which has a standard and multiple independent implementations. If you want to write a JS engine in Haskell, for example, you can do that. You can't do that with NaCl or PNaCl, you must use the existing code as is.
  - drivebyacct2 14y ago
    So write another new implementation? That's like saying (the first JS engine) is the only one that exists, so every other browser must also use it.
    - azakai 14y ago
      There is a standard for JavaScript, a spec to implement. And new features in the JS language evolve out of a standards process that involves all the browser makers (as well as others). As a result, you can write a new implementation of it, and people do. There is no standard or spec for NaCl, PNaCl or PPAPI. Those things are still being developed, and they change a lot (talk to people that develop for that API to get an idea of how things can change with each 6-week update of Chrome). To implement those, you need to basically "do what Google's implementation does." Trying to track that large and complex - and changing - implementation is practically impossible.
haberman 14y ago
PNaCl targets LLVM bitcode, so can be supported on any modern CPU: http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client http://www.chromium.org/nativeclient/pnacl/building-and-test... Compiling other languages to JavaScript imposes an unacceptable speed penalty. C++-to-JavaScript is not a viable platform for real applications, especially anything performance-critical.
- gsnedders 14y ago
  Except, of course, LLVM bitcode isn't meant to be distributed: it's designed as a compiler IR, and merely an intermediary form. It's also not portable: the existence of types like x86_fp80 and ppc_fp128 make this quite clear.
  - azakai 14y ago
    Yes, and it also implicitly includes assumptions on endianness, stack size, alignments, etc. It is very hard to make it portable. It's a great compiler IR though! This isn't a criticism of LLVM bitcode.
  - haberman 14y ago
    I suggest reading the PNaCl paper, which addresses how they make LLVM bitcode distributable and portable. Because believe it or not, they have thought about these problems, and solutions to them have been designed and implemented. It's not a force-fit either. LLVM is designed to be a form from which machine-specific code is generated. The problem is only that different platforms have different conventions. But any modern 32-bit platform can use a given set of conventions if you want it to.
- azakai 14y ago
  See comments below - PNaCl is not finished, and we don't know what performance and portability it will provide when it is. It is also not close to being standardizable since it is in flux. Do you have numbers for the "unacceptable speed penalty" JavaScript imposes on compiled code? That's an honest question, I am curious to see benchmarks about that.
trentmb 14y ago
C++ to JavaScript. That won't be hell to debug.
- drivebyacct2 14y ago
  emscripten already exists and has a lot of... frankly unbelievably amazing demos to show for it.
- azakai 14y ago
  It is actually easier to debug than C++ to x86 in my experience.

darkstalker 14y ago

Better not. It's giving too much power to the browser, and it's just reinventing native apps

modeless 14y ago
Giving too much power to the browser? What does that even mean? Native Client runs in a very similar sandbox as JavaScript, so the only extra "power" it has is the ability to run faster. Why could it possibly be bad for the browser to be faster?