4 ms·

> I wouldn't be surprised if for those $300 million they also got Mozilla to accept using Native Client in Firefox later on. If you're suggesting that Mozilla

by azakai 15y ago

> I wouldn't be surprised if for those $300 million they also got Mozilla to accept using Native Client in Firefox later on. If you're suggesting that Mozilla would do something bad for the web for money, then I think you couldn't be more wrong. Mozilla is a nonprofit exactly for this reason. (Worth noting that the for-profit Opera opposes Native Client too - it isn't just nonprofits that have values.)

tomjen3 15y ago
Is that sarcasm? Native client is one of the best things that will ever happen to the web since jQuery made it possible to write cross-browser javascript. Imagine how much easier it will be in the future when ever very intensive programs can be written, and run, on the web.
- prodigal_erik 15y ago
  That future is better known as client/server, and it's a huge step backwards. There was only one client that worked at all, it was terrible, and you couldn't fix it. No, every time an author imposes fixed client behavior rather than writing publically addressible content which can be rendered and repurposed in many ways, the world-wide web dies a little more.
  - tomjen3 15y ago
    I seem to be somewhat dense today, do you mind explaining to me what harm will come if the next IDE to a language I use is implemented in native client and runs in a browser and wouldn't come if it was written in java and ran on my desktop? (and therefore was only available when my laptop was, etc) or for that matter the photoshop or some computer game.
    - prodigal_erik 15y ago
      My concern is for content increasingly being siloed within an app that only permits its use in ways encouraged by the author. An IDE is a decent counter-example, since nothing like it would have been feasible before js apps began displacing the web. But it's more and more unlikely that any app other than that IDE will be able to access your source code, simply because it's easier not to bother supporting a stable and documented API when the maintainer's favored client can be revved at a moment's notice.
  - WayneDB 15y ago
    "fixed client behavior" What _isn't_ fixed client behavior on the web? Browsers don't just interpret HTML any which way that they want to.
- bzbarsky 15y ago
  Native client would lock the web into particular hardware platforms. So it is in fact one of the worst things that could happen to the web.
  - mvgoogler 15y ago
    How would NaCl lock the web into a particular hardware platform? NaCl run on x86-32, ARM and x86-64.
    - bzbarsky 15y ago
      Yes. Which means it does NOT run on PPC, or MIPS, or IA-32, or Sparc. Note that there are modern-ish web browsers available for at least PPC, MIPS, and Sparc. More importantly, content using NaCl would not run on any new hardware platforms that might appear. So if the web were to use NaCl to an appreciable extent, new platforms would be unable to get any traction in any context that relied on the web. We'd be stuck with ARM or X86 forever for any mobile devices we might have. Maybe you think that's ok; I think that's a terrible idea; an attitude like that toward the web in the late 1990s would have meant that ARM phones that appeared in the late 2000s would not have been able to browse the web! (Also, note that I said "hardware _platforms_", not what you asked above.)
      - jlouis 15y ago
        PPC, MIPS, and Sparc are dead platforms anyway. X86 and ARM is where its currently at, like it or not. So it does make sense to target these platforms first. I don't buy that this is a step backwards. Rather, it is a step in the right direction: So we can run other languages in the browsers, at full speed - untangling the web from Javascript. It is about time.
        azakai 15y ago
        > 86 and ARM is where its currently at, like it or not. The important word is currently. As the GP said, 10 years ago "archs where its currently at" would not include ARM, and the ARM success on phones and tablets would have been impossible, because they wouldn't have been able to run the web, if the web used Native Client! 10 years from now, we could have entirely new architectures, and if we lock the web into the currently popular ones, we might miss out on those.
- azakai 15y ago
  Native Client only works on x86 and x86_64. You can't run Native Client content on your ARM phone or your PowerPC game console. That is very bad for the web, the whole idea of which is that you can access it from anywhere, using anything. There is some work to try to make it portable, but it is unclear how it will end up (how portable, how fast, how secure, etc.). Partly because of this, NaCl is not standardized or even a proposed standard, which is another problem for the web. I do admire the NaCl technology though - it's very neat. Although it's bad for the web, it is good for lots of other things.
  - magicalist 15y ago
    I agree that NaCl isn't the road forward, but I definitely don't agree that support for it is an indicator of good values. In your original comment, were you referring to the fact that Opera also runs on money from deals with search providers, yet doesn't support proposals from them if they disagree?
    - azakai 15y ago
      Opera is funded by search deals, but I think I read that they make most of their money from carriers in return for installing Opera Mobile on phones. Not 100% sure though. In any case, Opera has always been one of the biggest supporters of the open web, through working on standards, opposing things that are bad for the web, etc.
  - mvgoogler 15y ago
    "Native Client only works on x86 and x86_64. You can't run Native Client content on your ARM phone" Not true: http://www.chromium.org/nativeclient/reference/arm-overview http://www.chromium.org/nativeclient/reference/arm-overview
    - zobzu 15y ago
      You need to make it work for it. It's not a very good analogy because parts are portable, but good enough for me: I can recompile my C program for arm. Doesn't make the x86 binary run.

by azakai 15y ago

tomjen3 15y ago

Is that sarcasm? Native client is one of the best things that will ever happen to the web since jQuery made it possible to write cross-browser javascript. Imagine how much easier it will be in the future when ever very intensive programs can be written, and run, on the web.

prodigal_erik 15y ago
That future is better known as client/server, and it's a huge step backwards. There was only one client that worked at all, it was terrible, and you couldn't fix it. No, every time an author imposes fixed client behavior rather than writing publically addressible content which can be rendered and repurposed in many ways, the world-wide web dies a little more.
- tomjen3 15y ago
  I seem to be somewhat dense today, do you mind explaining to me what harm will come if the next IDE to a language I use is implemented in native client and runs in a browser and wouldn't come if it was written in java and ran on my desktop? (and therefore was only available when my laptop was, etc) or for that matter the photoshop or some computer game.
  - prodigal_erik 15y ago
    My concern is for content increasingly being siloed within an app that only permits its use in ways encouraged by the author. An IDE is a decent counter-example, since nothing like it would have been feasible before js apps began displacing the web. But it's more and more unlikely that any app other than that IDE will be able to access your source code, simply because it's easier not to bother supporting a stable and documented API when the maintainer's favored client can be revved at a moment's notice.
- WayneDB 15y ago
  "fixed client behavior" What _isn't_ fixed client behavior on the web? Browsers don't just interpret HTML any which way that they want to.
bzbarsky 15y ago
Native client would lock the web into particular hardware platforms. So it is in fact one of the worst things that could happen to the web.
- mvgoogler 15y ago
  How would NaCl lock the web into a particular hardware platform? NaCl run on x86-32, ARM and x86-64.
  - bzbarsky 15y ago
    Yes. Which means it does NOT run on PPC, or MIPS, or IA-32, or Sparc. Note that there are modern-ish web browsers available for at least PPC, MIPS, and Sparc. More importantly, content using NaCl would not run on any new hardware platforms that might appear. So if the web were to use NaCl to an appreciable extent, new platforms would be unable to get any traction in any context that relied on the web. We'd be stuck with ARM or X86 forever for any mobile devices we might have. Maybe you think that's ok; I think that's a terrible idea; an attitude like that toward the web in the late 1990s would have meant that ARM phones that appeared in the late 2000s would not have been able to browse the web! (Also, note that I said "hardware _platforms_", not what you asked above.)
    - jlouis 15y ago
      PPC, MIPS, and Sparc are dead platforms anyway. X86 and ARM is where its currently at, like it or not. So it does make sense to target these platforms first. I don't buy that this is a step backwards. Rather, it is a step in the right direction: So we can run other languages in the browsers, at full speed - untangling the web from Javascript. It is about time.
      - azakai 15y ago
        > 86 and ARM is where its currently at, like it or not. The important word is currently. As the GP said, 10 years ago "archs where its currently at" would not include ARM, and the ARM success on phones and tablets would have been impossible, because they wouldn't have been able to run the web, if the web used Native Client! 10 years from now, we could have entirely new architectures, and if we lock the web into the currently popular ones, we might miss out on those.
azakai 15y ago
Native Client only works on x86 and x86_64. You can't run Native Client content on your ARM phone or your PowerPC game console. That is very bad for the web, the whole idea of which is that you can access it from anywhere, using anything. There is some work to try to make it portable, but it is unclear how it will end up (how portable, how fast, how secure, etc.). Partly because of this, NaCl is not standardized or even a proposed standard, which is another problem for the web. I do admire the NaCl technology though - it's very neat. Although it's bad for the web, it is good for lots of other things.
- magicalist 15y ago
  I agree that NaCl isn't the road forward, but I definitely don't agree that support for it is an indicator of good values. In your original comment, were you referring to the fact that Opera also runs on money from deals with search providers, yet doesn't support proposals from them if they disagree?
  - azakai 15y ago
    Opera is funded by search deals, but I think I read that they make most of their money from carriers in return for installing Opera Mobile on phones. Not 100% sure though. In any case, Opera has always been one of the biggest supporters of the open web, through working on standards, opposing things that are bad for the web, etc.
- mvgoogler 15y ago
  "Native Client only works on x86 and x86_64. You can't run Native Client content on your ARM phone" Not true: http://www.chromium.org/nativeclient/reference/arm-overview http://www.chromium.org/nativeclient/reference/arm-overview
  - zobzu 15y ago
    You need to make it work for it. It's not a very good analogy because parts are portable, but good enough for me: I can recompile my C program for arm. Doesn't make the x86 binary run.