Round-up of ES4 discussions for the past few days:
Like it or not, with JavaScript, JScript, ActionScript and others in play, ECMAScript is fragmenting. There is an opportunity for the players involved to work together to converge. That presumes that the motivation is there for them to do so.
ES4 is intended to be a superset of ES3. Your one liners in onClick attributes will continue to work. The magic that is prototype will continue to work. In addition, there will be classes, packages, and optional type annotation, to name but three of the many new features. To some that may be bloat, but every indication is that compatibility will be maintained and performance overall will not suffer; furthermore there is no requirement that you have to use every feature of the language in every script.
As always, no new specifics emerged from the secretive northwest. Even if ES4 were renamed ES5 to make room for a bridge release, every issue that needs to be addressed in ES4 would also need to be addressed in ES5. Specifics would be helpful here. Again, the question goes back to whether the people involved are motivated to be helpful here or not.
I just got done reading Ars article along the same lines, what a shame.
In the background, all I could think of was M$'s history of doing things there own way, so I went in with a biased attitude, but it seems like Brendan needs to have a sit down in this case.
I may have missed it, but completely missing from this coverage, and “coverage” by Scoble and others is any discussion of specifics.
"When you have the facts on your side, argue the facts. When you have the law on your side, argue the law. When you have neither, holler." - Al Gore.
There is an understand frustration involved when “the other side” consistently skirts any discussion of specifics. It is unfortunate that a lack of specifics doesn’t make good “copy”, so that tends to go underreported.
How exactly does introducing classes or packages or optional typing “break existing code” or create "new interoperability problems"? If those features aren’t the contentious ones, which ones are? I haven’t been involved with the standardization process for ECMAScript for eight years, but specifics would be very helpful here.
How exactly does introducing classes or packages or optional typing “break existing code” or create "new interoperability problems"? If those features aren’t the contentious ones, which ones are? Maybe Sam just has a way with words , or maybe...
Shelley: I did not call Chris a liar, in either that open letter or your blog, because he was not at any TG1 meetings except for two hours of the March one, during which no one shouted down anyone else (well, Scott Isaacs of Microsoft sat a little too close to me, but I like Scott ;-). Now it seems you are distorting what I wrote to make me sound like a child crying “liar, liar!”. Please cut that out!
If what Chris wrote charging me or others in Ecma TC39-TG1 of “ignoring” and “shouting down” people meant anything, it came from someone else, who was in TG1 meetings, and that person seems unable to tell the truth recorded by the meeting notes and the dinner bills. Or someone is just making stuff up — but that’s lying too.
Needless to say, if someone repeats a false claim without knowing it to be true, that’s not lying. It may be a careless mistake, but sometimes you have to repeat a falsehood and get called on it before you know whom to trust. So I don’t think Chris is intentionally telling falsehoods.
As I wrote on your blog, the charges of ignoring and shouting down are serious, and deserve to be treated seriously. If they are true, there’s a problem with the conduct of the majority of TG1, and anyway with the TG1 Convenor (me). But if the charges are false, as I believe the meeting notes and general comity among face-to-face players demonstrate, then there’s a big problem with falsehoods knowingly told to Chris.
I’m going to repeat here what I said in my weblog on this issue:
Brendan, I don’t think you’re an ‘offender’ at all. I also don’t see Chris' expressing his opinion to be ‘serious offenses’.
I think there’s too much emotional context to this discussion and it might be good if all parties step back and take several long, deep breaths. This isn’t manners. It’s common sense.
I am sorry now that I wrote what I did about your use of ‘lie’, as it seems to have really hurt and offended you. I still believe in what I wrote, but the timing was poor on my part. I know better than to write what I did while emotions were still running so high. I apologize to both you and Chris for that. We on the outside have added much fuel to this fire, and it’s time for us to keep our opinions to ourselves and let you both work this out, without input from the gallery.
Good luck with your effort Brendan and Chris, both. Since I’m keenly interesting in the future of JavaScript, as I know both of you are, I hope all of the issues can be resolved.
CSS Rounded Corners Demo 7 Tips on Quoting Freelance Projects “Discover” the client’s budget. Spend time on your proposal. Charge by the hour. Up your estimated cost by 10%-20%. Set and manage expectations. Collect up front. Set a...
I don’t know about that. To many people, Tim’s proposed policies were common sense too. I’ve had a variation of that policy in place for years now.
It seems that “common” sense varies. *shrug*
without input from the gallery.
That’s not how open standards work in my book. When I was first involved with ECMA TC39, Mike Cowlishaw started laying the groundwork for becoming more open. That was in TG1 (ECMAScript). I later moved on to TG2 and TG3 (C# and CLI) where the parties involved were insistent in reversing all that. I am pleased to see that TG1 not only continued the work that Mike started, but greatly expanded upon it.
I hope all of the issues can be resolved.
All I know is that unsubstantiated claims of a lack of attention to backwards compatibility have been raised, and even after all of this “coverage”, no specifics have been brought forth. Without specifics, I have very little hope of there ever being resolution.
Whatever is done, Microsoft will implement some standards, and Mozilla will implement a (possibly different) set of standards. There may be some overlap, there may not. In any case, neither will dictate what is actually installed on either your or my machines.
I meant that the acrimony between Brendan and Chris should be resolved between the two people involved, without a lot of counter shots from those not involved in the exchange.
Being open about the specification and the discussions during the meetings, and open email lists, to me, does not equate to personal squabbles and acrimony being played out in comments across various weblogs. Unless you both know something about facilitating collaborative efforts I know nothing about.
If the new features can be added to existing scripting engines without impacting performance or reliability of existing web pages, and the Microsoft people are stating otherwise, then yes, these statements should be challenged. After all, IE doesn’t have to implement the new features, and other browser developers know best if these changes will, or will not impact, on overall performance. Especially if Opera, Safari/Webkit and other scripting engine builders also agree that it will not impact on how their engine perform.
But what is the truth in this seemingly open standards effort? I’ve seen a lot of links with a lot of conflicting information. I see a proposal (in PDF) for ES4, but I also read (from the link connected to Douglas Crockford) that the group could not agree, did not vote for ES4 as a whole, and agreed to disagree and pursue two different language directions.
I can agree that two different languages won’t work for the mobile world, but at the same time, does the mobile world really need the new constructs being added to ES4? I don’t know, I’m not a mobile browser developer.
What I do see is some fairly reasonable questions being asked and concerns being raised, and not only on the part of Microsoft. The point of their concerns is moot, though, because from what I can see, the decision has been made, ES4 is going forward, and what is what is, despite the disagreements and expressed concerns.
I keep going back to one paragraph in the ES4 overview:
“Though flexible and formally powerful, the abstraction facilities of ES3 are often inadequate in practice for
the development of large software systems. ECMAScript programs are becoming larger and more complex
with the adoption of Ajax programming on the web and the extensive use of ECMAScript as an extension
and scripting language in applications. The development of large programs can benefit substantially from
facilities like static type checking, name hiding, early binding and other optimization hooks, and direct
support for object-oriented programming, all of which are absent from ES3.”
I see two different audiences for one language: the web page builders and the RIA developers. Isn’t it just possible that one language for both really isn’t the best approach? Can we really extend the scripting engine enough so that existing scripting solutions won’t have their performance impacted?
Backwards compatibility just means the older applications work. It doesn’t mean they’ll work in the exact same way to achieve the same result, or that the performance will be the same. I’m not a language designer, but I have to wonder if adding complexity to a language, especially with the deep fundamental changes implied by ES4, doesn’t impact on the overall memory and other resource use, not to mention performance.
Still, if the decision is done, any concern expressed is moot. I hope, though, that we’re not faced with complaints in the future if Microsoft does choose not to go the ES4 route (which people have graciously said it doesn’t need to do), so that MS can then focus on supporting XHTML, SVG, the Canvas element, and CSS2.
Specific concerns: My own just stated. My own stated elsewhere. If that’s not sufficient, sorry.
Citation: None, just the general impression given by you and Brendan as I try to wade through all the links and all the references and all the notations and the citations and all the comments and all the wiki pages and all the email lists and all the weblog posts.
If the specification is still open for comments, consider mine given. If the specification is still open for debate, there you go. If not, there you go, too.
Chris Wilson gave him personal opinion. I gave mine.
The argument for one engine is strong with Adobe, Mozilla, Opera, and I think Apple (they can confirm or deny; not sure Maciej reads this blog). It has been made in the [link] many times, and it’s in the overview document. Here it is:
Two engines per browser, one for ES3 and one for ES4 (especially if it’s incompatible) mean unacceptable code footprint increase, plus the costs of engineering cyclic-leak avoidance. This won’t fly on phones.
Then there’s the developer brainprint, and all the code migration, that would be lost if a new, incompatible successor language was foisted on the web.
These two points are fatal by themselves, for the majority of TG1. We’re chartered with maintaining and improving the ECMAScript standard, not breaking it.
Fortunately, neither a new implementation, nor a whole new and different language to learn, is necessary. ES4 is a superset of ES3.
When Microsoft folks keep asking whether a new, incompatible language might not be better, I have to think they mean C#.
Where does the EC misspelling of ES come from? I’m curious, it happens enough that we clearly have the wrong letters juxtaposed in the ES shorthand for ECMAScript.
Note that all but two of the incompatibilities are formal ones against the de jure ES3 spec, where the spec language is not followed by some or all browsers. Real world web standards trump paper ones.
The two changes that lack precedent still have good arguments on their side. ES3’s inconsistent tolerance of deletable bindings for Object, Array, etc. is just a bug that pleases no one. And the |this| binding exception when calling an inner function is worse: because |this| binds to the global object when the inner function is activated, unintended global variable assignments are likely. This |this| confusion happened recently!
While I was busy moving, the rest of the programming world apparently started feeling as strongly as I do about JavaScript/ECMAScript, and now there’s controversy raging over the proposed new standard. The many interesting links I didn’t have time...