7 ms·

What was the actual reason why Mozilla could not implement NaCL? Why cannot multiple technologies compete among users on their merits?

by pekk 14y ago

dman 14y ago
I wish NaCL was available across browsers - at the very least it offers completely different tradeoffs that can be useful as escape hatches for certain kinds of applications. Also since none of Google's bread and butter products depend on it, I am a bit wary that it might be mothballed at some point. If anyone in this thread has more clarity about the NaCL roadmap I would be very interested in hearing about it.
- macspoofing 14y ago
  NaCL already feels like dead-man-walking. It's a tech that is completely controlled by Google and none of the other big guys (Apple, Microsoft, Mozilla) want anything to do with it.
  - dman 14y ago
    Thats a shame - Ive been on the fence on writing a data analysis environment using NaCL. Have a couple of small demos running but want to find out more about the roadmap before investing more time into it. This is the main reason I am going to Google IO this year to get some kind of feel for what the roadmap / traction looks like for NaCL going forward.
    - macspoofing 14y ago
      It's not going to be supported by anybody except Chrome, so whatever app you build, is going to cut 3/4ths of the market (plus all the Chrome Browser users that don't download Chrome apps). Most likely Google will keep it around for a while longer since it underpins not only Chrome Browser, but also Chrome OS. You're essentially in the ActiveX / Java Web Start worlds. It's fine if it suits your needs but it's not the web.
AndrewDucker 14y ago
Why would they implement NaCL? If someone wants to write a plugin for it, they're welcome to - but Firefox is solidly behind supporting Javascript as a standard, and don't see any point in adding other technologies to the mix.
- dman 14y ago
  Because that would at least get software like Photoshop / 3d Studio Max etc into the browser as a delivery platform. Then pragmatically parts of those apps can be transitioned to things like webgl / canvas as these technologies mature.
  - gcp 14y ago
    Emscripten will probably do more for that than NaCl ever will.
    - dman 14y ago
      The future is definitely going to be interesting - would be nice if the browser makers started shifting their own native codebases through Emscripten / asm.js / NaCL. Have a minimal bootstrap environment and then implement your entire stack in terms of primitives that you expect the rest of the world to use.
      - BrendanEich 14y ago
        That is farther in the future. Shorter term, we could NaCl (not PNaCl) parts of our native codebases, and Chrome VIPs have spoken of this to the press. But it has not happened yet, and some performance-critical pieces will probably remain unsafe. As noted elsewhere here, Mozilla with Servo is investigating zerovm-ish NaCl uses, _sans_ Pepper. Good stuff IMHO. /be
MatthewPhillips 14y ago
Do a search for BrendanEich on hnsearch.com, he's discussed it many times. I'm curious why you're asking about Mozilla and not Apple or Microsoft, though, they aren't implementing NaCL either.
- dman 14y ago
  One reason could be that there are higher expectations of Mozilla when it comes to making decisions on technical merit.
  - BrendanEich 14y ago
    No one has made the case that PNaCl/Pepper has more technical merit than Emscripten(or Mandreel, e.g.) / asm.js / WebAPIs. Assuming is a mistake. /be
    - chadaustin 14y ago
      It's of course risky to discuss something that hasn't shipped, though extrapolating PNaCl's behavior from its architecture isn't that hard. (It's just NaCl except that LLVM is compiled to NaCl on load. And LLVM itself runs within the NaCl sandbox too.) Off the top of my head, if PNaCl existed today, its advantages would be: access to SIMD units, true threads, 64-bit integer operations, 32-bit floats, debuggability with nacl-gdb, a growable heap, support for exceptions/setjmp, and no ridiculousness like: https://mail.mozilla.org/pipermail/es-discuss/2013-March/029519.html https://mail.mozilla.org/pipermail/es-discuss/2013-March/029... As a browser implementer, you are fully justified in rejecting Pepper. :) Permanent APIs should go through some kind of standardization process. (Or they should HAVE, cough XHR) I gave a presentation at GDC this morning* on Emscripten and asm.js and agree that asm.js has better survivability characteristics and is likely to succeed in the market. Nonetheless, the proposed design of PNaCl has several technical merits over asm.js as it exists today. In the meantime, please add 64-bit integers, threads, and SIMD to asm.js :) * It occupied the same time slot as the Mozilla presentation! arg! Edit: forgot exceptions, setjmp, and a growable heap, none of which work in asm.js today. I know, I know, asm.js is early, but the point I'm making is that we're comparing two theoretical technologies at this point.
AndrewDucker 14y ago
Here's Mozilla's CTO on why he's not supporting NaCL: https://news.ycombinator.com/item?id=4632410 https://news.ycombinator.com/item?id=4632410
jlongster 14y ago
There's several reasons, read this post and Brendan's corresponding comments about it: https://news.ycombinator.com/item?id=4630057 https://news.ycombinator.com/item?id=4630057 Practically speaking, it's quite a large engineering effort, duplicates maintenance work, and introduces a whole host of new problems (backwards compatibility, etc) itself. Not to mention the politics involved in getting all the browsers on-board and agreeing to a whole new completely different standard.
b0b_d0e 14y ago
If I recall, I read somewhere that it would take a lot of work to get Firefox to where it would need to be to support NaCL. The whole point of making asm.js is that it is easy to implement AND produces tremendous results. Oh, just found what I was referring to. This is from the asm.js FAQ http://asmjs.org/faq.html http://asmjs.org/faq.html > Q. Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript? > A. The principal benefit of asm.js over whole new technologies like NaCl and PNaCl is that it works today: existing JavaScript engines already optimize this style of code quite well. This means that developers can ship asm.js today and it'll simply get faster over time. Another important benefit is that it's far simpler to implement, requiring very little additional machinery on top of existing JavaScript engines and no API compatibility layer. Also for reference, this is the documentation on implementing native client http://www.chromium.org/nativeclient http://www.chromium.org/nativeclient
macspoofing 14y ago
I don't really see the point of NaCL when something like asm.js gives us our cake and let's us eat it too.
bzbarsky 14y ago
Mozilla doesn't want to implement NaCL because most of the people involved in the project feel that the hardware-architecture-dependence this would introduce to the web is a really bad idea. Mozilla could not implement PNaCL (which would not have that drawback) because it doesn't exist yet.
- dragonwriter 14y ago
  > Mozilla could not implement PNaCL (which would not have that drawback) because it doesn't exist yet. PNaCl doesn't exist yet? That's funny, because its both in the current Native Client SDK and has been in Chrome stable (disabled by default) since, well, I'm not sure, but at least since the last major version, which is the first time I noticed the setting.
  - bzbarsky 14y ago
    Except it still requires you to serve up architecture-specific things for now, as far as I can tell.
    - dragonwriter 14y ago
      > Except it still requires you to serve up architecture-specific things for now, as far as I can tell. PNaCl doesn't require that. The fact that PNaCl is not enabled by default on the client makes that a practical requirement when using NaCl, but "is not enabled by default in Chrome" isn't the same thing as "does not exist". Particularly, the fact that PNaCl isn't enabled by default in Chrome, unlike the claimed fact that it doesn't exist, is no barrier to Mozilla incorporating it.
      - bzbarsky 14y ago
        Uh... if it's not "existing" enough to enable in Chrome, what makes you think it's "existing" enough to enable in Mozilla? But also, see the Pepper discussions through these various threads. "Existing" for PNaCl also includes being specified enough to actually be implementable, which runs straight into Pepper.

What was the actual reason why Mozilla could not implement NaCL? Why cannot multiple technologies compete among users on their merits?

by pekk 14y ago

What was the actual reason why Mozilla could not implement NaCL? Why cannot multiple technologies compete among users on their merits?

dman 14y ago

I wish NaCL was available across browsers - at the very least it offers completely different tradeoffs that can be useful as escape hatches for certain kinds of applications. Also since none of Google's bread and butter products depend on it, I am a bit wary that it might be mothballed at some point. If anyone in this thread has more clarity about the NaCL roadmap I would be very interested in hearing about it.

macspoofing 14y ago
NaCL already feels like dead-man-walking. It's a tech that is completely controlled by Google and none of the other big guys (Apple, Microsoft, Mozilla) want anything to do with it.
- dman 14y ago
  Thats a shame - Ive been on the fence on writing a data analysis environment using NaCL. Have a couple of small demos running but want to find out more about the roadmap before investing more time into it. This is the main reason I am going to Google IO this year to get some kind of feel for what the roadmap / traction looks like for NaCL going forward.
  - macspoofing 14y ago
    It's not going to be supported by anybody except Chrome, so whatever app you build, is going to cut 3/4ths of the market (plus all the Chrome Browser users that don't download Chrome apps). Most likely Google will keep it around for a while longer since it underpins not only Chrome Browser, but also Chrome OS. You're essentially in the ActiveX / Java Web Start worlds. It's fine if it suits your needs but it's not the web.

AndrewDucker 14y ago

Why would they implement NaCL? If someone wants to write a plugin for it, they're welcome to - but Firefox is solidly behind supporting Javascript as a standard, and don't see any point in adding other technologies to the mix.

dman 14y ago
Because that would at least get software like Photoshop / 3d Studio Max etc into the browser as a delivery platform. Then pragmatically parts of those apps can be transitioned to things like webgl / canvas as these technologies mature.
- gcp 14y ago
  Emscripten will probably do more for that than NaCl ever will.
  - dman 14y ago
    The future is definitely going to be interesting - would be nice if the browser makers started shifting their own native codebases through Emscripten / asm.js / NaCL. Have a minimal bootstrap environment and then implement your entire stack in terms of primitives that you expect the rest of the world to use.
    - BrendanEich 14y ago
      That is farther in the future. Shorter term, we could NaCl (not PNaCl) parts of our native codebases, and Chrome VIPs have spoken of this to the press. But it has not happened yet, and some performance-critical pieces will probably remain unsafe. As noted elsewhere here, Mozilla with Servo is investigating zerovm-ish NaCl uses, _sans_ Pepper. Good stuff IMHO. /be

MatthewPhillips 14y ago

Do a search for BrendanEich on hnsearch.com, he's discussed it many times. I'm curious why you're asking about Mozilla and not Apple or Microsoft, though, they aren't implementing NaCL either.

dman 14y ago
One reason could be that there are higher expectations of Mozilla when it comes to making decisions on technical merit.
- BrendanEich 14y ago
  No one has made the case that PNaCl/Pepper has more technical merit than Emscripten(or Mandreel, e.g.) / asm.js / WebAPIs. Assuming is a mistake. /be
  - chadaustin 14y ago
    It's of course risky to discuss something that hasn't shipped, though extrapolating PNaCl's behavior from its architecture isn't that hard. (It's just NaCl except that LLVM is compiled to NaCl on load. And LLVM itself runs within the NaCl sandbox too.) Off the top of my head, if PNaCl existed today, its advantages would be: access to SIMD units, true threads, 64-bit integer operations, 32-bit floats, debuggability with nacl-gdb, a growable heap, support for exceptions/setjmp, and no ridiculousness like: https://mail.mozilla.org/pipermail/es-discuss/2013-March/029519.html https://mail.mozilla.org/pipermail/es-discuss/2013-March/029... As a browser implementer, you are fully justified in rejecting Pepper. :) Permanent APIs should go through some kind of standardization process. (Or they should HAVE, cough XHR) I gave a presentation at GDC this morning* on Emscripten and asm.js and agree that asm.js has better survivability characteristics and is likely to succeed in the market. Nonetheless, the proposed design of PNaCl has several technical merits over asm.js as it exists today. In the meantime, please add 64-bit integers, threads, and SIMD to asm.js :) * It occupied the same time slot as the Mozilla presentation! arg! Edit: forgot exceptions, setjmp, and a growable heap, none of which work in asm.js today. I know, I know, asm.js is early, but the point I'm making is that we're comparing two theoretical technologies at this point.

AndrewDucker 14y ago

Here's Mozilla's CTO on why he's not supporting NaCL: https://news.ycombinator.com/item?id=4632410 https://news.ycombinator.com/item?id=4632410

jlongster 14y ago

There's several reasons, read this post and Brendan's corresponding comments about it: https://news.ycombinator.com/item?id=4630057 https://news.ycombinator.com/item?id=4630057 Practically speaking, it's quite a large engineering effort, duplicates maintenance work, and introduces a whole host of new problems (backwards compatibility, etc) itself. Not to mention the politics involved in getting all the browsers on-board and agreeing to a whole new completely different standard.

b0b_d0e 14y ago

If I recall, I read somewhere that it would take a lot of work to get Firefox to where it would need to be to support NaCL. The whole point of making asm.js is that it is easy to implement AND produces tremendous results. Oh, just found what I was referring to. This is from the asm.js FAQ http://asmjs.org/faq.html http://asmjs.org/faq.html > Q. Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript? > A. The principal benefit of asm.js over whole new technologies like NaCl and PNaCl is that it works today: existing JavaScript engines already optimize this style of code quite well. This means that developers can ship asm.js today and it'll simply get faster over time. Another important benefit is that it's far simpler to implement, requiring very little additional machinery on top of existing JavaScript engines and no API compatibility layer. Also for reference, this is the documentation on implementing native client http://www.chromium.org/nativeclient http://www.chromium.org/nativeclient

macspoofing 14y ago

I don't really see the point of NaCL when something like asm.js gives us our cake and let's us eat it too.

bzbarsky 14y ago

Mozilla doesn't want to implement NaCL because most of the people involved in the project feel that the hardware-architecture-dependence this would introduce to the web is a really bad idea. Mozilla could not implement PNaCL (which would not have that drawback) because it doesn't exist yet.

dragonwriter 14y ago
> Mozilla could not implement PNaCL (which would not have that drawback) because it doesn't exist yet. PNaCl doesn't exist yet? That's funny, because its both in the current Native Client SDK and has been in Chrome stable (disabled by default) since, well, I'm not sure, but at least since the last major version, which is the first time I noticed the setting.
- bzbarsky 14y ago
  Except it still requires you to serve up architecture-specific things for now, as far as I can tell.
  - dragonwriter 14y ago
    > Except it still requires you to serve up architecture-specific things for now, as far as I can tell. PNaCl doesn't require that. The fact that PNaCl is not enabled by default on the client makes that a practical requirement when using NaCl, but "is not enabled by default in Chrome" isn't the same thing as "does not exist". Particularly, the fact that PNaCl isn't enabled by default in Chrome, unlike the claimed fact that it doesn't exist, is no barrier to Mozilla incorporating it.
    - bzbarsky 14y ago
      Uh... if it's not "existing" enough to enable in Chrome, what makes you think it's "existing" enough to enable in Mozilla? But also, see the Pepper discussions through these various threads. "Existing" for PNaCl also includes being specified enough to actually be implementable, which runs straight into Pepper.