I'm on Ecma TC39 and in touch with JS hackers working for all the major browser vendors. FWIW, as far as I can foresee there will be no standard JS bytecode. Co

I'm on Ecma TC39 and in touch with JS hackers working for all the major browser vendors. FWIW, as far as I can foresee there will be no standard JS bytecode. Commenters here touch on good reasons: * divergent, evolving VMs can't agree (not all NIH, see third bullet); * IPR concerns; * lowering from source over-constrains future implementation, optimization, and language evolution paths; * view-source still matters (less, but still). A binary encoding of JS ASTs, maybe (arithmetic coders can achieve good compression; see Ben Livshits' JSZap from MSR, and earlier work by Michael Franz and Christian Stork at UCI). But this too is just a gleam in my eye, not on TC39's radar. Meanwhile, we are making JS a lot better as a target language, with things like ES5 strict mode, the ES-Harmony module system and lexical scope all the way up (no global object in scope; built on ES5 strict), and WebGL typed arrays (shipping in Firefox 4). We have a Mozilla hacker, Alon Zakai, building an LLVM-based C++-to-JS compiler. Others are doing such things (along with good old SNES emulators and the like). So being a good mid-to-high-level, memory-safe compiler target language is on TC39's radar. Not to the exclusion of other JS desiderata, and never in a way that compromises mass-market usability or buy-by-the-yard rapid-protoyping "scriptability". But one among several goals.