7 ms·

Browsers don't need a programming language. Browsers need a standardized bytecode. The problem is, bytecode can have a significant impact on potential performan

Browsers don't need a programming language. Browsers need a standardized bytecode. The problem is, bytecode can have a significant impact on potential performance. So, as long as browsers are still competing on JS performance, they are actively disincentivized from pursuing standardization of a bytecode...

double051 14y ago
Bytecode for the web always fails. Remember Java applets and Flash? The great thing about javascript is that it can be hand-written and compiled-to.
- adrianN 14y ago
  I think the problem with Java applets and Flash was not the bytecode but the slow startup (Java) and the closed source software (Flash) as well as the poor integration with HTML. There is no reason why browsers couldn't implement the same functionality we have now with Javascript using a bytecode based VM.
  - jballanc 14y ago
    Browsers do implement Javascript using a bytecode based VM - https://github.com/WebKit/webkit/tree/master/Source/JavaScriptCore/bytecode https://github.com/WebKit/webkit/tree/master/Source/JavaScri... It just isn't standardized, or made available to website authors directly (there would likely need to be significant extra security audits before you could contemplate something like that...).
    - doublec 14y ago
      Not all browsers do this. At least one compiles directly to native machine code. Chrome's V8 does this according to http://stackoverflow.com/a/8819921 http://stackoverflow.com/a/8819921
  - tomjen3 14y ago
    Since you would need backwards compatability, just make an argument to script elementa that specify the byte code to use instead of the javascript. Then older browsers could continue to function and the rest of us don't have to wait.
- wingless 14y ago
  Flash was extremely successful, and it was a really great abstraction. What failed was Adobe's implementation, not the idea. Same with Java. JVM had (and AFAIK still has) a horrible cold startup time which locked the entire browser up, causing the user to curse profanely.
egillie 14y ago
Are you talking about something like Native Client? http://en.wikipedia.org/wiki/Google_Native_Client http://en.wikipedia.org/wiki/Google_Native_Client
- jballanc 14y ago
  NaCl is a side-long step in the right direction, but it gets almost as much wrong as it gets right: * You have to know what platform you're targeting (ARM vs. x86), which eliminates the browser/JS advantage of architecture abstraction * You have to recompile specifically for NaCl, which removes any potential benefit on binary reuse As others have noted, NaCl is closer to ActiveX-reborn than it is to a generic web runtime architecture.
lerouxb 14y ago
Bytecode on the web is a shitty idea. The minifiers and obfuscators out there are already breaking "view source" and with that the spirit of the web. Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot?
- icebraining 14y ago
  I think minifiers and obfuscators already destroyed any hope of learning from websites. But on the other hand, Github and the likes are a much better learning source than we ever had.
  - bmj 14y ago
    With the advent of pretty print in Chrome's web development console (and add-ons available for Firefox), minifiers are less of an issue for learning how a site works. I suspect that minifier arguments are no-win situations: either someone doesn't like that they can't easily read the JavaScript, or someone complains it takes too long to load the scripts for a given page.
    - nilved 14y ago
      I like sites that have a predictable `.min.js` convention; if I want to see the source code for `main.min.js`, I visit `main.js`.
- tomjen3 14y ago
  Only if you assume that view source was ever a good idea. If the writer wants you to see the source, you can download it elsewere (githun, etc) if not, there is no difference between not getting the source to office 98 and not getting the source to google docs.
  - coderdude 14y ago
    It was certainly a good idea. When the Web was young and there was no GitHub, viewing a page's source made it so that you could see by example how every page worked. It exposed you to a huge number of possibilities. The Web partially owes its success to this feature because without it far fewer people would have made it to the stage where they could produce their own pages. Every web developer/designer has used this to help them -- guaranteed. Besides, the feature would have sprung up anyway whether the browser vendors wanted it included or not. Third parties would have stepped in. It's plain text transmitted over the wire. Unlike the source of Office 98 which is not retrievable from the Office 98 binary, a page's source is readily available to the machine that has to cobble it all together when viewing that page.

double051 14y ago

Bytecode for the web always fails. Remember Java applets and Flash? The great thing about javascript is that it can be hand-written and compiled-to.

adrianN 14y ago
I think the problem with Java applets and Flash was not the bytecode but the slow startup (Java) and the closed source software (Flash) as well as the poor integration with HTML. There is no reason why browsers couldn't implement the same functionality we have now with Javascript using a bytecode based VM.
- jballanc 14y ago
  Browsers do implement Javascript using a bytecode based VM - https://github.com/WebKit/webkit/tree/master/Source/JavaScriptCore/bytecode https://github.com/WebKit/webkit/tree/master/Source/JavaScri... It just isn't standardized, or made available to website authors directly (there would likely need to be significant extra security audits before you could contemplate something like that...).
  - doublec 14y ago
    Not all browsers do this. At least one compiles directly to native machine code. Chrome's V8 does this according to http://stackoverflow.com/a/8819921 http://stackoverflow.com/a/8819921
- tomjen3 14y ago
  Since you would need backwards compatability, just make an argument to script elementa that specify the byte code to use instead of the javascript. Then older browsers could continue to function and the rest of us don't have to wait.
wingless 14y ago
Flash was extremely successful, and it was a really great abstraction. What failed was Adobe's implementation, not the idea. Same with Java. JVM had (and AFAIK still has) a horrible cold startup time which locked the entire browser up, causing the user to curse profanely.

egillie 14y ago

Are you talking about something like Native Client? http://en.wikipedia.org/wiki/Google_Native_Client http://en.wikipedia.org/wiki/Google_Native_Client

jballanc 14y ago
NaCl is a side-long step in the right direction, but it gets almost as much wrong as it gets right: * You have to know what platform you're targeting (ARM vs. x86), which eliminates the browser/JS advantage of architecture abstraction * You have to recompile specifically for NaCl, which removes any potential benefit on binary reuse As others have noted, NaCl is closer to ActiveX-reborn than it is to a generic web runtime architecture.

lerouxb 14y ago

Bytecode on the web is a shitty idea. The minifiers and obfuscators out there are already breaking "view source" and with that the spirit of the web. Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot?

icebraining 14y ago
I think minifiers and obfuscators already destroyed any hope of learning from websites. But on the other hand, Github and the likes are a much better learning source than we ever had.
- bmj 14y ago
  With the advent of pretty print in Chrome's web development console (and add-ons available for Firefox), minifiers are less of an issue for learning how a site works. I suspect that minifier arguments are no-win situations: either someone doesn't like that they can't easily read the JavaScript, or someone complains it takes too long to load the scripts for a given page.
  - nilved 14y ago
    I like sites that have a predictable `.min.js` convention; if I want to see the source code for `main.min.js`, I visit `main.js`.
tomjen3 14y ago
Only if you assume that view source was ever a good idea. If the writer wants you to see the source, you can download it elsewere (githun, etc) if not, there is no difference between not getting the source to office 98 and not getting the source to google docs.
- coderdude 14y ago
  It was certainly a good idea. When the Web was young and there was no GitHub, viewing a page's source made it so that you could see by example how every page worked. It exposed you to a huge number of possibilities. The Web partially owes its success to this feature because without it far fewer people would have made it to the stage where they could produce their own pages. Every web developer/designer has used this to help them -- guaranteed. Besides, the feature would have sprung up anyway whether the browser vendors wanted it included or not. Third parties would have stepped in. It's plain text transmitted over the wire. Unlike the source of Office 98 which is not retrievable from the Office 98 binary, a page's source is readily available to the machine that has to cobble it all together when viewing that page.