ECMAScript 5: What took you so long?

ECMAScript 5 was finalized this week, and it’s surely cause for celebration. The ECMAScript specification is the root of both JavaScript and Adobe Flash’s ActionScript language, making it one of the most important and influential standards in computing today.

If you’ve followed the standardization process at all, it may seem as if the ECMAScript technical committee is jumping the gun. After all, the version of the standard that current browsers support is only ECMAScript 3.

But don’t worry; no one could accuse the ECMAScript committee of undue haste. On the contrary, the real question — given how badly a revision of the standard was needed — is why it took the ECMAScript technical committee 10 whole years to approve one.

JavaScript grows up

“I think it was actually good that we waited some of those years,” says Yahoo’s Douglas Crockford, one of the leading figures in ECMAScript development.

In 1999, when ECMAScript 3 was approved, it was still very much a Web 1.0 world. Forget about AJAX; lots of Web applications still ran on CGI scripts. The idea of writing full-blown productivity applications that ran in the browser would have been laughed off as a pipe dream. “The Web wasn’t stable,” says Crockford. “There were too many versions of too many browsers, and only two browser makers at that time. There were just too many bugs in it, so it was not stable enough that you could write applications.”

As the years wore on, however, the stability of the Web improved. New vendors entered the field, and the increased competition encouraged browser makers to fix nagging bugs. Soon, major software vendors were eyeing the Web as a platform for serious application development.

But developers’ eagerness to exploit the Web led to a whole new problem for the ECMAScript committee. Now, new ideas began pouring in from every side. Ambitious proposals bogged down the draft ECMAScript 4 standard with pages of new documentation. As its complexity grew, browser vendors began to worry that implementing the entire standard was becoming infeasible — and a standard that can’t be implemented is virtually worthless.

Finally, after months of bickering, the ECMAScript committee brought the gavel down. In August 2008, the ECMAScript 4 initiative was formally scrapped. Taking its place was a much less ambitious effort, which was dubbed ECMAScript 3.1 but has since morphed into ECMAScript 5.

Measure twice, cut once

To Crockford, the failed ECMAScript 4 effort was a setback, but a necessary one. As he wrote in 2008, “the only thing we [the ECMAScript community] have to fear is premature standardization.” By avoiding expensive mistakes, the ECMAScript 5 standard has yielded a productive compromise.

That’s not to say that abandoning ECMAScript 4 ended the bickering. A number of proposed features still didn’t make the cut in ECMAScript 5. For example, namespaces — which Adobe has already implemented in ActionScript 3 — didn’t make the cut; neither did a system to improve the accuracy of ECMAScript’s decimal math, despite IBM’s insistence. (The new system would have slowed down processing considerably.)

But although its goals were not as high as ECMAScript 4’s, ECMAScript 5 adds important new specifications to the language. Notably, the JSON grammar for specifying and serializing objects is now a formal part of the specification. There are also new keywords that programmers can use to protect objects from unwanted modification.

Perhaps the most important new features in ECMAScript 5 is the formal definition of a “strict” ECMAScript language. Much like “use strict” in Perl or the strict dialects of XHTML, strict ECMAScript 5 forces programmers to abandon sloppy and outdated practices from the early days of JavaScript.

These might seem like trivial or redundant efforts; JSON has been around for years. But according to Crockford, this is only appropriate. If the ECMAScript 4 debacle taught him anything, he says, it’s that there must be clear separation between the process of developing new language features and the process of standardizing them. “If you’re doing science experiments in a standard, you’re doing it way wrong,” Crockford says. “The standard is the last place in the world that you want to see innovation.”

What’s next for ECMAScript?

If you’re wondering where the next phase of JavaScript innovation will come from, however, don’t fret. Google has launched a full-court press for the Web as the application development platform of choice, and other vendors have little option but to follow its lead. There is little doubt that JavaScript will play an increasingly central role in the future of software development.

Improving JavaScript performance has become the most important goal for browser vendors. Google claims the latest version of its Chrome browser executes JavaScript 39 times faster than IE8. Apple and Mozilla have countered Google’s efforts with accelerated JavaScript engines of their own. (Apple’s Safari beats Chrome on the Mac, in fact.) And even Microsoft has now promised to address JavaScript performance in IE9.

Yet Google plans to go even further. Its upcoming Chrome OS promises to tie JavaScript more closely to the underlying hardware, allowing JavaScript developers to take advantage of such features as native processor threading and GPU acceleration. You can be sure that as these capabilities appear, Google will propose new changes to the ECMAScript standard to accommodate them.

What remains to be seen is whether it takes another 10 years for the changes to be approved. Crockford, for one, hopes not — but in the world of standards, it’s always safer to err on the side of caution. “Hopefully it won’t take that long for the next one,” he says. “We’re hoping it’ll be in two and a half years, but these things always take longer than we think, so it’ll probably be more. But hopefully not 10 again.”

This article, “ECMAScript 5: What took you so long?,” originally was published at InfoWorld.com. Follow the latest developments on JavaScript and application development at InfoWorld.com.