There’s been a lot of discussion about ECMAScript 4 lately. The overview whitepaper was recently released as well (which I equate to little more than a public relations ploy). Those who were in my birds-of-a-feather discussion at the Rich Web Experience know of my utter disdain for ECMAScript 4, and nothing I’ve read thusfar has changed my mind.
Chris Wilson just blogged about it as well. I echo his sentiment that we need to move forward without breaking the Web. Microsoft has been criticized in the past for not immediately jumping on the standards bandwagon. While it’s hurt in some ways, their reason is solid: too many web sites and applications rely on the way things currently work to just abandon “wrong” implementations.
Gabriele Renzi blogged about it as well, stating that ECMAScript 4 changes ECMAScript 3 too much. I concur with this evaluation as well. ECMAScript 4 is not an evolution, it’s a revolution, and revolutions are as destructive as they are exciting. And it’s the destructive part that I’m concerned about.
The main question I ask those who are in support of ECMAScript 4 or those who are working on it is this: what problem is it solving? What is it that ECMAScript 4 introduces that we absolutely can’t either a) do now with ECMAScript 3 or b) live without. Array comprehensions? I’ve never had a need for them. True classes and interfaces? I’ve done fine without them to this point. Packages and namespaces? Haven’t really stopped me. Private members? Don’t really see the need.
On top of that, ECMAScript 4 “fixes” things in ECMAScript 3, meaning that your knowledge is no longer useful. John Resig just posted a list of fixes that ECMAScript 4 makes to the language. Most of the things he lists are questionable, in my opinion, as to their value, especially since they can’t be implemented in an ECMAScript 3 environment because it will cause code to break. That means the upgrade path from 3 to 4 is not a straight line, which further aggravates me.