Why are we limited to JS in browsers - would a bytecode standard help?

I've talked and written recently about why "just pick[ing] up Lua or Python" was not an option, but there are other strong reasons that was not in the cards.

Think about what mid-1990s Lua and Python were like, how much they needed to change in incompatible ways. The web browsers would never have tolerated that -- you'd get a fly-in-amber-from-1995-or-1996 version of Python or Lua, forced into a standards body such as Ecma (then ECMA), and then evolved slowly _a la_ ECMA-262 editions 2, 3, and (much later, after the big ES4 fight) edition 5.

Interoperation is hard, extant C Python and Lua runtimes were OS-dependent and as full of security holes, if not more full, than JS in early browsers, and yet these languages and others such as Perl were also destined to evolve rapidly in their virtuously-cycling open source communities, including server-side Linux and the BSDs (also games, especially in Lua's case -- Python too, but note the forking if not fly-in-amber effects: Stackless Python in Eve Online, e.g.).

JS, in contrast, after stagnation, has emerged with new, often rapidly interoperating, de-facto (getters, setters, array extras, JSON) and now de-jure (ES5) standards, the latter a detailed spec that far surpasses C and Scheme, say, in level of detail (for interop -- C and Scheme favor optimizing compiler writers and underspecify on purpose, e.g. order of evaluation).

The other languages you cite have been defined normatively over most or all of their evolving lives entirely by what their C implementations do. Code as spec, single source implementations do not cut it on the web, what with multiple competing open- and closed-source browsers.

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.

Lua (without JIT) is also one of the fastest non-JIT, non-native compiled languages there is. LuaJIT is also one of the faster JIT languages. Now, I'm not sure how it compares to the popular JS JIT engines, but from what I've read, its very hard to beat LuaJIT for performance.