4 ms·
Who said anything about Java bytecode? Java bytecode != bytecode. "I don't want this at all. That's too close to ActiveX for comfort." It has nothing to do wi
by cromwellian 15y ago
Who said anything about Java bytecode? Java bytecode != bytecode.
"I don't want this at all. That's too close to ActiveX for comfort."
It has nothing to do with ActiveX. It has everything to do with dead-stripping code and targeting particular browsers the way GWT and Closure Compiler do today.
In particular, Javascript VMs today always parse JS even if it's already been cached, hasn't changed, and is loaded from the cache. They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices.
As for size, I believe there's a Microsoft paper floating around somewhere where they use a custom tokenized AST byte code format to achieve significant wire savings.
The reality is, Java on Android already starts up faster than Android and runs faster than JS, so there is ample evidence that JS is underperforming other environments, meanwhile, Android APKs are not any bigger than comparable JS apps from my anecdotal observations.
- rictic 15y agoI don't know about GWT, but in my experience closure compiler does not produce different output for different browsers (though it does strip dead code).
- cromwellian 15y agoIt has the ability, but doesn't not part of the default IIRC unlike GWT which is built around permutations. GMail I think varies permutations. However, there are sound reasons for wanting to do so besides differing DOM capabilities, namely, that different JS VMs have different performance characteristics and what may be an optimal pattern for one, isn't for another.
- ootachi 15y ago"They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices." Wrong. SpiderMonkey doesn't. It retains the bytecode only, throws away the original source, and uses a decompiler when toString() is used. V8 saves the original source, but that's its problem :)