Mike Shaver writes, “Over the past year, JavaScript performance on the Web has undergone a striking revolution. Virtually every browser has improved its engine to produce significant gains in execution speed; Firefox 3 is about 3 times faster than Firefox 2 in various JavaScript benchmarks, for example. We’re not done. In addition to continuing to work on our existing JavaScript interpreter, we’re also looking farther into the future of JS performance. Yesterday we landed TraceMonkey in the Firefox 3.1 development tree, configured off by default. We have bugs to fix, and enormous number of optimizations still to choose from, but we’re charging full speed ahead on the work we need to do for this to be part of Firefox 3.1″. Early tests are showing significant speed and performance improvements, and all of this has been blogged about at length by the various people involved:

• TraceMonkey: JavaScript Lightspeed (Brendan Eich)
• Tracing the Web (Andreas Gal)
• The Birth of a Faster Monkey (Mike Shaver)
• Great performance improvements coming for Firefox 3.1 (Mike Schroepfer)
• TraceMonkey (John Resig)

Recent events related to ECMAScript — the specification that guides the development of JavaScript — have generated an unusual amount of buzz and press coverage. The crux of the matter is this: the ECMAScript 4 specification has been under development for quite some time. Those involved (primarily from Adobe, Mozilla, Opera, and Google) agreed upon a set of features they thought should be implemented and created a specification around that framework.

Other people (primarily from Microsoft and Yahoo) disagreed with how much of the ES4 specification should actually be implemented. Within the framework of the ECMAScript 3.1 activity, they advocated select changes to ECMAScript 3, and were averse to some of the syntax changes in ES4. Almost inevitably, this split lead to a situation where the ECMAScript 3.1 group wanted to add changes that would impact the development of ECMAScript 4, resulting in a clash between the groups that has stretched out over the past year.

Discussion between these two groups finally came to an amicable conclusion earlier this month at the July 2008 Oslo meeting, however, resulting in a cooperative refocusing on simplicity and pragmatic language additions. This collective effort will work to improve the existing ECMAScript 3.1 specification while, simultaneously, working on a new successor specification with the moniker “ECMAScript Harmony” that will include more significant language additions.

These developments have been covered extensively by other bloggers and podcasters, where you can get the full story: John Resig on ECMAScript Harmony, Arun Ranganathan’s Thoughts on Harmony and Evolution, and the Open Web Podcast on ECMAScript Harmony.