Producing a truly language-neutral VM would be an interesting goal, one that no-one's really got that close to achieving. (I think Microsoft's got closest.) Making it a compact wire format to boot would be... challenging.

Ultimately, a VM is just another language with lousy readability.

I see your point, but I think a VM spec comes with an implicit promise that it is OK to develop languages as opposed to the "why don't you just program in what we give you?" mantra.

I agree its a very hard problem. If I was starting from scratch I would probably look a lot more on vector operations than someone would have 10 years ago. Plus the manner of parallelism a person choses would seriously influence language implementors.

Some kind of flexible bytecode implemented across browsers would be fantastic, and you could always implement a fallback interpreter in javascript (or if feeling fancy, a decompiler).

Isn't Javascript a flexible bytecode?

Well, yes, but it comes with all the overhead of being a (partly) flawed language. Having a bytecode that allows, for instance, optional static and dynamic types would be much more direct than relying on type inference or separate native APIs (as are being introduced). Of course we have javascript now, so pragmatically languages should be compiled to it if we want them, but if there were to be an additional web bytecode, there would be many areas for improvement in terms of performance and safety.

JavaScript is a programming language that compiles to bytecode. It can be treated as object code, but it is a very different and higher-level thing than the term "bytecode" generally denotes.

Calling JavaScript "flexible bytecode" is like saying that all Turing-complete programming languages are the same, or that all objects capable of driving a nail into a piece of wood are equivalent. It's true in a very facile way. JavaScript can be treated kind of like bytecode, and all Turing-complete languages can be treated as a simulation of a Turing machine, but the details that these rough descriptions miss are more numerous and more significant than the details that actually went into forming the generalization.

JavaScript is a programming language that compiles to bytecode. It can be treated as object code, but it is very different and higher-level thing than the term "bytecode" generally denotes.

Yes a VM would be nice. Or LLVM + native client, "portable native client", Google is (was?) working on this in Chromium.

LLVM code with access to the DOM would be fine by me. Security would probably take a while to audit.

"The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler), and as a human readable assembly language representation. This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations. The three different forms of LLVM are all equivalent. This document describes the human readable representation and notation." http://llvm.org/docs/LangRef.html#abstract