While at MIX08 one of the many exciting announcements was the beta release of IE8. Luckily the IE8 team was there and I was able to spend a great deal of time picking their brains to find out what they were doing with IE8, what changes they had wrought under the hood and why they had made the choices they had. This was very enlightening and coming away from that I have a very different impression of them and where they are going with the browser. I know this may be difficult for anyone who has had to support any of the previous versions of IE to believe, but I see a radical change in Microsoft's strategy for IE. And this is very good for all Web developers and end users. (By the way, I own no Microsoft stock nor receive any money directly from them.)

Most of the public announcements about IE8 were regarding improved support for CSS, specifically a full implementation of the 2.1 specification. Fortunately they didn't stop there. They've also made substantial improvements in IE8's JScript engine. This included major speed increases. Previously IE was as slow as molasses in January when you had to iterate over large collections. This is a thing of the past. Even more important are changes to some of the core functionality that differed from the standard adopted by other browsers. I'll talk about those in another post.

Then there is something totally new, something I didn't see coming and totally floored me when I was told it: IE8 supports the same selector API that Webkit recently adopted from the W3C (http://www.w3.org/TR/selectors-api/). Since I had posted benchmarks in a previous post showing the huge speed increase in getting document nodes when using a browser's native implementation of the selector API through the querySelector() and querySelectorAll() methods, I thought I should run that same test with IE8.

When I ran the test, one of the interesting things I found was the general speed increases that JavaScript libraries got from the changes to IE8's JScript engine. Even better is the speed of IE8's querySelector and querySelectorAll for accomplishing the same tasks.

The select test was originally put together by the Mootools team to show how libraries differed in speed when accessing nodes with their own selector APIs. To be fair, the present version of IE8 is an early beta and they told me they expect to make further improvements to speed. The test is based on the following document http://www.w3.org/TR/2001/CR-css3-selectors-20011113/.

So here's a summary of my test compared to the same test run on IE7 (values are in milliseconds):

And now the best part, how the native implementations in IE8 and Webkit compare. At the moment, IE8 is only 424 milliseconds slower than Webkit:

From the above we can see that Webkit is still substantially faster than IE8 at this test. But I think we need to bear in mind that we are talking milliseconds. You will notice that IE8 failed to get nodes in seven instances. This would give Webkit a further lead if IE8 had rendered these. These seven tests that IE8 failed where all selectors based on the CSS 3 specification. I would expect this since the IE team told me that they were hesitant to implement CSS 3 APIs at this time since parts of the specification are still not finalized. Below is the actual result of IE8 running the selector test:

Now the ball is in Mozilla and Opera's court to implement the selector API. We are in interesting times.