Which JavaScript OOP design pattern will most take advantage of (new) ECMAScript 5 features?

Question

ECMAScript 5 is in final draft now, and includes new features relating to objects and prototypes. While hunting around SO and Google for OOP design patterns, I found that there were quite a few different ways of "doing OOP" (however you might define OOP, from trying to emulate classical OOP to simply trying to cut down namespace pollution) in JavaScript.

Which design pattern is the most forward-looking vis-à-vis the direction ECMAScript 5 is taking the JavaScript world? What are its key advantages? Which of those weren't possible or as nice to implement before?

Answer 1

I don't think ECMAScript 5 changes the landscape for OOP in JavaScript. Classical OOP will still be a bolt-on for people who want to use it.

The real story, in my opinion, is that when ECMAScript 4 was scrapped, JavaScript and ActionScript diverged, and JavaScript will NOT be adding classes the way ActionScript did.

I suspect that the libraries that support OOP (MooTools, Prototype, etc.) will mostly stick to what they are doing, but maybe they can use some new ECMAScript 5 features in their implementations to solidify things.

And we'll probably keep seeing interesting approaches like Joose and Class.js.

Remember this is going to take awhile. We still have a double-digit chunk of people using IE6. So the first useful places to use ECMAScript 5 will probably be on mobile phones, Adobe AIR, and JavaScript servers, where the browser is (mostly or strictly) known.

John Resig posted an article on ECMAScript 5's object changes here.

Answer 2

I think the standardization of Object.create will allow more people to use the underlying prototype-based OO without shame. Trying to hide the "new Foo" pseudo-classical syntax behind a wrapper makes the code confusing.