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

37 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 !

    1. Re:I'll wait for... by mangu · · Score: 2, Funny

      ECMA Script 3.11 for workgroups.
      The joke works this time !

      Dude, that joke is so 1993!

      The current version is going from 4.0 to 3.5.9

    2. Re:I'll wait for... by pragma_x · · Score: 2, Funny

      Slashdot: News for Trolls. Memes that Matter.

  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. Re:Let's pull a Microsoft by omfgnosis · · Score: 2, Insightful

    Why? There's consensus on Harmony.

  5. I'm skeptical by joe+155 · · Score: 2, Funny

    Brendan Eich may claim it to be dead, but I'd really rather wait for Netcraft to confirm it before actually basing any decisions on this news...

    --
    *''I can't believe it's not a hyperlink.''
  6. 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

    1. Re:Crockford and Standards by omfgnosis · · 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.

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

  9. What a damn shame by Stan+Vassilev · · Score: 3, Insightful

    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.

    1. Re:What a damn shame by DCstewieG · · 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.

    2. Re:What a damn shame by Maian · · 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.

  10. 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 ?

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

    No, no ideas, but ES4 was only going to give you about 1/10 of what you want anyway, so you don't lose all that much here.

    --
    Nerd rage is the funniest rage.
  12. 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.

    1. Re:A real pity by shutdown+-p+now · · Score: 2, Informative

      Barf. What we need is a trim lightweight browser scripting language. You want to write an desktop app, write a bleeding desktop app; don't bloat up javascript.

      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.

  13. it's the libraries and frameworks by speedtux · · Score: 2, Insightful

    Any ideas ?

    The problem with Java and the CLR in browsers are mostly with the libraries, not the virtual machines. So, I think the thing to do would be to start with, say, the CLR and develop an open applet environment and browser integration based on it. This environment could even be emulated in Silverlight, allowing things to run without any install on Windows.

    1. Re:it's the libraries and frameworks by Tim+C · · Score: 2, Interesting

      This environment could even be emulated in Silverlight, allowing things to run without any install on Windows.

      Doesn't the CLR (as part of the .Net Framework) ship with Windows as of Vista?

  14. Re:Establishing de facto (open source) standard ? by aliquis · · Score: 2, Informative
  15. Re:Establishing de facto (open source) standard ? by Dzonatas · · Score: 3, Insightful

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

  16. 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?

  17. Re:Why is JavaScript is so popular? Lamda Function by Z00L00K · · Score: 2, Interesting

    JavaScript is popular only because it exists in almost every browser since a long time ago. This means that if you code something for a browser in JavaScript you know that it has a reasonable chance to work for the most commonly used browsers.

    The use of JavaScript outside the environment of browsers is very limited, and exists only in specialized applications where it may be useful to have a script language. But then it competes with other script languages like TCL/Tk.

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  18. Re:Establishing de facto (open source) standard ? by andy9701 · · Score: 2, Interesting

    I haven't looked into SproutCore much, but isn't it just a framework built around JavaScript? If that's the case, how does that solve the multimedia part of the GP's request?

  19. Re:Why is JavaScript is so popular? Lamda Function by rycamor · · Score: 2, Insightful

    In my case, I really didn't START to like Javascript until I began to read up on it's functional capabilities.

    I think there is more to Javascript's popularity than what you say. It is actually a fairly nice little language, and hopefully when a few annoyances are cleaned up in version 2.0 it will be used outside the browser more and more. In fact, anyone who has done some serious Mozilla application programming with XUL realizes that there is no reason Javascript must be restrained to a web browser context to be useful.

  20. Re:Establishing de facto (open source) standard ? by try_anything · · Score: 2, Insightful

    I think their primary roles would have been for basic libraries, for generated code such as SOAP bindings, and other code that ordinary web-developers would not write. They would work quite well for that and allow better robustness and possibly better performance (less dynamism -> more JIT compiler optimizations) for core functionality like parsing XML and drawing graphics.

    The only way I can imagine that those features are "unsound for the Web" is that ordinary web developers would not bother to understand and use them.

    Unfortunately, many of the people who write Javascript these days stubbornly identify themselves as non-programmers. They resist learning anything that smacks of a "real" programming language. There could have been an ugly struggle between people trying to force these features on web developers and web developers clinging to Javascript's current free-form dynamism. On the face of it, it might seem that web developers are just lazy to avoid learning a few new language features. It also sounds quite silly for them to say, "I'm a programming idiot; I can't write code," despite slinging around complicated DHTML, CSS, and Javascript. They're obviously intellectually capable of learning and using a "real" programming language for "real" programming.

    I think their basic point is sound, though. The job of writing the Javascript for web pages often falls to the web designers, and they should be allowed to program in a simple and dynamic language that suits their artistic temperaments and lets them focus their minds on their creative specialties. They do have artistic design responsibilities that programmers do not, after all, so it doesn't make sense for them to invest as much time in learning about programming as programmers do.

  21. Re:Establishing de facto (open source) standard ? by Lerc · · Score: 2, Interesting

    I have an idea. I'm working on it.

    My initial idea I laid out here

    Since writing that I became aware of quite a few things also exploring this area. I'm currently putting together a proof-of-concept plugin using vx32.

    It should be possible to make something speedily executable on non-x86 with just a few restrictions and a bit of instruction-metadata.

    Importantly. The spec is much simpler than any existing VM model so an open spec with multiple implementation methods should be quite feasible.

    --
    -- That which does not kill us has made its last mistake.
  22. Re:Why is JavaScript is so popular? Lamda Function by Anonymous Coward · · Score: 2, Interesting

    I think I get what you're saying but the difference between function having closures and functions being objects, but I just intended to point out that unlike JavaScript, Java, C, and C++ don't allow first class functions (which I refer to as lambda functions) though they do allow first class objects and function pointers though

    First class functions and Lambda functions in Lamda calculus are the same thing. I also used the calculation of a derivative using a lambda function as an example which is something from mathematical calculus which may have added to the confusion.

  23. Classes are not out of the question. by Tiles · · 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 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).

  24. Re:Why is JavaScript is so popular? Lamda Function by LowlyWorm · · Score: 2, Insightful

    I agree but its not just its functional capabilities. It has a really nice (if limited) syntax. True, it is in many ways just a knockoff of C or C++ but that, to me, is part of its appeal. It is far less cumbersome than either and that makes it fun.

    --
    Time flies like an arrow. Fruit flies like a banana.
  25. Re:Establishing de facto (open source) standard ? by knorthern+knight · · Score: 2, 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?

    --

    I'm not repeating myself
    I'm an X window user; I'm an ex-Windows user