SlickSpeed CSS Selector TestSuite

[RobG]

The link below is to a CSS selector test suite that tests 6 popular
libraries:

<URL: http://ajaxian.com/archives/slickspeed-css-selector-testsuite
It might be of interest to some.

 

[-Lost]

The link below is to a CSS selector test suite that tests 6 popular
libraries:

<URL: http://ajaxian.com/archives/slickspeed-css-selector-testsuite

It might be of interest to some.

Very cool. A supposedly neutral look at the various mainstream
libraries and their CSS abilities.

I wonder though, on a precursory glance, dojo had 15 green blocks
(fastest), 3 black (errors), where MooTools had 7 green, and 1 black.

MooTools also had more "found the wrong things."

Whatever algorithm is being used determined that MooTools was then
*twice* as fast as dojo.

*sigh* Prototype was the fastest. Hehe.

Thanks for the link.

 

[RobG]

Very cool. A supposedly neutral look at the various mainstream
libraries and their CSS abilities.

I wonder though, on a precursory glance, dojo had 15 green blocks
(fastest), 3 black (errors), where MooTools had 7 green, and 1 black.

MooTools also had more "found the wrong things."

Whatever algorithm is being used determined that MooTools was then
*twice* as fast as dojo.

*sigh* Prototype was the fastest. Hehe.

I don't think absolute speed is necessarily the key - IE takes 10
times longer than Firefox overall and which library is "fastest" is
browser dependent.

Using Firefox or Safari, Prototype.js is not only fast, but the only
one to get no errors (though whether it gets "correct" results every
time I can't say). I haven't looked the different libraries too
closely, but Prototype.js uses XPath where it can, which probably
explains its good results in browsers that support it well.

A big issue with CSS or XPath selectors is that they tend to be used
badly, I've seen plenty of examples of code where programmers have
used a lengthy selector to get a reference to a sibling or parent.

 

[-Lost]

I don't think absolute speed is necessarily the key - IE takes 10
times longer than Firefox overall and which library is "fastest" is
browser dependent.

Using Firefox or Safari, Prototype.js is not only fast, but the only
one to get no errors (though whether it gets "correct" results every
time I can't say). I haven't looked the different libraries too
closely, but Prototype.js uses XPath where it can, which probably
explains its good results in browsers that support it well.

I guess this is really where jQuery's "basic XPath support" comes into play.

A big issue with CSS or XPath selectors is that they tend to be used
badly, I've seen plenty of examples of code where programmers have
used a lengthy selector to get a reference to a sibling or parent.

I think I have seen examples of this. Instead of employing (in jQuery
for example) parent(), children(), and siblings(), I have seen:

$('body/div/div/p').eq(1).css('font-size', '2em');
$('body/div/div/p:eq(2)').css('font-size', '4em');

That might do for a one-off solution, but definitely not extensible.
But somehow people focus on the XPath shite, and forget native functions.

As is the nature of JavaScript though, jQuery introduces the ability to
write really crappy code or really great code. For example, in order of
worst to best (in my opinion):

function change_class()
{
$('p').each(function()
{
if (this.className == 'foo')
{
this.className = 'bar';
}
});
}
function change_class2()
{
$('p.foo').each(function()
{
this.className = 'bar'
});
}
function change_class3()
{
$('p.foo').removeClass('foo').addClass('bar');
}

Then again, knowing me, there is probably an even cleaner method. (I
purposely ignored toggling.)