Slashdot Mirror

← Back to Stories (view on slashdot.org)

ECMAScript 4.0 Is Dead

Posted by Soulskill on from the long-live-ecmascript dept.

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?"

14 of 168 comments (clear)

  1. I'll wait for... by jfclavette · · Score: 5, Funny

    ECMA Script 3.11 for workgroups.

    The joke works this time !

  2. ES4 not dead by omfgnosis · · 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

    1. Re:ES4 not dead by rycamor · · Score: 4, Insightful

      The only problem is that JavaScript/ECMAScript from a language point of view isn't really good. A strongly statically typed script language would have been better since it would have allowed the developers to catch a lot of bugs that now occasionally blows up in the face of the users.

      That would be the worst possible thing to happen to Javascript. I know, I know... let's not get into a religious war over static/dynamic typing. There are valid points for each in different contexts, but a language in Javascript's problem domain is probably one of the worst contexts for static typing.

      Keeping the language small, clean and simple should be the priorities. If you want Java in the browser, well... that's already available.

  3. Harmony is a good name.... by QuietLagoon · · Score: 4, Insightful
    What is needed in the JavaScript world is not more features, but more consistency of implementation across the various browsers.
    .

    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.

    1. Re:Harmony is a good name.... by Goyuix · · Score: 4, Insightful

      I would disagree (to some degree) that more features are in fact needed. For example, E4X (and a native XML doc object) being standardized in the browsers would be a huge benefit.

      That being said, I think that a lot of the feature bloat going into the proposed v4 was really not all that great. I think this is generally a step in the right direction.

    2. Re:Harmony is a good name.... by omfgnosis · · 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.

    3. Re:Harmony is a good name.... by hedwards · · Score: 4, Insightful

      Quite so, a lack of standardization amongst the implementations has been a serious problem for years. Allowing developers to use the entire spec as is without fear of problems going between browsers would be a huge step forward for JavaScript.

      Perhaps add in a few fixes for annoying parts of the language and similar, but overall if it's just made to be consistent across browsers, that would go a long ways.

    4. Re:Harmony is a good name.... by pembo13 · · Score: 4, Insightful

      I would ask for a safe JSON parser as well as I prefer JSON to XML (which is quickly becoming overused)

      --
      "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
  4. Crockford and Standards by kevin_conaway · · 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

    He gives some insight into how ES4 got to where it is today and its impact on standards in general

  5. Re:Establishing de facto (open source) standard ? by maxume · · Score: 5, Interesting

    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.
  6. Re:Can I just point out by kevin_conaway · · Score: 4, Interesting

    [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.

  7. Re:Establishing de facto (open source) standard ? by boorack · · Score: 5, Interesting
    Maybe. Remembering earlier articles about ES4 and political mess about this, I dunno what to think.

    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 ?

  8. A real pity by shutdown+-p+now · · Score: 4, Insightful
    ES4, as proposed, was destined to become a truly beautiful language, applicable for far more than its present Web scripting role. It was something I was actually looking forward to. And now - they've essentially codified the status of ES as the "Web scripting language", and discarded all the "too hard" stuff from the spec because it didn't fit the role. Which is quite surprising, since, given the popularity of GWT, one would think that ES3 implementations do lack something that people want.

    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.

  9. Re:Can I just point out by fimbulvetr · · Score: 4, Interesting

    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?