As for your idea of compiling to some bytecode, if one wants to minimize sandboxing overhead, the representation needs to carry along with it an efficiently machine-checkable proof that it is well behaved. There are other ways to do this, but a sound static type system is the most well researched way of doing this. On top of this, the semantics of JavaScript aren't very clean, so there's a tension between making the semantics of the representation a good target for JavaScript and making the semantics of the representation a good target for non-JavaScript languages.
A stack-based bytecode would likely yield the best code size (at least in the absence of compression). An SSA-based representation is most attractive from the standpoint translating to the most optimized native code. A register machine representation is a good happy medium for fast interpreters and pretty good tracing JITs. People also occasionally float the idea of shipping around compressed syntax trees to at least cut down on bandwidth usage and time taken to tokenize and parse JS, as a least disruptive option.
In the end, I think there are too many options and too many players with conflicting goals for a standards committee to come up with a solution that gets widely adopted, so we'll need the invisible hand of the market to sort out the competing ideas.
At present, I think the closest we've got to your ideal is LLVM bitcode via Google's PNaCl plugin. Emscripten can generate JavaScript from LLVM bitcode, closing the loop, but I'm not aware of any production systems that target PNaCl with an Emscripten fallback for browsers that don't understand PNaCl.
Edit: s/space usage/bandwidth usage/, note that compressed syntax trees are the least disruptive option. Those wishing to disrupt the browser language landscape probably don't want the least disruptive option, but it's probably preferable to a lower level representation that too closely matches the semantics of JS, as that would tend to force JS semantics deeper into the VM's implementation.
And that's the heart of it all. If we had a static low-level highly optimized language, im sure we'd all compile javascript or whatever to it, especially if we can add on type checking and other optimizations.
HOWEVER, we cannot. That's the issue. So JS is the web's most low-level language at the moment.
A stack-based bytecode would likely yield the best code size (at least in the absence of compression). An SSA-based representation is most attractive from the standpoint translating to the most optimized native code. A register machine representation is a good happy medium for fast interpreters and pretty good tracing JITs. People also occasionally float the idea of shipping around compressed syntax trees to at least cut down on bandwidth usage and time taken to tokenize and parse JS, as a least disruptive option.
In the end, I think there are too many options and too many players with conflicting goals for a standards committee to come up with a solution that gets widely adopted, so we'll need the invisible hand of the market to sort out the competing ideas.
At present, I think the closest we've got to your ideal is LLVM bitcode via Google's PNaCl plugin. Emscripten can generate JavaScript from LLVM bitcode, closing the loop, but I'm not aware of any production systems that target PNaCl with an Emscripten fallback for browsers that don't understand PNaCl.
Edit: s/space usage/bandwidth usage/, note that compressed syntax trees are the least disruptive option. Those wishing to disrupt the browser language landscape probably don't want the least disruptive option, but it's probably preferable to a lower level representation that too closely matches the semantics of JS, as that would tend to force JS semantics deeper into the VM's implementation.