Wednesday, May 20th, 2009

EcmaScript 5: Changes to JavaScript

Category: JavaScript

Three Googlers, Mark Miller, Waldemar Horwat, and Mike Samuel gave the talk above to discuss how JavaScript is changing, and gets into detail on EcmaScript 5.

The slides that go along with the talk are available in good ole simple HTML prezo form and show that the talk discusses topics such as:

  • Accessor support:

    1. var domoid = {
    2.   foo: 'bar',
    3.   get innerHTML() { return ...; },
    4.   set innerHTML(newHTML) { ... }
    5. };
  • Property attribute control:

    1. Object.create(p, {...}).defineProperty(o, n, attrs)...
  • Strict mode: (I laugh at ‘use strict’; everytime. I can’t help it.)
  • Tamper proof objects (.freeze(o) and the like!)
  • Keyword collision: foo.class would be OK now (DOM not changed of course)
  • Higher order array methods: forEach(), map(), every(), some(), filter(), reduce(), reduceRight()
  • JSON now native
  • Function.prototype.bind. Hurrah!

Posted by Dion Almaer at 8:14 am

4.2 rating from 37 votes


Comments feed TrackBack URI

In my view, a quick overview of ES5 is that it makes the most important step of focusing on fixing some of the more serious oversights of the previous editions and getting all the major players on the same wavelength for future standardization. From this point, ES5+ should show us some even cooler things, possibly including: Type systems, lambdas, classes, modules, etc.
Something else that wasn’t mentioned above is that the arguments object now has array methods, so you can do this:

Comment by TNO — May 20, 2009

var domoid = {
foo: ‘bar’,
get innerHTML() { return …; },
set innerHTML(newHTML) { … }

Would seem a bit more consistent as:

var domoid = {
foo: ‘bar’,
get innerHTML:function() { return …; },
set innerHTML:function(newHTML) { … }

Comment by jwlrs — May 20, 2009


Lambda, classes, and modules are indeed all on the table for post-ES5. So is a type declaration syntax expressing some form of type-like constraint. However, due to all the simultaneous constraints, this is likely to be much weaker than a conventional, say Java-like, type system.

Good point about arguments inheriting array methods! It would have fit well into my talk. It just didn’t occur to me.

Hi jwlrs,

You may be right about what would have been a more consistent syntax. However, the syntax shown works today on FF, Safari, Opera,
and Chrome, and so is the proper precedent to codify.

Comment by erights — May 20, 2009

I would like to have scoping rules fixed. I don’t get them as they are now; why not use dynamic scoping if you need it, but also have true static (lexical) scoping as the default? It’s so much clearer (see Scheme’s fluid-let vs let for a concrete example).

Also, JS the language lacks important OOP facility: message passing, ala Smalltalk. It is *very* useful in practice, too; and the ability to treat messages as first class objects can sometimes considerably simplify the code.

Comment by chiaroscuro — May 20, 2009

simple object constructor pattern to avoid the undefined errors/ unexpected behavior when a function is always supposed to return an object.

var obj = function(){
if(typeof this.init == ‘function’){
return this;
} else {
return new obj();

obj.prototype = {
//do public construction here

o = obj();
o2 = new obj;

//this would work as long as someone doesn’t add your init method to the function.prototype (dont do that =P )

Comment by soldair — May 21, 2009

I can’t believe no mention was made of garbage collection or memory management in general.

Once you start writing big apps which access a lot of data, these issues become crucial.

Comment by hymanroth — May 21, 2009

Consistent, yes, necessary to have to write out the boilerplate code? I don’t think so. The meaning of the first example remains, and involves less code which I think is a good thing.

In regards to type constraints, I don’t believe a large collection of types is necessary. Having just enough types available to enforce a contract system would be enough of a benefit itself (at least in the short run). This would remove a good portion of the boilerplate code that’s in common use today.

As was mentioned in the video, this should be in the next version. In the mean time Firefox, Rhino and possibly other implementations already have let definitions available for you to abuse.

Wouldn’t that be more of an issue with your software design? If you don’t remove the variables, closures and references when you’re done with them, why should they go away?

Comment by TNO — May 21, 2009

Good ES5 explanations are also at

Comment by erights — May 23, 2009

Leave a comment

You must be logged in to post a comment.