Valerio Proietti, of mootools, created the Slickspeed test to be able to test the speed and validity of CSS selectors in JavaScript libraries. A lot of persons have expressed their take on the test itself, and I thought I’d share my opinions.

The test itself

Anyone can download the test to try it out and tweak it for your own specific needs. All you need to have is a web server capable of running PHP. You can then use what frameworks you want to test, by putting the framework JavaScript file in the folder named frameworks; please note that in the download, there are no JavaScript frameworks available, so you need to download each framework you want to test. Then point out/activate frameworks through a file in the root called config.ini. It can look something like this:

[DOMAssistant 2.6]
    file = "DOMAssistant.js"
    modifier = ""
    function = "$"

[Mootools 1.2b2]

    file = "mootool1.2b2.js"
    modifier = ""
    function = "$$"

You then choose what selectors you want to run, in the file called selectors.list, where you put each selector in its own line:

*
body
div
body div
div div

Objections/concerns regarding the test

While most people agree that this is a good addition to swiftly test CSS selectors, the most common objections are:

1. If a selector fails, the time for that might be shorter than if it would have worked. The result is the overall result/time for that JavaScript library can then look better than it actually is.
2. Accuracy, If a selector returns a number of nodes, there’s no way to determine if it actually were the correct and/or the right number of nodes.
3. It doesn’t put any value into that some selectors are more important to have a better performance for. E.g. an id selector (#container) needs to be faster than a more uncommon selector, for example: div:nth-child(2n+1).
4. The test HTML file doesn’t resemble any real-life scenario.

My take

I agree that those concerns are valid, but I think people somewhat misinterpret the situation. Slickspeed has never claimed to be the only test, the mother of all solutions, which will decide if a JavaScript library is fast or accurate. It is one of many ways to test your and others’ CSS selector in any easy fashion, but then you need to, of course, test the code in actual project scenarios and such.

To reply to the above concerns:

1. Absolutely true. However, it does indicate if a selector has totally failed, so you can take that into account.
2. Again, this is correct. However, if all major JavaScript libraries return the same number of nodes, it is fairly reasonable to assume that it has indeed returned the correct nodes; hence, a speed comparison is valid.
3. Of course, some selectors are more used than others, but I don’t think people will ever agree exactly on which ones that are most important. Looking at the Slickspeed results, you can see for yourself how each JavaScript library performs with different selectors, and then it is your call to decide which ones are most important to you. I.e., the value of a selector is in the eye of the beholder.
4. No, it doesn’t. But it’s still a basic page test where you can easily compare JavaScript libraries’ performance to each other. Besides, this is completely customizable, so you can put in any HTML you want.

Conclusion

At the end of the day, I think that Slickspeed is a good tool for us JavaScript library developers to test our CSS selectors in a very easy way. It indicates where we have performance problems, and in some cases, where we need to overlook accuracy.

We still need to test with lots of different source code and combinations, and Slickspeed is just one of the steps in that way. Then I, as everyone else, would love a test suite where we could pinpoint accuracy even more, make advanced comparisons, and then each JavaScript library would choose what path they want to take.

So please, see the Slickspeed like what its for: a good overall performance indicator and a decent tool for checking accuracy.