ECMA standards committee will steer toward a lighter JavaScript 2

The programmers in the trenches of Web development can breathe a bit easier now that a major committee planning the future of the JavaScript standard has decided to focus on small, incremental changes that will improve the performance in Web browsers. Some members of the ECMA International standards committee still have bigger dreams to enhance the language, known more formally as ECMAScript, to tackle more complicated projects, but these plans receded as the group focused on clearer and more present needs.

Kris Zyp, a researcher at SitePen and the Dojo Foundation's representative on the committee, said, "Our interest is empowering the Web developers, not seeing ECMAScript as a pure research language."

Many of the ideas that some committee members wanted to bring to the ECMAScript 4.0 standard are well known by programmers, but they're often associated with other languages and other styles of writing code. Some wanted ECMAScript 4.0 to include stronger ways for the programmer to specify the type of each variable, a more structured approach that's required by languages like Java.

ECMAScript 4.0 – now abandoned in favor of a more modest ECMAScript 3.1 proposal – was also going to have more sophisticated namespaces or packages that would prevent conflicts when two developers inadvertently use the same name for different methods.

Coders on big projects often crave these missing features because the structure helps avoid bugs and other problems. Language features such as dividing code into namespaces and adding types for the data structures are essential for keeping bigger projects functioning. When programming teams grow larger than one person, mind reading is harder than forcing the developers to use some extra structure. Adobe, for instance, incorporated many of these ideas into ActionScript to help developers create bigger, more sophisticated components that could be deployed through the browser. Much of the ECMAScript 4.0 standard was inspired by ActionScript and one of its spiritual forebears, Java.

While the foregone improvements would have helped some developers working with bigger projects staffed by more programmers, many coders considered them to be overly complex. Many developers like the more casual, LISP-like simplicity of JavaScript as it is today, and they see the extra structure as adding features and detail that a good programmer would rarely need. After all, JavaScript’s success is built on flexibly adapting to the code the person writes and not requiring the coder to spell everything out in detail. Why change that?

Thomas Fuchs, the creator of the popular Script.aculo.us framework, said that he won't miss any of these new ideas. "Lean is better, and less language features make for better interpreters." he said. "Think of mobile or embedded devices where performance is limited."

Dylan Schiemann, the CEO of SitePen and one of the initial developers of Dojo, noted that the new proposed features weren't going to speed up code as much as some had hoped. "The results of more research showed that the performance improvements weren't that great," he said, before pointing to the performance improvements of the latest JavaScript interpreters from Mozilla and Safari.

TraceMonkey, a new compilation approach recently announced by the Mozilla Foundation, is said to run some basic operations 20 to 30 times faster. The group claims the SunSpider benchmark runs almost twice as fast on the new implementation.

"It turned out that JavaScript implementations were just really sucky, and now they're getting better," explained Schiemann.

The stronger performance of regular implementations removes some of the drive for the new features. Indeed, many developers have already begun adding the new Mozilla and Safari interpreters to the language through the popular frameworks. Dojo, for instance, has a package system that offers namespaces. Many programmers aren't writing new JavaScript as much as working with these well-established frameworks.

The more casual, untyped structure of JavaScript makes it easier for frameworks to evolve. Developers can mix and cross-pollinate the code with a great deal of flexibility, adding features and creating potent sublanguages – at least until they reach the kind of namespace conflicts that sparked the ECMAScript 4.0 proposal.

Zyp said that most of the 4.0 ideas are still under consideration in some form or other. "ECMA 3.1 will be a relatively minor upgrade," he explained. "There's still active discussion about what will be after and that will be called ECMAScript Harmony."

"Having the next edition implemented by all parties including Microsoft is infinitely more valuable than having something implemented by just two browsers," Zyp said. "We're focused on what's easiest and fastest for people to use this stuff."

Peter Wayner is contributing editor at InfoWorld and the author of more than 16 books on diverse topics, including open source software, autonomous cars, privacy-enhanced computation, digital transactions, and steganography.