Slashdot Mirror
ECMAScript 4.0 Is Dead
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?"
ECMA Script 3.11 for workgroups.
The joke works this time !
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
.
It is good to see the standards committee taking a breather from major new features, and instead focusing upon the alignment of behavior of functionality across the various browsers.
Hopefully, there will be a robust and rigorous compliance test suite as a deliverable of this standards process.
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
He gives some insight into how ES4 got to where it is today and its impact on standards in general
The Microsoft stuff in the summary is just trolling. Mozilla and Google are both on board with abandoning the current work called ES4.
Nerd rage is the funniest rage.
[Can I just point out] That Javascript as a development platform, as it seems to have become, is evil. It's just horrible from an efficiency, performance, security and architectural point of view. It seems to be the future.
You can point that out, but you'd be wrong. JavaScript hasn't recently "become" anything. The last major revision that all browsers supported was in November 2000.
It is a beautiful, expressive and quite powerful language that is just now starting to shine after years of being misunderstood by people like you.
Such a damn shame to let ECMAScript edition 4 go in this way.
The small shame is for Adobe's efforts, who entered the ECMA standards body to contribute, donated the entire engine to Mozilla and plenty of other efforts to get this going. But AS3/Flash will not be affected in a big way from this.
The web community as a whole will be. That's where the big shame is: for all of us, web developers. I see that packages, namespaces, classes and early binding are out, likely forever.
Classes are not "sugar", we do need those paradigms when creating bigger applications, because they are more rigid, more readable, more maintainable, understandable. I love lambdas, prototypes and all that, but that's the lower level, the implementation inside a class, inside a package. Those are not interchangable paradigms.
ES4 and AS3 have managed to add those higher constructs to the language, while maintaining full compatibility with all flexible features of ES3 (the JavaScript currently used in browsers).
The reasoning behind dropping all constructs appears to be the preconceived notion that JavaScript must exist in the form of disparate text files loosely connected to each other, something that doesn't scale to bigger efforts at all (and which makes Flash much more viable for such deployment), hence packages and early binding are out. What a mistake.
Who's to say we won't see JAR-like environment where bigger libraries can be compressed together, and some preprocessing can be done to ease the load on the client CPU/bandwidth? I've been praying we get such deployment option soon as a modern web application typically has to download a ton of CSS/JS/image files to build an average GUI nowadays. Why isn't this the focus of ECMA's efforts, but instead the focus is to maintain the status quo and reject us basics that have proven themselves in time to work well in all environments out there.
If you doubt this would work, look no further than Java/Flash applets distributed over the web in this fashion (and Flash is very widely used nowadays).
What ECMA has achieved with their decision, is to basically stagnate the browser environment, and empower third-party cross-browser plugins to eat more from the advanced web application market share, because Adobe's Flash, Microsoft's Silverlight are not even thinking of dropping their mature OOP features, just because ECMA said we don't need them.
My opinion: I need a modern virtual machine with capabilities comparable with Flash/Silverlight applets and level of integration comparable with javascript engines shipped with browsers. Compatible across browsers. Language independent (I would like to program this in Python) - maybe with some kind of intermediate representation (bytecode?). Capable to run bigger, non-trivial apps. Well designed. Open sourced and not patent encumbered.
Currently there is nothing satisfying my wishes. Pure javascript has somewhat limited capabilities (especially in multimedia area) and isn't fully compatible across browsers. Flash is proprietary and doesn't work well on some platforms and is just an applet (not well integrated with the browser itself). Silverlight is proprietary and does not work well outside windows. Java applets - along with their bad integration with browser itself and huge startup overhead - are IMO examples of bad design. Any ideas ?
Oh well; Microsoft scores one here, considering that Silverlight 2.0 will be scriptable using Python and Ruby out of the box.
By the way, the whole fuss about MS being behind this is pretty stupid and unfounded. MS was actually one to jump on the ES4 bandwagon early, along with Adobe - their early implementation of it was called JScript.NET, first released in 2002 with .NET Framework 1.0, and it does in fact still ship with all versions of .NET, and is an officially supported .NET language. They certainly wouldn't have any trouble extending it to the more recent spec, should it become standard. Now, I guess it will just be quietly dropped in the next version of the framework.
>The Microsoft stuff in the summary is just trolling
That is true because MS actually voted for more security of an individual's IP rights than what ECMAScript 4.0 offered. One problem for example, under ES4, is that containers of code may also contain code that is owned by someone that never gave permission to distribute code. ES3.1 is not a solution, but it achieves that some desired advancements without a greater lack of security in a trade-off.
OOP !== Class based OOP
JS isn't a class based OOP language, it's prototype based OOP language - the two are _very_ different. I can understand why it's a pain in the neck. It's also a pain in the neck to force a square peg into a round hole, but is the blame on the person who made the square peg or on the person whom thinks that the square peg should indeed be able to be put in the round hole?
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 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).