Getting Faster With TraceMonkey

Mike Shaver has an awesome blog post on work to speed up JavaScript. Granted Firefox 3.0 is pretty fast already, 4.0 is shaping up to put 3.0 to shame. For those who don’t want to read it all, here’s what you really should know:

The goal of the TraceMonkey project — which is still in its early stages — is to take JavaScript performance to another level, where instead of competing against other interpreters, we start to compete against native code. Even with this very, very early version we’re already seeing some promising results: a simple “for loop? is getting close to unoptimized gcc[.]

That is a very impressive feat, and even more impressive is that it’s so early on. Schrep has a demo for anyone who still doesn’t see what this really means for future web applications.

Brendan has a great blog post with some more details on what has been done so far, as well as some more graphs.

The first thing that comes to mind is that it makes <canvas /> much more useful. While it already is handy, one of the big problems is that it doesn’t take to much to make it feel slow.

I think the real benchmark for most people these days is Gmail and Yahoo Mail, which are likely the two most JavaScript intensive applications most people use on a daily basis. Most people saw a nice gain when moving to Firefox 3.

Considering a substantial part of the browser chrome is implemented in JavaScript, this work has significant impact in the future performance of the browser as well as the web applications that run within it.

This all comes just a matter of hours after querySelectorAll landed, which will also give a boost in performance as John Resig explains.

A few months ago I mentioned SquirrelFish, the WebKit teams attempt to improve JavaScript performance. It’s great to see performance being such a focus.

It’s important to note that this isn’t just about making things feel faster, it opens up the web to handle things that previously couldn’t be done before. It also paves the way for a better mobile experience. Two fantastic things. Things that previously a browser just couldn’t do as well as a desktop application will become possible in the not to distant future.

Embedded JavaScript For Web 3.0

John Resig has an interesting blog post on embedded JavaScript. It’s something I’ve been thinking about for a little while.

It would be awesome to see a PHP extension to embed SpiderMonkey into PHP. As far as I’m aware Facebook is the only one that’s taken a step in that direction with FBJS, which uses Mozilla source code. Perhaps that could be a starting point.

Considering the ubiquity of JavaScript, using SpiderMonkey, which is already available for Perl and Python, or Rhino (for Java) would make sense. It would allow for JavaScript to be for logic what XML is for data. In my mind that is nirvana for the web.

XML made our data portable. JavaScript can make our logic portable. Seems practical enough right?

For those who question security, it’s really up to the client to decide if it should parse JS, and what subset it should allow (perhaps no eval()). Having an API based on JS is really no less secure than any other language including one that’s home made. It’s advantage is that it’s used everywhere else and makes your API easier to work with.

This could be cornerstone of Web 3.0. Web 2.0 was largely about shared data and isolated small services. Web 3.0 could be about shared data and shared services.