ECMAScript 5 released

Posted by Alex Blewitt on Dec 09, 2009

Sections

Development,

Operations & Infrastructure

Topics

Javascript ,

Java ,

Internet

ECMAScript 5 was released this week (pdf), generally known as JavaScript™, bringing advances to the basic libraries whilst introducing stricter runtime modes to aid with identifying and removing common coding errors.

Earlier attempts to rationalise ECMAScript 4 largely failed; only Adobe's ActionScript is based on the proposed changes. ECMA didn't even release a version 4 specification owing to different groups being unhappy at the developments; and as such, no browsers support it.

Over the last few years, with large improvements in JavaScript engines like Nitro and TraceMonkey, JavaScript has become performant to the extent that collaborative tools like Google Wave are showing the way forward for on-line applications. There's even Speed Tracer, an extension to Google Chrome, released as part of GWT 2.0, to help optimise the performance of JavaScript applications.

With that in mind, ECMAScript 5 aims to be backwardly compatible with the currently in-use ECMAScript 3 version (to foster quicker adoption across browsers), as well as providing for stricter constraints for developers to avoid common coding pitfalls.

Strict mode

The introduction of strict mode aims to avoid common coding problems in ECMAScript applications. This is achieved with the presence of a lone string literal in a unit (script or function):

"use strict;"

This literal will have no effect on existing runtimes, but new runtimes that target version 5 will turn on strict mode for either the entire script (if at the top of the script) or for a single function (if the first part of a function). This allows for a mixture of strict and non-strict code and for an evolution of existing code. So, what does strict mode actually mean?

• Variables must be declared before use. In other words, i=3 becomes a runtime error; var i=3 is needed (assuming i is not in scope at the time)
• Eval becomes a reserved word, and introducing new variables through eval cannot occur, so eval("var i=3"); print(i); will now throw an error.
• Octal literals are no longer used; so 010 is ten, and not eight
• delete cannot be used against arguments, functions or variables or other properties with the configurable flag set to false
• with statements, often a source of errors, are no longer used and considered syntax errors
• Functions can no longer have duplicate arguments with the same name
• Objects can no longer have duplicate properties with the same name
• The arguments and caller variables become immutable
• Access to the global object becomes a runtime error

Library extensions

Other extensions are also present in the base library:

• Date now supports the ability to generate ISO8601 formatted dates (such as 20091209T12:34:56Z) as well as to parse them
• String now has a built-in trim() method
• A new JSON object with parse and stringify to support efficient generation of JSON data; like eval but without the security implications of being able to reduce code. In addition, any JSONValue can be used, not just JSONObject and JSONArray as specified in RFC 4627. (4627 defines JSON-Text to be constrained to an object or array.)
• A new bind builtin has been added, with the same semantics as Prototype's bind()
• Array now has standard functions, such as indexOf(), map(), filter(), and reduce()
• Object now has seal() (which prevents new properties being added or existing properties deleted) and freeze() (which makes all properties read-only, as well as preventing new properties being added or deleted)
• Object.keys() lists all the enumerable properties of the object
• Object.getOwnPropertyNames() lists all the enumerable and non-enumerable properties
• Object.getPrototypeof() returns the prototype of the given object

Summary

The additions of a standard JSON parsing mechanism and strict mode will be of great benefit to developers, with the potential to translate into smaller libraries for Prototype and other extension libraries required. Parsing ISO dates from a JSON stream now becomes much more portable than before, and looks likely to be the de facto standard for representing dates in the future. Lastly, since this is backwardly compatible and takes cues from existing libraries like Prototype, it is likely that developers and web browsers alike will take to the new features of JavaScript in the near future.

• Older >