Monday, April 13th, 2009

EcmaScript Edition 5, formerly known as 3.1: Getting a new JavaScript

Category: JavaScript

>You probably remember the history. JavaScript 2, the reckoning, was going to come from EcmaScript Edition 4. That never happened, and instead the 3.1 group moved on with their agenda for “baby step” changes to the language.

Now we have a final release of that work, with a new name, EcmaScript Edition 5 which is an interesting change :)

Erik Arvidsson tells us his thoughts:

The most exciting thing in ES5 is that it finally standardize getters and setters. It also allows us to control the enumerability as well as whether properties should be read only etc. ES5 also adds a few other things like the array extras from Mozilla.

Yes indeed. We now have things like Function.bind. Well, by “now” we mean “when browsers support this.”

Many of the browsers have moved ahead with JavaScript, but IE has held back. Fortunately, that is hopefully in the past since Microsoft was a key player in this spec and has posted on the news itself on the JScript blog:

For the average web developer the release of a candidate specification has little immediate impact because you have to create content that works with the browser versions that are actually in use today. However, we expect that once it is finally approved, the revised ECMAScript standard to be widely and fairly rapidly adopted by browsers. In the meantime, this new specification is already having an impact. For example, in IE8 both the native JSON and the DOM Prototypes features are based upon APIs defined in the ECMAScript Fifth Edition Specification.

An interesting glimpse into the Microsoft developer world can also be found by checking out the comments to that entry:

I think it makes immense sense to hold off a final release of Managed JScript until the fifth spec is finalized, but the complete lack of transparency in the Managed JScript process has been a little disconcerting. When Managed JScript was announced it was promising, but IronPython and IronRuby have completely eclipsed it. Whether in the DLR for Silverlight or ASP.Net futures, Managed JSCript has been intentionally hidden, which is a shame.

As Web developers, if we actually see implementations of this on the shelves ACROSS browsers soon, that will be fantastic. I hope the new VM teams move fast to make this happen. Having some of the core changes available will be great for us. It is bloody frustrating to be able to use really great features in a Firefox add-on, or a server-side JavaScript application and then have to go back to the real world on a “normal” app.

On the other hand, this is hardly enough change. Getting a couple of the useful Prototype methods like bind, and some nice Array helpers and the like…. good to get us all on the same page, but come on guys, it’s time to step it up a notch! Harmony here we come :)

Related Content:

Posted by Dion Almaer at 8:01 am
16 Comments

++++-
4 rating from 25 votes

16 Comments »

Comments feed TrackBack URI

I love it when new specs come out! Maybe there should be a spec governing roving updates to browsers? That would be LOVELY!

Comment by oopstudios — April 13, 2009

Well I’ll be. That’s my comment from the JScript Blog. Goes to show you that you let you voice be heard and someone will listen.

Comment by pnewhook — April 13, 2009

There’s quite a few major and much-needed changes here, so I find it a shame you’ve barely scratched the surface and instead focused on the negative and said to “step it up a notch” than cover the multiple improvements and changes in the spec that are a huge step in the right direction. I guess people prefer to moan.

Anyway, let me do what you didn’t do and actually cover the major changes: new internal object properties and ways of accessing them (via Object.defineProperty, Object.defineProperties, Object.getOwnPropertyNames); being able to set properties for getters/setters (i.e. call functions when you get/set objects); properties to be able to set how objects can be changed and functions to access and check them(frozen, seal and preventExtensions); being able to set whether an object is enumerable (i.e. whether or not it appears in for… in loop); addition of array prototypes map, reduce, reduceRight, filter, some, and forEach; a real Object.create function instead of having to do it by hand (finally!); and native JSON.

Comment by Halo — April 13, 2009

An extensive coverage of the new features in EcmaScript 5 is what I’d like (and expect) from Ajaxian. Not just this (pretty useless) piece of news.

Comment by andysky — April 13, 2009

@Halo: Thank you for the detailed news on EcmaScript 5. :)

Comment by andysky — April 13, 2009

@Halo: thanks for a more complete view of what’s to come in ECMAScript. There are definitely some useful features there. But I have to call BS on the hype about getters and setters. They’re just syntactic sugar, and don’t really provide any benefit, and provide a lot of potential downsides for anyone who works with other people’s code.

Of course, the first thing I thought of when I heard about getters and setters was, “gee, I could do all kinds of background work upon setting a value, it would really simplify my non-library code!”

But then it occurred to me that working against other people’s libraries could be a real mess. You get or set a value, and who knows what’s happening in the background. You end up having to do a lot of digging into the library, at which point, you really might as well be maintaining your own library, right?

Comment by eyelidlessness — April 13, 2009

Why do we need to change what is obviously working pretty well?

Comment by berend — April 13, 2009

@berend, I think you’ll see from Halo’s comment that there are actually many features in ES5 (9_9, I am tempted to keep calling it ES3.1 out of spite at the stupid name change) that can’t be accomplished with syntactic sugar in ES3. Several of those are features many of us have wanted for quite some time. If you don’t want them, don’t use them.

Comment by eyelidlessness — April 13, 2009

@eyelidlessness:

They’re just syntactic sugar, and don’t really provide any benefit

Having to write less code is quite a benefit IMO. If I have a property on an object that updated the textual content, it would make much more sense to define it as .text and not .text(str).
.

You end up having to do a lot of digging into the library, at which point, you really might as well be maintaining your own library, right?

The same argument could be applied to any function you call on a 3rd party library. Not every library you come across is going to follow the Law of Demeter, but that’s the name of the game on any large code base

Comment by TNO — April 13, 2009

Having to write less code is quite a benefit IMO. If I have a property on an object that updated the textual content, it would make much more sense to define it as .text and not .text(str).

I don’t understand. It’s a difference of one character. .text=str vs .text(str). The latter is substantially more clear, and comes at the cost of a single character.

The same argument could be applied to any function you call on a 3rd party library.

Not true. A method call does not obscure itself as a property assignment. You may still have to dig into the internals to find out why something went wrong, or simply why something happened, but you are not going to be mislead around the source of the method call that is syntactically a property assignment.

Comment by eyelidlessness — April 13, 2009

Getters/setters are useful as it provides a key piece in the puzzle of working around features browsers don’t implement or implement incorrectly.

As a convoluted example, let’s say you want the MS-only outerHTML attribute in FireFox. It works exactly the same as InnerHTML, but includes the container tags as well. Before, there was nothing you could do to implement this so it worked the same as in IE, now you can.

Or what about CSS3 style attributes. Let’s say you want to access a CSS feature, but the browser doesn’t support it. You can simulate it, so in JavaScript it works exactly the same as if it was native, and then when it’s implemented natively in all supported browsers simply drop your old code. This allows you to use future features today.

From that point of view, I think it’s a huge step forward.

Comment by Halo — April 13, 2009

Halo, outerHTML is in the DOM right? I don’t think with this you can override DOM objects, could you?

Comment by berend — April 13, 2009

berend, getters/setters are useful for many reasons. outerHTML is an example, the target in IE Event.prototype is another one, etc etc.
About size, text(str) against text=str is one char, .text against .text() to retrieve the value are two chars. If a browser would like to implement something native in another one you have to choose another name for the callback which will simply emulate a getter/setter behavior. So, rather than add a check like if(arguments.length) for each callback with a set/get behavior, plus a different name to avoid conflicts with the native method, you can simply implement a background callback capable to make code clear and more natural to both write and read. Moreover, thanks to getters/setters, IE8 could implement standard DOM behaviors and vice-versa, other browsers could implement IE behavior to make code faster for IE and fast enough for every other (something I am working on but something that will require time) ;-)

Comment by WebReflection — April 14, 2009

halo: andysky: Detailed post on the updates in ECMAScript 5:
http://markcaudill.com/index.php/2009/04/javascript-new-features-ecma5/

Discuss on HN:
http://news.ycombinator.com/item?id=562045

Comment by mcaudill — April 14, 2009

@mcaudill: now that IS handy! thank you. :)

Comment by andysky — April 17, 2009

@mcaudill:
Ah, I see now that YOU are the author of the article!

1000 Thanks! :)

Now what can we do to make your article show up in Ajaxian’s RSS feed / be mentioned in an Ajaxian article?

Maybe you can tweet to:
http://twitter.com/dalmaer
:)

Comment by andysky — April 17, 2009

Leave a comment

You must be logged in to post a comment.