jsslickspeed: css3 selectors testing frameworks (jquery,dojo,mootools,prototype,yui,ext...) vs browser

How to create your own basic css selector in javascript.This was the plan for the next entry.Having a grasp of how this can be implemented could help many to improve the css selectors they use with their favorite framework. But before this article,it would be nice to know where actual javascript frameworks stands against one an other (including custom selectors created by some frameworks )and against the native implementation,document.querySelectorAll. Some results will be surprising...

Libraries tested

First things first, a list of the library tested:

• Prototype 1.6.1.0
• Mootools 1.2.4
• Ext js 3.1.0
• Dojo 1.5
• jQuery 1.4.2
• YUI 3.2.0
• RightJS 2.0
• document.querySelectorAll (when available in the browser).

I've included RightJS 2.0 in this tests as it was claiming to be the fastest (well, it's only a fraction of the framework that is tested) but unfortunately the css selectors supported are few...
We will see an in depth view of the results.

The test runner : jsslickspeed

jsslickspeed is a fork of slickspeed to use only javascript and add document.querySelectorAll in the list when available. Only tested with the following browsers so far:

• IE6 (emulated with IETester)
• IE7 (IE8 emulatation mode)
• IE8
• FF3.6
• Safari 5
• Chrome 6

jsslickspeed allows to load scripts from different servers too as I wanted to use google cdn when the library was available .

Tests contents

2 tests:

• CSS3 standard selectors
• CSS3 custom selectors

If the standard selectors test does not need further explanation, the custom selectors test may need some explanation.
The frameworks offer some shortcuts, ie, :even or :radio or :submit, :contains, [attr!=foo]. We will see that these custom selectors are not implemented in the same way, may slow down the process and could even be buggy.

CSS3 standard selectors

The test uses mostly the same selectors as the original slickspeed, I've just added some few selectors but nothing tricky (like weird construct to see how the library handles them).

• Let's start with IE series: IE6,IE,7 and IE8.

IE8 does have a document.querySelectorAll but unfortunately does not support css3 selectors.
The only one to fall in this pitfall is... RightJS. Having document.querySelectorAll does not mean that the browser supports css3 selectors.
This basically means that you can not write safely the same selectors across browser... Hope this bug will be fixed.

 

The IE implementation of the selector is rather fast but does not support 11 selectors (and therefore,Right JS only using the native implementation without adding extra parser functionality when required has the same errors. The speed is not representative for this library here).
Dojo is the fasted followed by jQuery. YUI is extremely slow followed by Prototype, Mootools and Ext JS.

Moving on to IE7...
This version of IE and below do not implement document.querySelectorAll.All the libraries use therefore their own css selector parser and implementation:



We can see that RightJS goes out of the roof but does not implement properly 15 selectors (attribute selectors,ie [class=example],are all wrong). YUI and Prototype are as slow as in IE8 but we can see that Ext JS and Mootools are faster than jQuery while Dojo is still the fastest.

Let's move on to IE6...



Well, no real surprises, this is slow...
Ext JS is the first of all and Dojo, jQuery,Mootools follow. YUI,Prototype and RightJS(buggy anyway) are outsiders.
It is to note that Prototype has some selectors that make its result jumps... "div ~ p" for example takes about 450ms where other frameworks are between 40~100ms. All the attribute selectors are around 200ms and p:nth-child(n) is at 300ms against a 20~40ms for the others.

As a conclusion on the IE series:

IE8 does offer a native selector but unfortunately, by not implementing the css3 selectors can not be used reliably unless you intend to use only css2 selectors in your projects.
You should avoid RightJS if you intend to develop with css3 selectors in mind.
As for the speed concern, it would be too easy to reduce a library to its sole implementation of css selectors and if the speed is an indicator it can not be used a the primary reason to elude a framework(unless you intend to use heavily complex selectors beyond class selectors, id selectors and descendant selectors).

• Firefox

This gets better!
Prototype gets back in the track while misteriously Mootools and Ext are the slowest. But even the slowest is at around 230ms when compared to the 1400ms in IE8, this is really nothing!

Obviously the native selector of Firefox is the fastest of all and now YUI is the first in the list.
Most of the libraries use the native implementation behind the scene and add some extras that's why the result gets tighter.

Notice that Firefox implementations requires about 40ms to do the tests.

• need for speed or Chrome:

Makes no surprise here but Chrome is blazing fast,it takes about 14ms for its native implementation to do the tests which is almost 4 times faster than Firefox. Obviously we are talking about ms here so it's not going to be as noticeable as the 2500ms of IE6...

YUI is again the fastest of all, followed by jQuery,RightJS and Dojo.
RightJS using the native selector does get the test right this time.
Prototype,Mootools,Ext are not so bad but could gain in speed.



Safari 5 is really fast natively and we basically have the same result as Chrome 6, no surprises here.

As a conclusion for the standard selectors

Amongst all the libraries, Dojo and jQuery stands out as they offer the most reliable engine and speed. Prototype,YUI were very deceptive in IE while Mootools and Ext JS even if a little bit slow does offer some good results in every browsers.

»Continue with custom selectors