5 ms·

For some time now I've been wondering why the primary scripting format consumed by browsers is JavaScript (a language intended for humans) and not some sort of

by hetman 15y ago

For some time now I've been wondering why the primary scripting format consumed by browsers is JavaScript (a language intended for humans) and not some sort of standard bytecode that would be executed in a browser's virtual machine. What we need is the JSVM! In other words, something like the JVM but adapted for the browser. That probably means it would have a more dynamic typing focus since it makes sense for JavaScript to be the primary language targeted by the system (though there's no reason this couldn't evolve over time just like the JVM has). All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy.

Drakim 15y ago
I'm sure we could have some sort of JSVM, we could even have some sort of bytecode for the HTML, but it would destroy part of what makes the web so great: it's openness. The ability to view the source of any webpage, and even make chances and enhance it locally. There is also the fact that certain optimization can only be done by the browser if it has the actual source code rather than the compiled bytecode.
- deleted 15y ago
  [deleted]
- vilya 15y ago
  I think you're arguing a bit of a strawman when you mention viewing page sources: the discussion is about replacing JavaScript, not HTML. In any case, the fact that (non-web) applications are compiled into binaries hasn't stopped open source from flourishing.
- hetman 15y ago
  Not really. HTML would remain HTML. We're talking about JavaScript, and that is already minified (and sometimes obfuscated) beyond recognisability for a human. I'd be curious to hear what kind of optimisations become unavailable.
- justncase80 15y ago
  In both .net and java there exists excellent decompilation tools where you can easily decompile the bytecode back into java or C# or anyother language. It's not necessarily going to give you the original source code (especially missing comments) but it works incredibly well nonetheless. You could easily debug in it and edit it dynamically in browser tools as well. This is pretty much a solved problem. I wouldn't consider this a limitation worth talking about again.
- justncase80 15y ago
  Those optimizations can happen in the compiler that transforms the code into bytecode anyway.
- tomjen3 15y ago
  You have already lost that. Go look at the source code for cuttherope.ie and tell me that you learned anything. It might as well have been binary.
hannes2000 15y ago
Lots of essential Python features are not part of the language, but belong to its standard library. The thing that makes JavaScript so portable is that it basically has no such thing (except maybe Date and Math). So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. And you would have to do that for each language you want to support.
- ttt_ 15y ago
  You also would not be able to minify it properly because of whitespace identation constraints. Or am I off on this?
  - lloeki 15y ago
    Minifying is a compression hack. Just get the files served compressed with a proper algorithm. gzip compresses whitespace just fine.
  - read_wharf 15y ago
    You can compact a lot of whitespace out of python. $ cat hello.py def helloooo(): print "helloooo" print "SLAM!" helloooo() $ cat hellomin.py def helloooo(): print "helloooo"; print "SLAM!" helloooo()
  - hannes2000 15y ago
    Or you could deliver your JSVM bytecode as binary files (which reveals a new set of drawbacks)
  - hetman 15y ago
    If we're compiling to bytecode there is no need to minify.
- azakai 15y ago
  > So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. You would ship it once. Websites already do not download jquery etc. more than once. In fact websites can use those libraries from standard locations on the web so that multiple websites don't need multiple downloads of large libraries.
pornel 15y ago
We do have that VM. It just happens that this VM's "bytecode" looks like JavaScript. Here is Python running in the browser: http://syntensity.com/static/python.html http://syntensity.com/static/python.html
- batista 15y ago
  Yes. And it just happens that it's optimized for js and sucks compared to a lower level VM. Not to mention the extra overhead, not having proper traces for exceptions, source-line equivalency on errors, etc.
- dhconnelly 15y ago
  Sorry, but this is not good enough. This argument is made all the time, but all you're really saying is that every other language should be a second-class citizen to JavaScript. Emscripten is a cool technical hack, but why the fuck is it 2012 and we have to compile C++ to JavaScript?
  - MatthewPhillips 15y ago
    Browsers supporting JavaScript and some other bytecode format would bring web innovation to a crawl. I think once browsers are able to debug in the originating languages people will stop complaining about this.
    - nknight 15y ago
      Arrogant people preemptively declaring failure and trying to enforce their baseless declarations on others is what brings innovation to a crawl.
      - MatthewPhillips 15y ago
        Come on now, that's a bit harsh. There are really smart people who have been trying this exact thing for years without success. Microsoft tried harder than anyone to make "JScript" part of .NET but finally gave up and Windows 8 has 2 first-class VMs.
icebraining 15y ago
For some time now I've been wondering why the primary scripting format consumed by browsers is JavaScript (a language intended for humans) and not some sort of standard bytecode that would be executed in a browser's virtual machine. Because that's how it was initially. And initially - before github and minifiers - that was very important as a way of helping people learn by being able to study the code of other websites.
wladimir 15y ago
All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy. Yes please. Just define a straightforward VM in the browser and be done with it. Let the coders handle the rest, and compile any of their favorite languages to it (they will!). Java was on the right track, too bad the implementation (and APIs) were so clunky instead of nicely integrated, otherwise we'd never have needed the JS, Flash, Silverlight, Java applets, HTML5 mess that we're in now. Anyway, hindsight is 20/20, now we can just settle on JS as a target VM. Too bad it's implemented slightly different in every browser, making it inconvenient as intermediate format. Also, going through a dynamic language is an inefficient level of indirection if you want to program in a static language. You throw away information that could have been used to optimize.
gizzlon 15y ago
Parrot in the browser! Don't really know a lot about it, to be honet, but it could work :) "Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. Parrot is not about parrots, though we are rather fond of them for obvious reasons." http://www.parrot.org/ http://www.parrot.org/ http://duckduckgo.com/Parrot_virtual_machine http://duckduckgo.com/Parrot_virtual_machine
gringomorcego 15y ago
This is called NACL. And as great as it is, what we really need are on-the-fly compilers/interpreters. The web needs to be open. As much as this would appease those who want privacy/drm for their code, we all know what road this leads to. Eventually we will be forced to execute certain binaries to browse certain portions of the web. The Urchin.exe forced to execute while we divulge our lives in our browsing habits. Google/Facebook will track us, we'll know it, and we won't be able to function without it. We do need a vm. But more than that, we need transparency in the future choices of web standards. Their are powers-that-be that are simply salivating at how quickly developers will evangelize this technology. All I'm trying to say is the battle seems quite planned and half-done already, and I'm not sure anyone understands the long-term consequences. I sure don't.

by hetman 15y ago

Drakim 15y ago

I'm sure we could have some sort of JSVM, we could even have some sort of bytecode for the HTML, but it would destroy part of what makes the web so great: it's openness. The ability to view the source of any webpage, and even make chances and enhance it locally. There is also the fact that certain optimization can only be done by the browser if it has the actual source code rather than the compiled bytecode.

deleted 15y ago
[deleted]
vilya 15y ago
I think you're arguing a bit of a strawman when you mention viewing page sources: the discussion is about replacing JavaScript, not HTML. In any case, the fact that (non-web) applications are compiled into binaries hasn't stopped open source from flourishing.
hetman 15y ago
Not really. HTML would remain HTML. We're talking about JavaScript, and that is already minified (and sometimes obfuscated) beyond recognisability for a human. I'd be curious to hear what kind of optimisations become unavailable.
justncase80 15y ago
In both .net and java there exists excellent decompilation tools where you can easily decompile the bytecode back into java or C# or anyother language. It's not necessarily going to give you the original source code (especially missing comments) but it works incredibly well nonetheless. You could easily debug in it and edit it dynamically in browser tools as well. This is pretty much a solved problem. I wouldn't consider this a limitation worth talking about again.
justncase80 15y ago
Those optimizations can happen in the compiler that transforms the code into bytecode anyway.
tomjen3 15y ago
You have already lost that. Go look at the source code for cuttherope.ie and tell me that you learned anything. It might as well have been binary.

hannes2000 15y ago

Lots of essential Python features are not part of the language, but belong to its standard library. The thing that makes JavaScript so portable is that it basically has no such thing (except maybe Date and Math). So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. And you would have to do that for each language you want to support.

ttt_ 15y ago
You also would not be able to minify it properly because of whitespace identation constraints. Or am I off on this?
- lloeki 15y ago
  Minifying is a compression hack. Just get the files served compressed with a proper algorithm. gzip compresses whitespace just fine.
- read_wharf 15y ago
  You can compact a lot of whitespace out of python. $ cat hello.py def helloooo(): print "helloooo" print "SLAM!" helloooo() $ cat hellomin.py def helloooo(): print "helloooo"; print "SLAM!" helloooo()
- hannes2000 15y ago
  Or you could deliver your JSVM bytecode as binary files (which reveals a new set of drawbacks)
- hetman 15y ago
  If we're compiling to bytecode there is no need to minify.
azakai 15y ago
> So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. You would ship it once. Websites already do not download jquery etc. more than once. In fact websites can use those libraries from standard locations on the web so that multiple websites don't need multiple downloads of large libraries.

pornel 15y ago

We do have that VM. It just happens that this VM's "bytecode" looks like JavaScript. Here is Python running in the browser: http://syntensity.com/static/python.html http://syntensity.com/static/python.html

batista 15y ago
Yes. And it just happens that it's optimized for js and sucks compared to a lower level VM. Not to mention the extra overhead, not having proper traces for exceptions, source-line equivalency on errors, etc.
dhconnelly 15y ago
Sorry, but this is not good enough. This argument is made all the time, but all you're really saying is that every other language should be a second-class citizen to JavaScript. Emscripten is a cool technical hack, but why the fuck is it 2012 and we have to compile C++ to JavaScript?
- MatthewPhillips 15y ago
  Browsers supporting JavaScript and some other bytecode format would bring web innovation to a crawl. I think once browsers are able to debug in the originating languages people will stop complaining about this.
  - nknight 15y ago
    Arrogant people preemptively declaring failure and trying to enforce their baseless declarations on others is what brings innovation to a crawl.
    - MatthewPhillips 15y ago
      Come on now, that's a bit harsh. There are really smart people who have been trying this exact thing for years without success. Microsoft tried harder than anyone to make "JScript" part of .NET but finally gave up and Windows 8 has 2 first-class VMs.

icebraining 15y ago

For some time now I've been wondering why the primary scripting format consumed by browsers is JavaScript (a language intended for humans) and not some sort of standard bytecode that would be executed in a browser's virtual machine. Because that's how it was initially. And initially - before github and minifiers - that was very important as a way of helping people learn by being able to study the code of other websites.

wladimir 15y ago

All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy. Yes please. Just define a straightforward VM in the browser and be done with it. Let the coders handle the rest, and compile any of their favorite languages to it (they will!). Java was on the right track, too bad the implementation (and APIs) were so clunky instead of nicely integrated, otherwise we'd never have needed the JS, Flash, Silverlight, Java applets, HTML5 mess that we're in now. Anyway, hindsight is 20/20, now we can just settle on JS as a target VM. Too bad it's implemented slightly different in every browser, making it inconvenient as intermediate format. Also, going through a dynamic language is an inefficient level of indirection if you want to program in a static language. You throw away information that could have been used to optimize.

gizzlon 15y ago

Parrot in the browser! Don't really know a lot about it, to be honet, but it could work :) "Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. Parrot is not about parrots, though we are rather fond of them for obvious reasons." http://www.parrot.org/ http://www.parrot.org/ http://duckduckgo.com/Parrot_virtual_machine http://duckduckgo.com/Parrot_virtual_machine

gringomorcego 15y ago

This is called NACL. And as great as it is, what we really need are on-the-fly compilers/interpreters. The web needs to be open. As much as this would appease those who want privacy/drm for their code, we all know what road this leads to. Eventually we will be forced to execute certain binaries to browse certain portions of the web. The Urchin.exe forced to execute while we divulge our lives in our browsing habits. Google/Facebook will track us, we'll know it, and we won't be able to function without it. We do need a vm. But more than that, we need transparency in the future choices of web standards. Their are powers-that-be that are simply salivating at how quickly developers will evangelize this technology. All I'm trying to say is the battle seems quite planned and half-done already, and I'm not sure anyone understands the long-term consequences. I sure don't.