ECMAScript 4 Papers

Posted: November 8th, 2007

20 Comments (Show Comments)

1. Justin Meyer (November 8, 2007 at 2:26 am)

   I was nervous about ES4 at first, but white papers like these slowly make it more acceptable (and almost exciting).

   I’d still like to see an example of something that I couldn’t do before ES4. I don’t mean using yield. I mean something like XHR which opened doors that didn’t exist before. Something that makes it possible to build an application that was impossible in ES3.

2. Ryan (November 8, 2007 at 2:37 am)

   I’d really like to get your opinion on the changes. There’s a lot of talk about ES4 at Yahoo!, with many against it and many for it.

   I’ve just begun to truly understand the parts of Javascript that make it unique (prototypical inheritance, closures, etc) and now ES4 seems like it completely ignores all this and tries to make it like Java and C#. Is my opinion correct? Is it a good thing this is happening?

3. Blair Mitchelmore (November 8, 2007 at 3:47 am)

   I really don’t understand why so many people are bashing ES4. I’ve been following its progress from a distance for a year or so now, and lurking on the mailing list for a couple months now and I’m damned excited. (Add to that that the reference implementation has finally been released in a cygwin-free form for windows and I can finally play with the new language without busting out my linux laptop.)

   Every new feature of ES4 seems incredibly well thought out to me with a focus on improving readability, reuse, and large team development of code. It should also be noted (again for the umpteenth time) that all the new features do not remove the old style of ecmascript code. You can still use glorious closures and prototypal inference. It’s just that there are instances where a more traditional object-oriented approach results in more manageable code. Also, there are many many existing implementations of traditional OOP already, so it makes sense to canonize it in language and allow for compiler optimizations.

4. John Resig (November 8, 2007 at 4:31 am)

   @Justin: I definitely get your point – it’s something that I’m trying to grasp, as well. There’s a ton of features that are “this was really hard/annoying/slow before and now it’s easy/fast” but that’s not a “new door,” so to speak. Right now, I’d have to say “compile-time checking of variables using type annotations” – this was, absolutely, not possible in ECMAScript 3, but now you can verify that the input that you’re passing in is, in fact, right long before you ever run your code (thus, it can be verified in your favorite IDE).

   I’d have to vouch for program units, as well. Previously, there was no way to gracefully (synchronously) load JavaScript code across domains. When using program units it is now possible to do just that – and in a syntax that is trivial. This opens huge doors for library development.

   I’d also have to shoot for namespacing. This is a linchpin of ECMAScript 4 and allows it to do much of what it does, right now. Previously, if you loaded multiple JavaScript libraries they’d just blow away each others variables, with reckless abandon – that is no longer the case. You can now call specific functions within specifically-loaded packages (e.g. jQuery::query(...)). This completely overhauls how things where done previously, finally allowing for a safe way to use JavaScript libraries.

   Those are just a couple that I could think of off the top of my head, but I’m a little bit tired – let me know if you need more!

   @Ryan: The more I learn about it, play with it, and use it – the more I like it. Personally, I feel that choosing to have Prototypal inheritance be the default manner of inheritance in the language, for so long, was a mistake. I know that there was initial effort to correct this around 2002-2003 (and, thus, you can see the results in ActionScript 3 and JScript 8) so I think it’s about time that JavaScript caught up.

   Closures are definitely not any less useful – in fact, I’d argue that they’re now much more relevant (and intuitive – especially when dealing with classes). For example, look at the following class code:
   class Ryan {
  var name = "Ryan";
  var last = "Doherty";
  function job(){
    return name + " " + last + " works at Yahoo!";
  }
}
   Note that I no longer have to say “this.name” or “this.last” to access the instance properties of the object – this is fantastic and incredibly intuitive – and long overdue.

5. Andrea Giammarchi (November 8, 2007 at 4:52 am)

   I think there are basically 2 point of view about ES4:
   – who thinks about never solved problems in 3rd edition (probably they should think about never IE JScript standardizzation / evolution)
   – who thinks about new features, bug fixes, control and speed improvement and a “quite real” write once run everywhere language / enviroment

   These points are both respected in ES4, first because one of its goal is to fix ES3 bugs mantaining backward compatibility, second becasue who need a more powerful language/enviroment should use new features while who don’t want “to break the Web” (that’s just broken) will has old features fixed.

   Flash Player 9 simply runs AS3, AS2 and AS1 without problems, why We should think that Tamarin will not be able to do the same thing parsing 2 versions instead of many more?

   Why We should break the Web if backward compatibility is even fixed and ActionMonkey project will bring these features even inside IE browsers?

   What is the alternative: waiting for Internet Explorer JScript evolution/standardizzation? Waiting for new IE that will never implement standard methods? Stop a normal language evolution that should be used to create even more RIAs as well as “Rich Server Applications”?

   I didn’t approve MacroMedia way to change every year its language and Adobe is changing them one more time (AS4) … anyone is really an AS expert just because in one single year You can’t say you’re a real program language expert.

   In the other hand, JavaScript 3rd edition is about 8 years old (I mean third “standard” Edition) with problems that We all know and now it would be evolved into a really cool language that will allows us to write both old or new scripts in a way that should be used for a “Web revolution” instead of “Web crash”.

   The problem is security? Well, ES4 will fix some security problem.
   The problem is portability? Well, ES4 will be available for every browser using a small integrated (or downloadable) plugin that should be used only if browser supports/has them.

   It seems that if tomorrow ES4 will be available We will ignore users while I think that if tomorrow ES4 will be available We simply should choose wich language version should be used for compatible browsers.
   I can’t see where is the problem but it’s just my point of view.

   (P.S. sorry for my English, I’m going to study them next week in London :D)

6. filipe_c (November 8, 2007 at 5:04 pm)

   i read somewhere that javascript 4 is in risk since mozila guys and microsoft tech chief does not agree in the spec,,, it´s true ?

7. Peter Michaux (November 8, 2007 at 5:18 pm)

   ES4 cannot be both “compatible with ECMAScript 3” and have “backwards compatibility changes” which is a euphemism for the title of the linked document “Incompatibilites Between ES3 and Proposed ES4.”

8. John Resig (November 8, 2007 at 6:13 pm)

   @filipe_c: I think you mean JavaScript 2 or ECMAScript 4 – but no, there’s no risk. Microsoft is in the minority disagreeing with the current language proposal (for example, Mozilla, Adobe, Opera, and many others are all in support of the current standard).

   @Peter: Correct – there are changes in relation to ECMAScript 3 – no one is saying that there aren’t. However, the changes are compatible with current ES3 implementations (which is an important distinction) because:
   – The majority of changes are already included, universally, in current ES3-compatible implementations.
   – The changes that aren’t in current implementations have no discernible negative effect real-world applications.
   Even changes that may, possibly, have some negative effect have been reverted at this point (such as: typeof null == “null”). They’re being incredibly cautious about which changes should be included – and if one should actually have a real, negative, effect you can bet that it’s inclusion will be closely reconsidered.

9. Peter Michaux (November 8, 2007 at 8:34 pm)

   If there are “Incompatibilites Between ES3 and Proposed ES4” then the two are not compatible. Period. That’s just facts. However the proposal says ES4 is compatible with ES3 and later goes on to say that there are exceptions. You state they are compatible but that there are changes. That seems quite confused. Real compatibility is a boolean property. ES4 is compatible or it isn’t. I think it would be better for the talking point to be something like “ES4 is mostly compatible with ES3.” This emphases that they are close but migrating will take some work and doesn’t have the feeling of “well this is how we want to market it but be sure to read the small print.”

10. John Resig (November 8, 2007 at 8:50 pm)

    @Peter: There is no confusion – there’s incompatibilities between the ECMAScript 3 SPEC and the proposed ECMAScript 4 SPEC – there are virtually no incompatibilities between ECMAScript 3 IMPLEMENTATIONS and the ECMAScript 4 SPEC. That’s the distinction. The specification has moved to adapt to how existing JavaScript engines have been implemented; which is an important step to take for a specification to remain relevant.

    It’s not like this is being obscured either – Brendan has stated this publicly on his blog:

    On the compatibility front, we have a new document on known incompatibilities between ES3 (ECMA-262 Edition 3 the spec, not real-world behavior of ES3 implementations in browsers — note well) and ES4. (cite)

    It’s weird that you’re even having problems with this – it’s not even the most significant part of the specification, by a long stretch. Even Douglas Crockford agrees that these changes are a good idea.

    So, the talking point is: “The proposed ECMAScript 4 specification is completely compatible with real-world ECMAScript 3 use and implementations.”

11. Lindsey (November 9, 2007 at 12:23 am)

    Whats the point of Parameterized types? The examples in the overview are a little… brief, and don’t seem to convey the point of the addition.

12. John Resig (November 9, 2007 at 1:53 am)

    @Lindsey: Two examples for you. Here’s one example for a class that you could’ve written to hold point data:
    class Point.<T> {
 var x: T, y: T; 
}

    var p = new Point.<double>;
    
p.x = 3.0;

    p.y = 5.0;

    var p2 = new Point.<int>;
p2.x = 3;
p2.y = 5;

    The above creates a custom Point class which is able to hold specific number types (such as a double or an int). We can see both examples in use – and you could even pass in another type (like a ‘string’) if that suited you.

    A more realistic example is with the builtin Map and Vector classes. These allow you to have structured means for holding data of specific types, for example:
    var m = new Map.<string, *>;

    The above creates a Map object that has a key of type string and any value (specified by the “Any” type). I hope this helps to clarify it!

13. Patrick Donelan (November 9, 2007 at 2:06 am)

    Do you think ECMA4 will expand the possibilities for people writing Code Assist and Refactoring tools (eg. for IDEs like Eclipse)? That would certainly make Javascript development more fun.

14. John Resig (November 9, 2007 at 2:26 am)

    @Patrick: Absolutely – that’s virtually guaranteed. For code assist, the editor be able to do basic checks to make sure that the right values are being passed in to functions, being assigned to variables, etc. and give you warnings before you ever even hit ‘save’.

    As for refactoring – now that there’s a solid class structure and way doing type checking – that’s a solid possibility. This wouldn’t have been feasible before because you would’ve never been able to tell when a class was used (or when a class that inherits from an other is being used).

    I’m curious to see what the first real ECMAScript 4 IDE will be and what features it will include.

15. Justin Meyer (November 9, 2007 at 5:11 am)

    John, thanks for the answer. I’ve been posting that question across a number of blogs and you are the first to give a cogent response.

16. filipe_c (November 11, 2007 at 12:35 pm)

    sorry, but there news about mozzila and microsoft CTO´s figths…

    look at:
    http://www.computerworlduk.com/technology/development/software/news/index.cfm?RSS&NewsId=5995

    “Mozilla and Microsoft developers are fighting over the future of the JavaScript programming language.”

17. John Resig (November 11, 2007 at 3:45 pm)

    @filipe_c: Right, what I said before still stands: “Microsoft is in the minority disagreeing with the current language proposal (for example, Mozilla, Adobe, Opera, and many others are all in support of the current standard).”

18. Peter Michaux (November 11, 2007 at 4:35 pm)

    John, what is the metric used to determine “minority” status?

    What is the end game? Who votes and when?

19. John Resig (November 11, 2007 at 5:44 pm)

    @Peter: The number of participants in the ECMA TG1. If I remember correctly, Adobe, Mozilla, Opera, and mbedthis are all for the current spec – Yahoo and Microsoft are against it – and a couple companies, like Apple and Google, haven’t stated an opinion yet. (Although, it’s not clear to me if they’ve joined TG1 yet, or if they’re just watching with interest – Brendan could probably clarify this.) So currently it’s a 4-to-2 minority.

    I’m not sure, exactly, when “the vote” occurs – but simply the proposed spec needs to have a majority interest before it gets pushed on for final approval by ECMA, which will be fall/winter 2008.

    If I remember correctly, there’s another TG1 meeting here real soon (it may even be happening right now). So we’ll have to see what the result of the meetup is and if any conclusions are reached (or if any counter-proposals are revealed).

20. filipe_c (November 12, 2007 at 5:35 pm)

    minority status ?? hm
    don´t mess with ms. js without ms consent will be a risk…

    but i hope it goes well and js has a great success.

Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.