This article is more than 1 year old

JavaScript shogun deflects Google's mid-air Dart attack

Wirfs-Brock preaches Harmony

Sweet harmony

That's where Wirfs-Brock reckons ECMAScript Harmony could come in. Harmony is an over-used and somewhat lazy codename for technology projects; in this context, however, it denotes the permanently "next" version of the ECMAScript standard that underpins JavaScript.

Harmony's goals include making the language better for writing complex applications and libraries, including - it seems - writing the Document Object Model (DOM) code (which manages the elements on a web page) in native JavaScript. "There were things done in the DOM that were important to do in JavaScript, so you couldn't implement the DOM as a JavaScript library. We are making sure the language is able to support the DOM," Wirfs-Brock said.

A Mozilla research project has already tried re-implement the HTML5 DOM in JavaScript, but it seems to have slowed down or been stopped. Project member David Flanagan recently told The Reg by email he'd become involved in another project that was taking his time and called Dom.js "incomplete". However, he reckoned Dom.js would "become much more robust" as Mozilla's larger Servo Project for a "parallel browser engine" develops.

Wirfs-Brock was sanguine about the project, suggesting that "these things start and stop", but stressed native DOM would be a major step forwards for performance. "The more we can implement in JavaScript the less interoperability overhead and more flexible and extensible the environment is," he said.

Broad goals for Harmony are modularity and better abstraction capabilities. There's a discussion about whether JavaScript should be a functional or Object-Oriented language and also a debate about how permissive the language should remain and about security.

When it comes down to actual features in Harmony, these will include: sandboxes and module loaders, array comprehensions, binary data objects, built-in hash maps and sets, and super-method calls. Some of these, such as block scoping, array comprehension, maps and proxy, have already made it into browsers, specifically Firefox and Chrome between 2006 and 2008. Elsewhere "some of these details aren't really pinned down yet," Wirfs-Brock says.

In the meantime, there's no date for Harmony, although you can expect to be using Harmony's features in five to six years from now. Ahead of that, ECMAScript 6 is expected to be formalised by the end of 2013 when Wirfs-Brock also expects most browsers will be running ECMAScript 5.

Meanwhile, Google marches on with Dart.

The future meets JavaScript

Speaking at QCon last week, Wirfs-Brock reckoned that if there's a danger to JavaScript it'll be from the ECMAScript standards process, which could make JavaScript irrelevant to the needs of developers or chuck in the wrong things. ECMAScript 4 was considered a bit of a disaster and version 5 a success because it got everybody on track again.

And while Google pushes the Dart VM performance factor, Wirfs-Brock believes the performance problem for the language Google wants to replace has been solved, thanks in part to the break-neck work of JavaScript engine makers, who turned out with V8, Webkit, Spidermonkey and Chakra a few years back.

"People heard a lot about JavaScript performance - it's been a big area of emphasis for JavaScript engine implementers in last couple of years. For the moment, the JavaScript performance issues have been solved," Wirfs-Brock said.

Maybe JavaScript has done enough to hold onto its kingdom and to keep Dart at arm's length. And maybe not. ®

More about

TIP US OFF

Send us news


Other stories you might like