WHATWG Weekly: Happy New Year!
Happy new year everyone! We made great progress in standardizing the platform in 2011 and plan to continue doing just that with your help. You can join our mailing list to discuss issues with web development or join IRC if you prefer more lively interaction.
I will be taking the remainder of the month off and as nobody has volunteered thus far, WHATWG Weekly is unlikely to be updated in January. All the more reason to follow email and IRC.
Since last time the toBlob() method of the canvas element has been updated in revisions 6879 and 6880 to make sure it honors the same-origin policy (for exposure of image data) and handles the empty grid.
In the land of ECMAScript a proposal was made to avoid versioning by David Herman, which if successful will keep ECMAScript simple and more in line with other languages used on the web.
What is the statement that avoiding versioning is “more in line with other languages used on the web” based on? I guess if you count HTML (and if you’re talking about programming languages, you shouldn’t), there’s one.
But PHP has versions, Python has versions, Perl has versions, Java has versions, Actionscript has versions. I’m not going to rank which is most popular, but I think between those 5 you have 90% of web programming using version-based languages.
John, the versioning in question refers to being able to “opt in” to new language features (“use version 6;”), not whether the language gains a numbered edition (the “6” in ECMAScript 6). I am not familiar with Perl, Python and Actionscript, but in PHP and Java you don’t explicitly opt in to a specific version, you just get error messages if your compiler or runtime is too old.
I appreciate the distinction, and was reacting mainly based on the idea that this no-versioning was similar to WHATWG’s no versioning rhetoric. But not using a version flag of some sort for new versions ECMAScript poses its own danger.
In most languages, you opt-in by using a runtime that only supports the new version of the language (although that runtime may not be newer than the newest runtime of the old version of the language, most languages (at least open source ones with large communities) will maintain parallel development of an old version runtime and a new version runtime for a period of time whenever there are compatibility breaking changes).
EMACScript is complicated by the fact that its most significant usage is bound to browsers who can’t choose whether to opt-in/out by choosing a runtime. It’s true that users who like applications that only ran on the older version of EMACScript (say for a media company that made a killer web app, fired its development team but still had a significant fan base) could choose to use an older browser, but that prevents them from utilizing any of the improvements that the browser makes in other parts of the browser platform.
The danger is you may get a situation like the way the corporate world has with IE6/7. A lot of places use ActiveX applications that don’t work in IE 8, and so they persist in using a browser with significant security issues to avoid losing a critical application.
All that said, you could ask the browsers to do the same thing they did while transitioning the world from Javascript 1.0 to 1.1 – have special values for the script tag attributes. This would also preserve the distinction between javascript the language and the browser’s implementation.