6 ms·

"Maintaining compatibility with existing browsers" is like saying "emitting machine code for CPUs that actually exist".

pbsdp 13y ago
Introducing a browser bytecode and/or sandboxing is not anywhere near the scale of complexity and expense of inventing a new CPU architecture. It's a policy decision, not a technical decision.
- gmac 13y ago
  Replacing JS may not be technically difficult, but practically it's extremely difficult (IE6, anyone?). Plus JS has got so fast, it's becoming hard to see the point anyway.
  - pbsdp 13y ago
    > Plus JS has got so fast, it's becoming hard to see the point anyway. Native is faster. A lot faster. And that's what browser apps are competing against.
    - klibertp 13y ago
      asm.js ? It's essentially almost typed intermediary language which can be directly/easily translated to CPU instructions.
      - rational_indian 13y ago
        Not fast enough apparently: https://developers.google.com/native-client/ https://developers.google.com/native-client/
- gnaritas 13y ago
  Getting your bytecode working in shipping in all browsers has proven to be impossible; there's a reason people compile to Javascript, it's the only practical choice.
  - pbsdp 13y ago
    It's impossible because Mozilla won't work with Google, not because it's actually impossible.
    - gnaritas 13y ago
      Even if they did, that's not enough, you have to get it into all popular browsers, not just two. JavaScript works everywhere, you have to match that to have any hope of replacing it.
      - pbsdp 13y ago
        Two browsers is more than enough to shift the industry, and there's still nothing stopping you from supporting JS as a legacy compilation target.
        gnaritas 13y ago
        No it isn't; if you can't get Microsoft and Apple on board, it won't shift. It'll take more than Mozilla and Google cooperating to replace JS.
        pbsdp 13y ago
        Ah, so it will lose because it will lose. So we can't implement it because we won't implement it. That's ridiculous. Mozilla is willing to stick their neck out there implementing a mobile phone operating system, but trying to deploy a sane runtime environment to replace JavaScript is just too risky?
        gnaritas 13y ago
        It is ridiculous, but it's also reality.
        pbsdp 13y ago
- marshray 13y ago
  Browser plugins are dead and they're not coming back. Yes, really. It's time to move on.
  - pbsdp 13y ago
    Nobody is proposing that. Neither NaCL, PNaCL, nor asm.js are 3rd-party browser plugins. I agree that it's time to move on. It's time to treat the web as a real application platform, instead of as document model with a JavaScript scripting interface.
    - marshray 13y ago
      NaCL, PNaCL aren't plugins because they're features of one specific browser. I don't know of any 3rd party developers using them. I think asm.js is brilliant and I hope it does turn out to be the way forward. But it's also a poster child for maintaining compatibility with existing browsers through standard Javascript.

pbsdp 13y ago

Introducing a browser bytecode and/or sandboxing is not anywhere near the scale of complexity and expense of inventing a new CPU architecture. It's a policy decision, not a technical decision.

gmac 13y ago
Replacing JS may not be technically difficult, but practically it's extremely difficult (IE6, anyone?). Plus JS has got so fast, it's becoming hard to see the point anyway.
- pbsdp 13y ago
  > Plus JS has got so fast, it's becoming hard to see the point anyway. Native is faster. A lot faster. And that's what browser apps are competing against.
  - klibertp 13y ago
    asm.js ? It's essentially almost typed intermediary language which can be directly/easily translated to CPU instructions.
    - rational_indian 13y ago
      Not fast enough apparently: https://developers.google.com/native-client/ https://developers.google.com/native-client/
gnaritas 13y ago
Getting your bytecode working in shipping in all browsers has proven to be impossible; there's a reason people compile to Javascript, it's the only practical choice.
- pbsdp 13y ago
  It's impossible because Mozilla won't work with Google, not because it's actually impossible.
  - gnaritas 13y ago
    Even if they did, that's not enough, you have to get it into all popular browsers, not just two. JavaScript works everywhere, you have to match that to have any hope of replacing it.
    - pbsdp 13y ago
      Two browsers is more than enough to shift the industry, and there's still nothing stopping you from supporting JS as a legacy compilation target.
      - gnaritas 13y ago
        No it isn't; if you can't get Microsoft and Apple on board, it won't shift. It'll take more than Mozilla and Google cooperating to replace JS.
        pbsdp 13y ago
        Ah, so it will lose because it will lose. So we can't implement it because we won't implement it. That's ridiculous. Mozilla is willing to stick their neck out there implementing a mobile phone operating system, but trying to deploy a sane runtime environment to replace JavaScript is just too risky?
        gnaritas 13y ago
        It is ridiculous, but it's also reality.
        pbsdp 13y ago
marshray 13y ago
Browser plugins are dead and they're not coming back. Yes, really. It's time to move on.
- pbsdp 13y ago
  Nobody is proposing that. Neither NaCL, PNaCL, nor asm.js are 3rd-party browser plugins. I agree that it's time to move on. It's time to treat the web as a real application platform, instead of as document model with a JavaScript scripting interface.
  - marshray 13y ago
    NaCL, PNaCL aren't plugins because they're features of one specific browser. I don't know of any 3rd party developers using them. I think asm.js is brilliant and I hope it does turn out to be the way forward. But it's also a poster child for maintaining compatibility with existing browsers through standard Javascript.