The development of ECMAScript 4 is moving into an important phase: the implementors are making good on their word and are starting to implement the ECMAScript 4 proposals. Many of the features have been well thought out by this point and the implementors are working hard to integrate the necessary changes into their engines.
A couple important pieces are coming along but the most critical of which is the ECMAScript 4 Reference Implementation. They’ve released a second milestone release. You can find a copy of the implementation on the ECMAScript download page.
An important list of features is starting to become available in the reference implementation:
Implemented, may have bugs:
- classes and interfaces
- namespaces
- pragmas
- let, const, let-const
- iterators
- enumerability control
- type expressions / definitions / annotations
- runtime type checks (“standard mode”)
- nullability
- destructuring assignment
- slice syntax
- hashcode
- catchalls
- map & vector
- date & time improvements
- meta objects
- static generics
- string trim
- typeof
- globals
- expression closures
- name objects
- type operators (is / to / cast / wrap)
Implemented and partly working, but still in flux / work to do:
- inheritance checking
- strict mode
- type parameters
- structural types
- numbers & decimal
- getters & setters (structural part is incomplete)
- packages
Now a full feature list is also being worked on by all of the implementors (as I mentioned previously). This list is going to serve as the starting point for many implementors especially when they decide which features to implement.
Adobe has also taken a step and has outlined (note the column with green/red/etc.) where they stand on all of the ECMAScript 4 proposals. They also took the time to outline their position on the proposals that they’re (currently) declining to implement.
This is a really important step in the development of the language. The implementors are staking their ground and are working hard to make sure that a solid language comes out at the end – especially one that is universally implemented. Both Google and Apple have also been participating the ECMAScript 4 mailing list, asking a lot of good questions, as they look towards creating their own ES4 implementations (in Rhino and WebKit, respectively).
Pretty much everyone can agree that a lack of dialog between implementors would surely cause problems – but that does not appear to be the case, here. Because of this openness and solid dialog ECMAScript 4 looks to have a strong future.
TNO (February 27, 2008 at 3:38 am)
Excellent news,
Its just too bad that quite a few developers are still against the evolution of the language:
http://ajaxian.com/archives/ecmascript-4-milestone-2-released
zimbatm (February 27, 2008 at 5:40 am)
ES4 is too complicated. They’d better just add type inference, maybe namespaces, and clarify the language, just like the WHATWG did for HTML5. Are the features motivated by a real need at least ? Give me my prototyped objects back at least ! :)
Dig (February 27, 2008 at 9:41 am)
I’m happy to see work still going. Is Adobe really against operator overloading? Thats one of the few features of ES4 that really had me excited. What’s the beef there?
John Resig (February 27, 2008 at 10:47 am)
@TNO: *shrug* Not sure what to say. You, I, and many others are quite interested in the evolution of the language. I definitely see many of the features that are proposed as being excellent salves to the many problems and frustrations of JavaScript developers. It’s almost comical how some people don’t understand the need for that.
@zimbatm: I wouldn’t call HTML5 a good example of a “simple” upgrade to HTML4. I mean you have a full implementation of SQLite, video and audio tags, and a full dynamic scheme for manipulating forms. And that’s just scratching the surface.
Absolutely all the features of the language are being backed by a real need. You’ll note in the feature spreadsheet that justification is being provided for everything that’s being implemented. An implementor of these proposals certainly wouldn’t implement something that they don’t feel strongly about (like in the case of Adobe and their position paper).
@Dig: That’s what it sounds like. You’ll have to read their position paper to get a good feel for their stance.
Leo Petr (February 27, 2008 at 11:07 am)
zimbatm: Prototyped objects are still the core of the language. They never left. The new extensions are almost entirely backwards compatible.
Tom (February 27, 2008 at 11:45 am)
One thing Adobe has right for sure is that the spec and implementations need done fast. ES4 can too easily look like the next Perl 6.
Kevin Dangoor (February 27, 2008 at 12:56 pm)
Thanks for the summary!
I noticed in Adobe’s position statement that they’re not inclined to do certain features because they’re not things that “ES programmers do”. I think ES4, with the right features, can expand beyond the browser in a big way.
As a Python programmer, the case for operator overloading and the decimal type are pretty clear. In Python, I see operator overloading used a lot for custom collections (overloading []), and occasionally for things like decimal (overloading +, etc.). Decimal itself can be important when working with things like databases or really anywhere that you’re dealing with money and want to handle the numbers precisely.
Anyhow, I’m watching the development of ES4 closely, and your summaries are helpful.
TNO (February 27, 2008 at 5:14 pm)
Sorry if this is a bit off topic, but was an integer division operator ever proposed? http://www.codingforums.com/showthread.php?t=58799
I’ve glanced through the documentations thus far and didn’t notice it.
zimbatm (February 28, 2008 at 5:50 am)
@John Resig: You’re right, HTML5 is not really a good example for simplicity. Actually I just wanted to refer to the higher precision put in that document compared to HTML4, with the goal of avoiding ambiguities.
Regarding feature justification, are you referring to the “Base documents, tickets, minutes” column ?
Jacques Surveyer (March 3, 2008 at 2:15 am)
Just a quick note on ECMAScript 4 from the Adobe ActionScript 2 to 3 world – the transition is not easy: new OO syntax, strict typing, and event handling obsoletes a lot of ActionScript 2 code and apps – so Adobe supports both AS3 and AS2 and earlier code in Flash player. But AS3 code runs faster.
It appears the trade-off for JS 1.x to 2.0 (or ECMAScript 4) is better OO and Event handling and therefore large scale programming in JS as is happening in AJAX and Web 2.0 apps versus approachability and ease of use of JS 1.x.
So I have propsed here (see http://www.theOpenSourcery.com under WhatsNew or JavaScript tabs) that developer consider forking JavaScript into JSEasy or whatever that retains JavaScripts ease of use/fast short scripting capabilities – and allows JavaScript 2.0/ECMAScript 4 to carry the heavier AJAX and Web 2.0 programming load.
Robby (March 9, 2008 at 6:20 am)
Forking?! Um, seriously. It’s all about who implements what, this is implementation specific, not what community wants.
That being said, “JSEasy or whatever that retains JavaScripts ease of use/fast short scripting capabilities” is very much at the core of all of the new implementation.
I *really* don’t see how hard this is to get. You want the js of now, write it. You don’t, write in the new implementation. Will you gain speed in the new vs old, of course, you’re throwing hints to the interpreter all over the place.
Here’s what people need to get at some point, or whither behind while the rest of us do. Javascript was indeed born as a browser based interpreted language for manipulating websites. That’s where its history lays. Obviously.
This update puts ES4/Javascript 2.0 in a class of it’s own. Really. While it’s been true of Spidermonkey being able to be used outside of the browser context, javascript has still been regulated to the web. (this includes AS)
Now we can have an implementation that can not only do the quick scriptables that we’re used to, but one that under pragma strict opens up a lot more doors. I would be quite suprised if someone doesn’t take the pragma strict def. at some point and wrap it around llvm or gcc and create a compiler that gives us the power of true compilation using javascript.
You want to use it to do some quick and dirty validation on a webform, or some slide show script. Fine. From everything I’ve seen and have read, nothing changes. Me? I’m looking forward to the day when I can have a language that has the quickness of a scripted interpreted language, the possibility of a compiled language, and with a flick of a switch (pragma) I can have both, in one toolkit.
Javascript may be considered the swiss army knife for the web, but I have a feeling that it just may become the swiss army knife outside of it here shortly.
pens (March 14, 2008 at 2:54 am)
Maybe too complicated. Why not use a subset of ruby as web script language?
David (March 17, 2008 at 7:12 pm)
@pens: Not to bash Ruby, but from what I’ve heard, Ruby’s runtime implementation is pretty bad. (might be getting better, don’t know) Also, I doubt any browser maker would be foolish enough to try to implement a Ruby engine. The web is bad enough with the 20+ differing implementations of Javascript. Imagine the confusion of having a bunch of different Ruby engines on top of that…
But I think you’ve missed the point. ES4 will not be used much at all on the web in the foreseeable future. Places where ES4 will greatly benefit developers in the short term is with desktop applications. ES4 won’t even be available as a web-scripting language for at least a year from now (if that soon) and even then no one would dare use it until it has a high market penetration. So you don’t have to worry about web scripting being any more complex (not that the additions will make it more complex) for oh.. maybe 5 years from now.