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."