3 ms·

> It turns out that C++ compiled to JavaScript can run at about half the speed of native code, which in some cases outperforms Java, and is expected to get bett

> It turns out that C++ compiled to JavaScript can run at about half the speed of native code, which in some cases outperforms Java, and is expected to get better still. Those numbers are when using the asm.js subset of JavaScript, which basically structures the compiler output into something that is easier for a JS engine to optimize. It's still JavaScript, so it runs everywhere and has full backwards compatibility, but it can be run at near-native speed already today. The problem that many people have with web browsers is that they have evolved from retrieving text to become bloated, Frankensteinish wannabe operating systems that perform redundant operations at slower speeds. It is the job of the underlying operating to execute programs, not the web browser's. Constructing a redundant operating system and executing code at half the possible speed (at best!) is not progress.

azakai 13y ago
I would say it is progress, if 1. The browser executes programs in a totally platform-independent way, which the underlying OS cannot (a website should be able to run on all browsers and on all OSes). So having the browser run code is useful too. 2. That "half speed" number was the status as of a few months ago, and is still improving.
- LowKarmaAccount 13y ago
  > The browser executes programs in a totally platform-independent way JS has different scripting engines and different dialects, so it isn't really platform independent in the sense that the same code will execute the same way on every computer. In fact, it's possible for JS to execute in different ways on the same computer when you run the code on browsers with different engines. There are plenty of instances were a page will not render the same way in different browsers (although this is usually because HTML use isn't consistent). > That "half speed" number was the status as of a few months ago, and is still improving. It's still an effort to reinvent the wheel. When a 1:1 ratio is reached, you (not you in particular) will still have ended up spending time implementing a feature that already exists on your OS, instead of improving the original program. For example, browsers have pdf readers baked in. Now you have a dedicated pdf reader on the desktop, and a slower, buggier pdf reader on the browser. The problem is that programs on the desktop don't communicate well with each other to get the same kind of integration you get on a browser, or the underlying OS doesn't include programs to implement features that you want to include on your web page. I understand that it may be simpler to turn a web browser into a mini OS rather than get OS authors to change their OS (the Chromebook is a misguided attempt to take this to its logical end), but it is still an ugly and redundant solution.
  - azakai 13y ago
    JS, for the most part, does run identically on different browsers. With very few cases of truly undefined behavior, any other difference is either DOM stuff, or a bug. I've ported lots of apps to JS, and generally they just work across browsers. Even the Unreal Engine 3 demo runs on Chrome, JS was not what was holding it back. > It's still an effort to reinvent the wheel. When a 1:1 ratio is reached, you (not you in particular) will still have ended up spending time implementing a feature that already exists on your OS The OS can run it, but native apps are not portable, as I said before. That is what makes it worth reinventing some parts of OSes in browsers.
jabr 13y ago
The browser I'm using at the moment is faster than the one I was using three years ago, despite also having a very large number of new abilities. Further, a significant number of my current OS processes are currently executing programs themselves (with various degrees of dynamic compilation). I'm not clear on when it's okay for a process to itself execute a program. Is interpretation ever okay? Or does it always need to be dynamically compiled? Also, what's the rule on compilation of turing complete languages like Postscript?

azakai 13y ago

I would say it is progress, if 1. The browser executes programs in a totally platform-independent way, which the underlying OS cannot (a website should be able to run on all browsers and on all OSes). So having the browser run code is useful too. 2. That "half speed" number was the status as of a few months ago, and is still improving.

LowKarmaAccount 13y ago
> The browser executes programs in a totally platform-independent way JS has different scripting engines and different dialects, so it isn't really platform independent in the sense that the same code will execute the same way on every computer. In fact, it's possible for JS to execute in different ways on the same computer when you run the code on browsers with different engines. There are plenty of instances were a page will not render the same way in different browsers (although this is usually because HTML use isn't consistent). > That "half speed" number was the status as of a few months ago, and is still improving. It's still an effort to reinvent the wheel. When a 1:1 ratio is reached, you (not you in particular) will still have ended up spending time implementing a feature that already exists on your OS, instead of improving the original program. For example, browsers have pdf readers baked in. Now you have a dedicated pdf reader on the desktop, and a slower, buggier pdf reader on the browser. The problem is that programs on the desktop don't communicate well with each other to get the same kind of integration you get on a browser, or the underlying OS doesn't include programs to implement features that you want to include on your web page. I understand that it may be simpler to turn a web browser into a mini OS rather than get OS authors to change their OS (the Chromebook is a misguided attempt to take this to its logical end), but it is still an ugly and redundant solution.
- azakai 13y ago
  JS, for the most part, does run identically on different browsers. With very few cases of truly undefined behavior, any other difference is either DOM stuff, or a bug. I've ported lots of apps to JS, and generally they just work across browsers. Even the Unreal Engine 3 demo runs on Chrome, JS was not what was holding it back. > It's still an effort to reinvent the wheel. When a 1:1 ratio is reached, you (not you in particular) will still have ended up spending time implementing a feature that already exists on your OS The OS can run it, but native apps are not portable, as I said before. That is what makes it worth reinventing some parts of OSes in browsers.

jabr 13y ago

The browser I'm using at the moment is faster than the one I was using three years ago, despite also having a very large number of new abilities. Further, a significant number of my current OS processes are currently executing programs themselves (with various degrees of dynamic compilation). I'm not clear on when it's okay for a process to itself execute a program. Is interpretation ever okay? Or does it always need to be dynamically compiled? Also, what's the rule on compilation of turing complete languages like Postscript?