[jacquesm]

> Don't just create a standard for (monopoly) ECMA Script, instead - create a standard for a VM that other languages can compile bytecode to. Create an API in this VM for graphics, video, audio, ETC.

Please no. That's the opposite of where we should be going. Less executable code on the client, more powerful markup.

JavaScript was a huge mistake that we will likely have to live with for decades, let's not compound it.

[jerf]

"Less executable code on the client, more powerful markup."

Well, since when it comes to layout, the union of everybody's desires appears to be simply Every Possible Thing, your more powerful markup is going to end up being executable code anyhow. If you specify a Turing-complete set of needs, you're going to need a Turing-complete language to satisfy them.

You can already see this happening even in CSS, and the more they try to pretend that CSS isn't code (even though it increasingly is), the more frustrating it's going to get for everyone when you end up with a bug in your CSS, which you are not allowed to fix due to the fact that we're all pretending it's not code.

[anon1385]

>Less executable code on the client, more powerful markup. JavaScript was a huge mistake that we will likely have to live with for decades, let's not compound it.

That ship has well and truly sailed. Mozilla and Google both want to make the web into a general purpose app platform, and they have veto power over any proposed standards. Admittedly they both want a slightly different version of the idea (asm.js vs Dart or NaCl), but that gridlock just leaves us investing even more heavily into the current Javascript ecosystem.

[kaoD]

Markup and JavaScript are orthogonal concepts.

[jacquesm]

Lots of concepts that are now part of HTML5 could only be done with Javascript in earlier incarnations.

[kaoD]

Although you're right, they're still orthogonal concepts. Powerful markup does not replace JavaScript for all use cases.