8 ms·
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 de
by 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 agoReplacing 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 agoasm.js ? It's essentially almost typed intermediary language which can be directly/easily translated to CPU instructions.
- rational_indian 13y agoNot fast enough apparently: https://developers.google.com/native-client/ https://developers.google.com/native-client/
- gnaritas 13y agoGetting 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 agoIt's impossible because Mozilla won't work with Google, not because it's actually impossible.
- gnaritas 13y agoEven 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 agoTwo 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 agoNo 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 agoAh, 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 agoIt is ridiculous, but it's also reality.
- pbsdp 13y agoIt's reality because Mozilla makes it a reality. See how this is a circular argument? Meanwhile, native mobile and desktop keep growing, and growing, and the web as an application platform loses out, because none of the native platform vendors are quibbling about whether they can convince themselves to ever do something different than what they were doing before.
- marshray 13y agoBrowser plugins are dead and they're not coming back. Yes, really. It's time to move on.
- pbsdp 13y agoNobody 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 agoNaCL, 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.