There are some really exciting things to come, some of the biggest being to the foundation Object object’s functions which will allow turning off Enumeration on properties, making “read only” properties, etc. I’ve noticed a lot of this has come from Mozilla’s innovation and also I see some similarities to PrototypeJS’s modifications to prototypes.

• JSON object
• Object object
• Function object
• Array object
• String, Number, Boolean, Date
• Miscellaneous

JSON object

The first major addition in the draft is the JSON object, which is not a constructor but rather similar to the Math object and some of Object’s functionality.  JSON.parse takes a JSON string and creates an object.  JSON.stringify takes an object and creates a string.  Pretty simple!
JSON.parse has an optional 2nd parameter (a function) that receives a key and value which it can return a value to override the original value.
JSON.stringify has an optional 2nd and 3rd parameter. The second being a function to modify the way objects and arrays are stringified or an array of white listed keys to stringify.  The third being a string or number that allows the result to have a singular space or up to 100 spaces (and line feeds) between keys of the object.

Object object

• Object.getPrototypeOf(O) returns the prototype of O if O is an Object.
• Object.getOwnPropertyDescriptor(O, P) returns the property descriptor of O’s (as object) property P (as property of O).
• Object.getOwnPropertyNames(O) returns an array of property names (uses ToString on the names).
• Object.create(O[, Properties]) returns an object with a prototype of O and properties according to Properties (as if called through Object.defineProperties).
• Object.defineProperty(O, P, Attributes) returns O after adding a new property P with a property descriptor of Attributes. Just imagine the possibilities when O is a DOM element :). Read: DOM Prototypes Part 1 (Intro), Part 2
• Object.defineProperties(O, Properties) returns O after enumerating Properties as name/descriptor (e.g. {name: descriptor}).
• Object.seal(O) returns O after setting the internal Configurable flag to false for each property of O and the internal Extensible property of O to false.
• Object.freeze(O) returns O similar to seal except the internal Writable flag is also set to false.
• Object.preventExtensions(O) returns O after setting the internal Extensible property of O to false.
• Object.isSealed(O) returns boolean based on all properties’ Configurable (any true returns false) and O’s internal Extensible property (a false returns true).
• Object.isFrozen(O) returns boolean similarly to isSealed except Writable is checked (any true return false).
• Object.isExtensible(O) returns boolean value of the internal Extensible property of O.
• Object.keys(O) returns an array of property names.

Function object

Function binding!  Now this is based on whatever you bind a function to or whatever this internally would be by default.  What that means for us is that we can bind functions easily to objects via the prototype so that calling this in those functions returns the associated object. Function.prototype.bind(this[[, arg1] arguments…]) where arg1/arguments are passed into the function first.

See: PrototypeJS’ implementation

Array object

Array.isArray(arg) returns boolean based on if the internal Class property is “Array”.

• Array.prototype.indexOf(needle[, fromIndex]) returns the position of needle in the array, if not return -1 is returned.  If fromIndex is positive or 0 (defaults to 0) this is the start index; if it is negative fromIndex is the offset from the end of the array to begin searching.
• Array.prototype.lastIndexOf(needle[, fromIndex]) returns similarly to indexOf except the array is searched reversely.
• Array.prototype.every(callFunc[, thisArg]) returns boolean depending on callFunc’s return value via iterating the array.  If thisArg is specified, the function is bound to thisArg, otherwise thisArg defaults to undefined.  callFunc gets three arguments for each element in the array: value, count, the object of this (not what thisArg is!).
• Array.prototype.some(callFunc[, thisArg]) returns boolean similarly to every except one true instance returns true.
• Array.prototype.forEach(callFunc[, thisArg]) returns nothing, but processes similarly to some and every.
• Array.prototype.map(callFunc[, thisArg]) returns a new array of return values by processing similarly to forEach.
• Array.prototype.filter(callFunc[, thisArg]) returns a new array of elements that callFunc returns true while processing (similarly to the processing of forEach).
• Array.prototype.reduce(callFunc[, initialValue]) returns a value that is daisy-chained through callFunc by passing accumulator, property value, index, and the object.  The return value of callFunc is passed into the next call as accumulator, then accumulator is returned.  initialValue sets the starting accumulator, otherwise this starts at index 1 (2nd element) with an accumulator of index 0.
• Array.prototype.reduceRight(callFunc[, initialValue]) returns similarly to reduce except from right-to-left in the array (last to first).

String, Number, Boolean, Date

Date.now() returns a Number with a unix timestamp.

• String.prototype.trim() returns the value of this without white space on the left or right.
• Date.prototype.toISOString() returns a string representing the time in the Date Time string format as UTC.
• String.prototype.toJSON(key), Boolean.prototype.toJSON(key), Number.prototype.toJSON(key), Date.prototype.toJSON(key) returns a string that represents object.  Does anyone have some ideas on what key actually does for this?

Miscellaneous

Of importance is that Unicode 3.0 is now supported, including relevant whitespace additions.

Line terminator characters proceeded by an escape sequence (\) are allowed in a string.

Indirect calls to eval use the global (window) environment.

For-in doesn’t throw errors for null/undefined, instead it just continues as if it was given an object that had no enumerable properties.

Strict Mode was added, but I’m unsure if we’ll see this in JavaScript (see Annex C; page 237).

New keyword debugger is moved from future reserved words to keywords and allows triggering a breakpoint when running within a debugger, otherwise it should have no observable effect.

The Object object is now setup drastically different internally: ReadOnly becomes “Writable”, DontEnum becomes “Enumerable”, DontDelete becomes “Configurable” (also only allow some changes; with exceptions, see 8.6.1). “Set” was also changed from Put and is by default an undefined function. Most of this can be written over using property descriptors (see Object.defineProperty above).

(A lot more miscellaneous stuff, see Annex E for upgrade breakers.)

Suggestions? Comments?

Thank you ECMA :). Hope to see all of this implemented in a year or two (since IE8 in standards mode and Firefox 3.1 are to support at least portions of this) as part of JavaScript. Is there anything else you think should be in this post? Comment!

A closure is actually more liberating than the name implies.  It opens the door to new possibilities by passing variables between lower-level functions.

Take for example, a very simple closure:

As you can see, the ourVar variable is available to ourFunction2 despite ourVar being defined in the scope of ourFunction (locally).  Even if ourFunction2 wasn’t defined inside of ourFunction, we’d still have access to ourVar.  Similarly, if ourVar was a parameter of ourFunction, we’d still have access to it within ourFunction2.

Internet Explorer and Circular References

So what is it about closures that give them a bad rap?  The horrible truth is that Internet Explorer is to blame.  A bug in their automatic garbage collection of closures (removing unneeded closures) causes circular references involving DOM nodes or ActiveX objects to not be freed from the memory until the browser closes.  A circular reference is created when 2 or more functions/elements/objects refer back to each other.

The obj variable is referenced, and then a closure is created for the onclick event of obj. This means that the closure will never be cleared, even if document.onload is changed. But there is hope! One solution is to simply set obj to null after creating the closure. This breaks the circular reference by removing one of the objects in that circular reference.

Another solution is to create another closure within the function to prevent the circular reference.

Or, alternatively, just avoid creating a closure in general.

To closure or not to closure?

Any way you look at it, closures are a powerful feature of JavaScript. They enable some really special things to happen in JavaScript that would be much more difficult without the feature.

This growing trend, which in my opinion is great, seems to have come out of the simple concept: Keep It Simple Stupid. With sites like MSN and NBC, a user can easily get lost in finding what they’re looking for if it’s their first time visiting the site — think of your grandma that just got that brand new Intel Quad Core. They go in looking for show times and end up writing a chain letter about boycotting XYZ Corp.

Some of the biggest design sites out there (e.g. Smashing Magazine) award and applaud sites that adhere to standards, and many of their reward winners are professionally simple sites. Taste isn’t always more graphics.