Cool, but sadly to me this is almost a parody of how modern web dev innovation HTML5/JS/CSS are so far behind the technology that actually exists in the world today (this was originally created in 1977). Web standards are good, but much faster and be far more "open" and expandable.
One suggestion. 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. This may be self defeating for these clowns, because JavaScript/CSS/HTML may be decimated in a decade if they actually did this, but hey... One can hope.
Once Google firmly owns the browser (like Microsoft in the 2000s) one of two things will happen. One they say to hell with the standards board and push real innovation and opportunity for developers to innovate. Two, they will sit and let it stagnate. Either way, the cycle is coming around again. Android will own the market in a big way soon. Big opportunity is on the horizon and I am getting my hopes up that there is a big shake up with "browser standards". End the monopoly of lame markup, styling, and scripting (HTML/CSS/JS) in the OS of the internet.
"this is almost a parody of how modern web dev innovation HTML5/JS/CSS are so far behind the technology that actually exists in the world today (this was originally created in 1977)"
That's a weird opinion. The original was analog, created by several people and shoot carefully in specific conditions. This HTML version was made by a guy in his bedroom in a fraction of a time and is sharable, editable and can be viewed on many devices, including mobile, instead of just a movie theatre like the original. For me this is innovation across the board (not only in web standards, but technology overall)
> 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.
"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.
>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.
One suggestion. 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. This may be self defeating for these clowns, because JavaScript/CSS/HTML may be decimated in a decade if they actually did this, but hey... One can hope.
How would that bytecode be any less of a "monopoly" than ECMA Script is now?
Web standards may be "far behind" in what they can do compared to native code, but their are far, far, far ahead in terms of giving some control back to the user, whether it's in terms of enabling browser extensions, letting content be viewed without running arbitrary code, doing presentation transformations (e.g. Readability), well defined semantics for sharing content (links), etc.
Your suggestion would grant some more power to developers, at the expense of users. So thanks, but no thanks.
"create a standard for a VM that other languages can compile bytecode to. Create an API in this VM for graphics, video, audio."
There already is a standard VM with an API for graphics, video and audio - it's called HTML5, and, as a bonus, it also includes an API for text layout. Sure, if you sat down intending to design such a VM, you might not come up with HTML5, but so what; what concrete improvement would you get by distributing programs as bytecode rather than JavaScript?
One suggestion. 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. This may be self defeating for these clowns, because JavaScript/CSS/HTML may be decimated in a decade if they actually did this, but hey... One can hope.
Once Google firmly owns the browser (like Microsoft in the 2000s) one of two things will happen. One they say to hell with the standards board and push real innovation and opportunity for developers to innovate. Two, they will sit and let it stagnate. Either way, the cycle is coming around again. Android will own the market in a big way soon. Big opportunity is on the horizon and I am getting my hopes up that there is a big shake up with "browser standards". End the monopoly of lame markup, styling, and scripting (HTML/CSS/JS) in the OS of the internet.