7 ms·

Yea I'm crossing my fingers that asm.js eventually leads to a real bytecode VM in browsers and Javascript simply becomes a language that targets it. For large

Yea I'm crossing my fingers that asm.js eventually leads to a real bytecode VM in browsers and Javascript simply becomes a language that targets it. For large applications compiling to asm.js (such as Unity3D) this experiment could provide significant gains in load time. Considering games usually spend their initial time presenting a menu, background loading of the fast-path makes a ton of sense.

beagle3 12y ago
Other than load time (which the emterpreter already makes great advances on), what other advantages does a bytecode carry? I don't see "load time" as a good enough reason for a revolution of this magnitude. Do you?
- jdmichal 12y ago
  Binary sizes, which would even further improve startup times, along with reducing network usage (and thereby hosting costs). GZip works just as good on binaries as it does on JavaScript.
  - beagle3 12y ago
    There are two things here: 1. [citation needed] and a [specific bytecode] needed. Details are everything: an uncompressed .dex file is comparable to a gzipped compile jvm class file; Also, with a specific bytecode in mind, if you compared minified+gzipped gs to gzipped bytecode, I suspect the difference will be small. 2. Regardless, the benefit of binary size is already provided, yesterday, with the emterpreter, without requiring any buy in from any browser vendor. So, again - what's the benefit, other than startup time (which might be solved in other ways) of a universal browser bytecode?
    - iopq 12y ago
      If you read the article, it downloads the full sized binary later. So actually the size with the emterpreter is higher
      - beagle3 12y ago
        I commented on another thread, that I believe a future version of the emterpreter will generate the full JS back from the bytecode, thus eliminating that problem - it will increase the emterpreter size by a few tens of Ks, but that will probably by cached everywhere through CDNs. And even if it never does - it's politically close to impossible to agree on a universal bytecode, so it is extremely unlikely to happen. (Google already tried with PNaCl - if they can't pull it, I doubt anyone else can)

beagle3 12y ago

Other than load time (which the emterpreter already makes great advances on), what other advantages does a bytecode carry? I don't see "load time" as a good enough reason for a revolution of this magnitude. Do you?

jdmichal 12y ago
Binary sizes, which would even further improve startup times, along with reducing network usage (and thereby hosting costs). GZip works just as good on binaries as it does on JavaScript.
- beagle3 12y ago
  There are two things here: 1. [citation needed] and a [specific bytecode] needed. Details are everything: an uncompressed .dex file is comparable to a gzipped compile jvm class file; Also, with a specific bytecode in mind, if you compared minified+gzipped gs to gzipped bytecode, I suspect the difference will be small. 2. Regardless, the benefit of binary size is already provided, yesterday, with the emterpreter, without requiring any buy in from any browser vendor. So, again - what's the benefit, other than startup time (which might be solved in other ways) of a universal browser bytecode?
  - iopq 12y ago
    If you read the article, it downloads the full sized binary later. So actually the size with the emterpreter is higher
    - beagle3 12y ago
      I commented on another thread, that I believe a future version of the emterpreter will generate the full JS back from the bytecode, thus eliminating that problem - it will increase the emterpreter size by a few tens of Ks, but that will probably by cached everywhere through CDNs. And even if it never does - it's politically close to impossible to agree on a universal bytecode, so it is extremely unlikely to happen. (Google already tried with PNaCl - if they can't pull it, I doubt anyone else can)