New direction for 'JavaScript 2'

A factional fight that held up the popular language's evolution has apparently been resolved

Standardization efforts for the next version of JavaScript have taken a sharp turn this month, with some key changes in the Web scripting technology's direction. JavaScript creator Brendan Eich, CTO of Mozilla, has helped forge a consensus on how to proceed with the direction for JavaScript's improvements. "JavaScript was sitting still. It was stagnant," he says.

The fundamental reason to update JavaScript -- whose standard hasn't changed since 1999 -- is to handle the heavy demands being placed on it. Although the language certainly has caught on for Web application development, it was not envisioned for the workloads now demanded of it by developers, Eich says. "They're using it at a scale that it wasn't designed for."

[ Read InfoWorld's deep-dive interview with Brendan Eich on JavaScript's future. ]

The biggest change in JavaScript 2's direction is that the ECMAScript 4 project has been dropped. That change resolves a long-simmering debate as to whether ECMAScript 3.1 or ECMAScript 4 should be the basis of JavaScript 2. (ECMAScript is the formal name for the standard, vendor-neutral version of JavaScript.)

This decision at the ECMA International standards group overseeing the JavaScript standard unites the EMCA International Technical Committee 39, including Eich, with Google and Microsoft around the "Harmony" road map. (The committee and Eich favored a major revision to the ECMAScript standard, while Microsoft and Google opposed such grand plans, Eich says. "Microsoft [in particular] started working on a much smaller improvement to the last version of the standard," an effort that is now the core of the ECMAScript 3.1 plan, he says.)

First up: a rationalized ECMAScript 3.1
The "Harmony" road map starts with an effort to finalize ECMAScript 3.1, essentially a rationalization of the current version, and produce two interoperable implementations by spring 2009. "I think you could characterize 3.1 as a maintenance release," says John Neumann, chair of the technical committee. The ECMAScript 3.1 effort will formalize bug fixes but also standardize across all implementations some of the improvements made in the field, Neumann says. That's key, so applications written for one browser will work in another.

After the ECMAScript 3.1 effort, work will then proceed on a more significant ECMAScript successor dubbed Harmony.

The result is that the standards effort "wasn't to be the big, scary fourth edition that Microsoft and others objected to," Eich says. But the decision also means no more stalling on JavaScript 2, as well as agreement to continue to refine ECMAScript 3 after the 3.1 effort is done. Furthermore, developers likely will have to wait until 2010 for the Harmony standard, Eich says.

In essence, the JavaScript 2 effort will no longer depend on ECMAScript 4 being finalized, and instead will proceed from an improved ECMAScript 3.

Next in line, a less ambitious "Harmony" version
The new strategy means that some ideas planned for ECMAScript 4 have been dropped, after being deemed unworkable for the Web. Several ECMAScript 4 ideas "have been deemed unsound for the Web and are off the table for good: packages, namespaces and early binding," Eich wrote in his blog. But other ECMAScript 4 ideas remain in the mix, though with some changes to make them palatable to the entire technical committee, such as the notion of classes based on ECMAScript 3 concepts combined with proposed ECMAScript 3.1 extensions, he says.

Harmony could feature classes as a stronger way of making objects and generators to enable powerful programming patterns. Generators already have been featured in JavaScript 1.7, ahead of the official specification.

But beyond agreeing that there will be a Harmony effort, the technical committee has yet to figure out what will actually go into the Harmony standard.

Addressing JavaScript security holes
Plans for both ECMAScript 3.1 and Harmony call for providing tools to help developers more easily implement security. That plan will require the technical committee to codify security practices; the committee plans to meet this week to discuss security. "I think a secure ECMAScript will be based on some future revision of ECMAScript," beyond version 3.1, Neumann says.

Currently, JavaScript is at risk for cross-site scripting attacks in which any application can request executable inclusion in an existing application on a Web page, Neumann says. "The intent is to solve that problem."

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies