Mozilla's comeback in Javascript performance

In the beginning there was Netscape (though there were lesser known browsers before that). Then, seeing the opportunity to gain more marketshare and money, Microsoft licensed Mosaic, and created Internet Explorer. Then there was the first browser war.
The story is interesting, and there was a lot of unfair play, but everyone knows the ending. Microsoft included IE in Windows, and put money behind marketing and proved yet again that a superior product wasn’t necessary to win.
Then there was peace, with web developers having to only cater to one browser.
Then Netscape resurrected itself in the form of Firefox. It was far superior to Internet Explorer in every way. It was standards compliant, it had great extensions, it was cross platform etc..
While is gained significant traction, there were too many people who continued using Internet Explorer because it was preinstalled on their system, and others, who needed to use it because some sites required it.
For a few years, there were just two web browsers of importance, (Opera has existed for years, but had virtually no market share on the desktop). IE and Firefox. Then, suddenly, as Google (and Apple) realized the importance of controlling the web, Chrome was released (and Safari was ported to Windows). It marked a HUGE increase in Javascript performance, using a new Javascript engine called V8 (developed by Google employees in Denmark). Suddenly the race was on again. Safari was working on their Javascript engine Nitro and Firefox was talking about TraceMonkey.

New releases were made, and benchmarks were compared, and Chrome (with Safari right behind) was continually in the lead. Then, Firefox 3.5 was released, and the developers stressed the improvements in their Javascript engine. The results. Extreme disappointment. It was no where near Chrome’s level of performance.

So, how can Firefox stay relevant?
By building JägerMonkey.
According to Firefox developers David Mandelin, The reason we’re [building JägerMonkey] is that TraceMonkey is very fast for code that traces well, but for code that doesn’t trace, we’re stuck with the interpreter, which is not fast. So, to better explain. TraceMonkey is great when it works. When it doesn’t, performance sucks. So, basically they’re going to use the open source (free) Javascript engine developed by the Webkit guys as a failsafe.
So, when TraceMonkey works, they’ll use it. When it doesn’t, they’ll use the Webkit nitro (the Javascript engine in Apple’s Safari web browser). This failsafe method of trying to use TraceMonkey, with nitro failsafe is JägerMonkey. This seems like a great idea. That’s why open source software exists. Why rewrite code when it’s already available, has been tested, and is free.

I was very interested in this, so I got in contact with David Mandelin (from Mozilla) to discuss this.
Here is a transcript of our discussion:

Antony: Why not use V8 instead of Nitro?

David: We just liked the design of Nitro’s assembler. Also, their VM is more similar to ours generally, so we thought we would run into less trouble. We also learned that Nitro’s assembler is better optimized for ARM.

Antony: But, why wasn’t the following done ages ago? (since Firefox has lagged in Javascript performance ever since Chrome came out)
Use V8/Nitro as a complete replacement and then, later, when JägerMonkey is ready, switch to TraceMonkey with V8/Nitro assembler.

David: Doing a complete replacement would not be a quick process. The browser interacts closely with the JS engine, so the browser has a lot of code using the JS engine API and depends on the JS engine’s guarantees. There would be a lot of code to change and likely a lot of subtle bugs to fix.

Antony: Currently the main reason some people switched to Google Chrome is speed.

David: That is what I hear from my friends as well. I care about it a lot and making our JS faster is my top priority this year. As you say, the competition is very good, and we know we have to work hard to catch them.

That sounds like a promise!
It’s always great to get in contact with a developer and not hear excuses. David is aware that Firefox needs to improve, and is committed working toward that goal.
I look forward to an interesting year for web browsers!