It was really sad to see everybody moving to Flash JavaScript could've done video/audio and games a long time ago.

> That is something I could see Mozilla and Apple getting behind.

Why would you expect either Mozilla or Apple to get behind such a proposal? Apple has a powerful self-interest in making sure the Web remains a second-best app platform behind iOS and desktop OS X. Mozilla wants the Web to be the premier app platform - but it's no bloody good to Mozilla if the web is the world's #1 web platform but Mozilla has no control over it anymore. The last thing Mozilla wants to see is the Web browser become some fairly-easily-implemented, highly-interchangeable runtime platform adhering to a stable, open spec somewhere. This would, I think, be very good for the world at large, but it would undoubtedly be very bad for Mozilla - it's what is known as the commoditization of the platform. Mozilla's self-interest is served by keeping as much of the Web as possible controlled, in the minutest detail possible, by the hard-to-join club of major browser vendors. Right down to things like the lexical syntax of JavaScript. So in reality, as soon as Google proposed such an IL, Mozilla's advocates would start blowing smoke about "oh no, another Java".

Also, going back to 2006 or so when I invited pre-Google Alex Russell and other JS hackers to Ecma TC39 meetings, Mozillans including yours truly have tried to open up the standards process. Mozilla, Opera, and Apple co-founded the WHATWG and set up an open membership structure for it in 2004, to create HTML5. W3C finally relented and internalized much of that structure.

So alleging that "Mozilla" is trying to keep the old boy's club closed is simply false.

I've cited hard, in some cases physical (as in physics) reasons for why there won't be a lower-level bytecode standard for browser-based VMs any time soon. I'm not blowing smoke.

http://www.aminutewithbrendan.com/pages/20101122

A high level bytecode sounds a lot like minified JS source, with a relatively-few extensions to the standard language. Extending is easier than replacing or setting up a new, parallel cross-browser standard.

Your inflamed sense of grievance at "Mozilla" is misplaced. Mozilla has no control other than what users of our software delegate to us by trusting us enough to download and run our stuff. We do not have hundreds of millions in our browser advertising budgets. We do not have billions of revenue with which to influence people or pay for attention and distribution.

If we are really in the way of Web standards, I'll personally pull the plug.

Certainly, VM byte code languages are often simpler than silicon processors' machine languages; perhaps they offer safety guarantees; and perhaps they provide garbage collection. These are all big wins for language implementers targeting such VMs.

But what no virtual machine will ever do is make modules written in different source languages work together transparently. Any time one module calls another module written in a different language, at least one side of that boundary needs to be written with a detailed understanding of both languages' semantics.

Tiny details of the semantics influence the idioms people settle on in that language --- and interfaces are designed around those idioms. For example, JavaScript conditionals treat the empty array and the empty object as true, while Python conditionals treat them as false. Each of these facts shapes what people expect of a "natural" API in that language --- and that ensures that modules written in other languages will always "speak with an accent", or seem unnatural, at best.

You can define a common data world, as the .NET CLR does, and extend each source language to cover that world, but the effect is to change each participant language into a gloss on the common data world. This is why CoffeeScript fits seamlessly into the JavaScript world: JavaScript's and CoffeeScript's data worlds are exactly the same. CoffeeScript cannot deviate from JavaScript's types and objects.

Each programming language is like a city occupying an island: commerce within the city is much less expensive than commerce between islands. Although it's sometimes worth it, dealing with "foreigners" is confusing and risky. No VM will change that.

But even within the points you bring up, I'm not sure that VMs are as winning as they're made out to be. Size and compilation time aren't somehow intrinsically better for VMs; JS does quite well on both fronts these days. And I'm not convinced JS's quirks are harder for implementers to cope with than a silicon machine language's.

Mozilla "conspires" to do almost exactly the opposite of what you suggest. Having lots of decent browsers available was our old success condition. Now the mobile world is starting to look locked up, so breaking that open to competition and free choice is our new success condition.

Really? I thought that was the _mission_ of Mozilla. Except for the "stable" part perhaps, because that's quite at odds with innovation.

The track record easily shows that pretty much every single thing you have said is wrong.