ECMAScript 4.0 Is Dead 168
TopSpin writes "Brendan Eich, creator of the JavaScript programming language, has announced that ECMA Technical Committee 39 has abandoned the proposed ECMAScript 4.0 language specification in favor of a more limited specification dubbed 'Harmony,' or ECMAScript 3.1. A split has existed among the members of this committee, including Adobe and Microsoft, regarding the future of what most of us know as JavaScript. Adobe had been promulgating their ActionScript 3 language as the next ECMAScript 4.0 proposal. As some point out, the split that has prevented this may be the result of Microsoft's interests. What does the future hold for Mozilla's Tamarin Project, based on Adobe's open source ActionScript virtual machine?"
ES4 not dead (Score:5, Informative)
It's not dead. There will eventually be a Fourth Edition of ECMAScript, it just isn't the focus now. The ES4 proposal wasn't ever enshrined as the actual Fourth Edition either.
I was really skeptical about the concessions made by the ES4 side before I listened to some of their rationale; it wasn't so much concessions to the 3.1 side, it was that the things they were dropping didn't adequately solve the problems they were put in to solve.
There's a great talk about it here: http://openwebpodcast.com/episode-2-brendan-eich-and-arun-ranganathan-on-ecmascript-harmony [openwebpodcast.com]
Re:Harmony is a good name.... (Score:5, Informative)
"What is needed in the JavaScript world is not more features, but more consistency of implementation across the various browsers."
With the exception of a few later-added methods (on Array for example), that's already there. The inconsistency is in the DOM, and that's not something ECMA covers.
Crockford and Standards (Score:5, Informative)
I invite everyone to read Douglas Crockford's latest post on the YUI blog entitled: The Only Thing We Have To Fear Is Premature Standardization [yuiblog.com]
He gives some insight into how ES4 got to where it is today and its impact on standards in general
Re:Establishing de facto (open source) standard ? (Score:3, Informative)
http://www.sproutcore.com/ [sproutcore.com]
Re:What a damn shame (Score:2, Informative)
With a good build/deployment script you can combine all of your CSS and JS files together, giving the advantage of better compression and less HTTP requests. If you have it set up in that way, you can split your script into as many files as you want.
Images are a bit different, you can't do much outside of spriting where you can.
This is not to say a JAR equivalent wouldn't be preferred, just that there are things you can do today.
Re:What a damn shame (Score:1, Informative)
>modern web application typically has to download a ton of CSS/JS/image files
This is trivial to fix for JS/CSS, either via runtime tool or build system. It takes about 10 minutes to add a servlet to combine and compress JS/CSS files in Java via the JAWR library, for example.
Re:What a damn shame (Score:1, Informative)
Um, that's exactly what "sugar" means: a more readable syntax that hides the implementation details.
Harmony will have classes -- they will merely be implemented as syntactic sugar on top of lambdas and prototypes, instead of being new constructs altogether. This change is irrelevant from the point of view of anyone other than a language implementor.
Re:A real pity (Score:3, Informative)
JS was never "lightweight" in any sense of the word - neither in terms of language features, nor it terms of performance of typical implementations. If you want a truly lightweight scripting language, designed as such, see Lua.
Classes are not out of the question. (Score:3, Informative)
Classes are syntatic sugar. That's what the working group found, when it discovered that most class-centric features can be boiled down to simpler APIs such as .freeze(), .defineProperty(), &c., all of which are being implemented in ES3.1. Classes, then, would only be user interface to what can already be implemented using these features.
ES-Harmony is about standardizing new features that already work in (three out of four) major browsers, without changing the syntax of the language. Brendan Eich of Mozilla in the Open Web Podcast [openwebpodcast.com] already discussed how script versioning will allows coders to use different language versions in the future. So syntax changes are not out of the question, they're simply being postponed until after ES3.1.
Until then, users will still have all the power of classes in their code, just without the ease-of-use of a "class" keyword (which will be a lot easier to implement after ES3.1 is proven and tested).
Re:Crockford and Standards (Score:3, Informative)
That line was about HTML5, which is absolutely ridiculous. The things that the WHATWG and W3C have added to the HTML5 proposal are one or both of the following:
- formalized semantics already informally in use as classes and ids (like the section and nav tags);
- behaviors already in use, drastically simplified (like Web Forms 2.0).
They didn't really "just make new stuff up", they're making the language and environment much more powerful, with real world use in mind. Both types of feature additions make developers' lives easier, behaviors more predictable, and creative and expected uses of HTML beyond simply parsing and displaying more possible. The HTML5 effort is downright fascinating in the amount of good in it.
Re:What a damn shame (Score:3, Informative)
Seriously, RTFA.
This thread's title is totally misleading. In fact, the summary is wrong. ES Harmony is NOT ES3.1. And of course, there's the anti-MS slant as usual, but no mention of Yahoo, which was also against ES4. Good ol' /.
So just in case you're too lazy to read the article, here's a quick summary:
ES Harmony is just an ES4 that the ES 3.1 guys agreed to work on after ES3.1 is out the door, while the ES4 guys agreed to work together with the ES3.1 guys on ES3.1. So ES Harmony (which could be ES4 or ES5, depending on what they call ES3.1) will still have classes. They will still have integrity. However, there won't be any early binding, since they now just "desugar to lambda-coding + Object.freeze and friends from ES3.1."
Also, your complaints about web development packaging is out of the scope of ES. It's a browser/HTML issue. Every scripting and styling language on the web suffers the same problem.
Re:Establishing de facto (open source) standard ? (Score:3, Informative)
> My opinion: I need a modern virtual machine ==> Java ... check
> with capabilities comparable with Flash/Silverlight applets ==> Java ... check
> and level of integration comparable with javascript engines shipped with browsers. ==> Java ... check
> Compatible across browsers. ==> Java ... check
> maybe with some kind of intermediate representation (bytecode?). ==> Java ... check
> Capable to run bigger, non-trivial apps. ==> Java ... check
> Open sourced and not patent encumbered. ==> Java ... check
> Currently there is nothing satisfying my wishes.
Errrr uhmmm, ever heard of Java?