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.
I don't really see ECMAScript 4 as the next step in JavaScript's development; I see it as a completely different language. It's part Python, part Java, with a sprinkle of JavaScript. It's a new language, not the logical extension of an existing one...I just wish that everyone would start treating it accordingly.
By the way, I have no intention of using JavaScript 2. Ever.
You'r right about that this version is too much different, but the changes that comes with it where to much expected!
The solely implementation of ECMAScript 4 (AFAIK) is Adobe's ActionsScript 3... so one could imagine what kind of apps it's targeted to... RIA's with a client runtime. Even MS is introducing those functional programming concepts with F# (Yes! Array comprehensions also...). So I think it is a different stuff, not evil at all, but a different thing.
Personally, speaking only as an amateur, I am looking forward to EMCAScript 4, athough I can see your point that EMCAScript 4 could effectively be seen as a different language if you only use the new features, e.g. abandon prototypes in favour of classes.
What is your view as (a) whether JavaScript needs to change at all (i.e. is it up to the task for the forseeable future), and (b) if so, what path it should be steering in the context of Silverlight, JavaFX Script, and Flash/Flex, HTML5 proposals?
Looking at those fixes, I am not seeing anything that worries me, because as long as ECMAScript 3 is around, I will stick to my current practices, and pay no attention to the fixes.
I would say, naievely: embrace the multi-cultural web. If some people like Silverlight, .NET and C#, I respect that. If some people want Java, Java Web Start, JavaFX Script etc, I respect that. If some people want Flash and Action Script, I respect that.
If some people want to risk time developing an ECMAScript 4, I welcome it. If it doesn't have or find a purpose, then that is the risk they may be willing to take.
I suppose the worry is, will it risk weakening the niche which ECMAScript 3 has found for itself, or is that niche already under attack?
If people personally don't want ECMAScript 3 to change, then just ignore ECMAScript 4. ECMAScript 3 will presumably hold sway on the browser for a long time, (a) partly because it will need a consensus for all of IE, Firefox, Opera and Safari to move to something else, and (b) partly because Edition3 is friendly (once someone has read your book!).
The only thing I worry about is that a multi-cultural web shouldn't destroy what enabled it in the first place, democracy and the rule of law in the case of societies, and standards and the rule of HTML/CSS/DOM/ECMAEdition3 in the case of the web!
Of course, new technology is one of the main factors that makes economics unpredictable over the longer term, so something else could emerge.
My position is that ECMAScript 4 should be a completely different language. It is no longer JavaScript. I'm not saying it's innately bad, just that it's misrepresented as being JavaScript, which it's not. Create an entirely new language that has aspects of JavaScript, sure, but call it something different and don't worry about an upgrade path. Let it be another option without confusing people into thinking their old code will work with it.
I can see the argument for a separate name, and in addition the namespace for "Java" is getting a bit crowded.
Inevitably it will be a separate option, as not all browsers will necessarily support it I guess, unless you get yourself ScreamingMonkey and the like.
Presumably there will also be an incentive on Mozilla to convince developers that it is robustly backwards compatible if it is to be the only interpreter of ECMAScript Edition 3 programs in Firefox 4 in the future, otherwise that could be a source of major cross-browser compatibility issues.
Do you think that there should be a separate development path for ECMAScript, and perhaps rename this new language as ECMAApplicationScript to distinguish it?
@Nicholas: Isn't it a little bit naive to think that browsers like Firefox or Opera would implement a new version of the language that would actively break existing web sites?
The most significant changes are listed here:
http://ejohn.org/blog/bug-fixes-in-javascript-2/
and quite nearly all of them are already implemented in IE, Firefox, Opera, and Safari (they're mostly specification tweaks).
Thus, if the largest incompatibility changes are moot - and there is no upgrade path - then there's absolutely no need to worry about naming or name changes.
So, with that out of the way, let's talk technical!
@John - I don't think it's naive at all. Mozilla has, in the past, introduced "bug fixes" that have altered how pages are displayed or behaved. For instance, on my site's menu I used to have each first letter underlined to indicate the access key. When you hovered over it, the entire link would become underlined, connecting to the underline of the first letter. At least, that's how it worked in Firefox 1.0, when 1.5 came out, it was different...and then 2.0 changed it further. I eventually just gave up and got rid of the first-letter underlines.
Bugs are things that cause errors in code, not things that were oversights. Those oversights are what we got used to, so fixing them will actually cause more errors. Most of the fixes you've listed are just subtle enough to cause problems, and I like Firefox as much as the next guy, but unless Internet Explorer fixes these as well, they're just going to make cross-browser scripting that much more complicated.
The *bug* fixes summarized on John's blog are mostly alterations to the spec to follow the real world implementations. For example all implementations iterates over the keys of an object in the order that they were created. The spec (ES3) clearly says that the order is unspecified but to be able to work and interact with real world code the order has to be specified. This is what the ES task force has been doing.
If you don't want classes and namespaces (which allows you to write more secure programs) you do not have to.
Is there some other way that ES should go? Maybe, but we have yet to see any proposal for solving some of the more serious issues with ES3.
@Erik - It just doesn't seem to me that ES4 is solving any real world ES3 problems. A lot of what's included in just sugar to placate people who can't figure out how to write JavaScript in the first place. Even the whitepaper says that people just have a hard time using an OO language where there aren't classes and interfaces. The solution is to have better programmers, not to change the language.
Additionally, not all of the bug fixes already exist and some will cause problems. The automatic "this" propagation is one that jumps out at me as the potential for breaking code.
I am excited about the new specification. I have a massive Web 2.0 product which uses tons of Javascript and so am extremely familiar with the limitations of Javascript.
Specifically, I am keen to see fixed point math. I do lots of financial calculations and this is really something that is a must.
I am keen to see some of the improvements in relation to working with Ajax and async operation.
As far as compatibility goes, I think this needs to be resolved with an Acid style battery of tests to be performed on all web browsers. Looking over all the differences that have been documented so far, my code is clean and I see no problems at all running ECMCA 4 engine.
I am somewhat disappointed with all the generalities people are talking about when they complain about the proposed standard.
Scott.
@Scott - I agree that true floating-point math will be useful, though this could have been added without an entirely new language.
As for improvements related to Ajax and async operations, I don't see that anywhere. ECMAScript has no concept of Ajax, that's purely a web pattern.
And the fact that you can't anticipate problems upgrading to an ES4 engine doesn't mean that the problems won't exist. Plus, there are numerous specific complaints both in this post and in the comments. Not sure where you're looking for generalities...
Post Comment
Your e-mail address will never be shown, only your URL. Please, no HTML in your comments, as it will be automatically stripped out for security purposes.