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?
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)
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?