What many seems to forget when using it, is that it only runs the query once. On a fast computer that almost always gives a 0 ms result. That doesn’t mean it’s instant, only that it took less that 1 ms. The problem is that timing in JavaScript is limited to milliseconds. So to get a true measurement the query must be run so many times that the total time takes a few ms, then divide the time by iteration count.

When testing our selector we use a modified Slickspeed. The results are quite interesting.

Again, you’re getting way too caught up in the particular example.

How could I not? It’s the only one you gave? Besides, my college debate professor always told us that you always go for the kill with your first shot–so I assumed you we’re trying to go for the kill with that one.. I was wrong, I guess.. :P

Anyway……

Developers should write selectors how they wish and they engines should work to improve. Libraries are there for the user and should implement what the users want – not the other way around.

I agree completely. And I think the Mootools devs do too, which is why they gave us, the users, the power to do something like this: http://paste.mootools.net/f5a08747c (Thanks to Simo [worrcu] from #mootools for this one).

What’s that? It’s an implementation of the “<” selector. Yes, one of the examples you gave. It’s incomplete, since it was just written in the span of a few minutes in between volleys in this thread, but it’s fully functional.

So what does this mean? In terms of extensibility of selectors, Mootools is at par with JQuery/Sizzle–those examples can be implemented in Mootools just as they can in Jquery/Sizzle. Of course, you could show us a real example of something Mootools can’t do (no syntax issues please.. :P ), but within the unix timestamp of this reply, Mootools and Sizzle/JQuery is even.

Now, one might argue that the example is too complex. “A regular user can’t do that!” But of course! We have to remember that these things–whether it’s a good thing or not–is not within the grasp of regular devs. It will be the intermediate and advance devs that will do these stuff, and they are the ones who actually know how to do it. I don’t know about you guys, but when I started using Mootools, I never had the urge to say, “Gee Golly Wiz! I do wish I could implement a new selector!” (I honestly don’t sound like that in real life..)

And for that matter, if you’re an intermediate or advance dev who’s been using Mootools for quite some time, you’ll probably know just how to do these stuff–because you’re already thinking the mootoolsian way.. :)

But–and this is the biggie–if extending Sizzle is way easier than this (and by way easier I mean that someone who’s a total noob can do it without banging their head on the table and praying to the Gods of Firebug), then I’ll zip it and have my peace.. :D

As to the actual flexibility of the codebases I cannot give any thorough comments. But arguing about hypothetical features can only lead to hypothetical results. We usually don’t know what’s next.

Why should developers be forced to work around limitations in selector engines? Developers should write selectors how they wish and they engines should work to improve. Libraries are there for the user and should implement what the users want – not the other way around.

As to your statement: “For example .classname will always be slower than tag.classname, thats a fact.” Maybe that’s the case in MooTools, but it’s not the case in Sizzle/jQuery. In Firefox 3, Safari, and Opera – which all implement getElementsByClassName – it is faster to just do “.classname” than to do “tag.classname” (since it requires extra post-processing).

especially because these test suites return a different result every time, sometimes it’s over 20% difference

seriously, what’s next? “omg, my thingy was 1 nanosecond faster in 1/1 000 000 tests”?

come on now

$$(‘a’).getParent(‘div’) returns an array with the first div parent of all a elements on the page. You could also probably implement the div:color(red) thing with just checking in your custom selector if color contains red and not only equals red (referring to my blog post from above, this is easily possible). I have no idea what you are doing with a & b but we still have Array.filter so we can do $$(‘selector’).filter(fn) to match all needs. So clearly, there is no need for custom selectors, as said. Also, I think adding a custom Syntax doesn’t make it any easier, MooTools sticks with the :name(property) selector so it still looks natural.

I want to add that it is not a good idea to optimize the selectors the people use but rather to advocate the recommended usage. For example .classname will always be slower than tag.classname, thats a fact and you (as in: the application developer) should optimize the selectors where appropriate. Given the nature of jQuery to appeal to people not knowing a thing about javascript this might not be possible for you, luckily for us MooTools states it is for the “intermediate to advanced developer” only, so we can :)

Again, you’re getting way too caught up in the particular example. Just to give some examples of the type of selectors that we’ve been discussing as possible plugins since we have an extensible engine.

“div < a” – Find all divs that are a parent of an anchor.
“a & b” – Find all anchors and bold words – but only if they both exist.
“#foo*” – Find all elements that have an ID that begins with foo.
“div{color*=red}” – Find all divs whose style color property contains the color red.

Obviously there is some disagreement as to if adding in new selectors is useful – I say that it is (it empowers the user to create the selectors that best suit their use cases). But, again, while MooTools is extensible – it is so for a limited subset of functionality. The extensibility requirements for Prototype, Dojo, YUI, and jQuery was much higher, so Sizzle was written accordingly.

The syntax may not be to your liking but the fact remains.

This statement is too weird. What fact? That Mootools can’t implement something that looks so… uh, I dunno.. “unnatural”?

So what if Mootools can’t do a “div{color=red}”? As Chris showed us, it’s fully capable of doing a “div:color(red)”–which I assume is exactly the same thing, but somehow looks more like native selectors and, in my vote, is certainly more appealing syntax-wise.

Please remember that syntax has nothing to do with how extensible Mootools or Sizzle is. Suppose the Mootools team decides to allow something like “div:c:o:l:o:r:{&r&e&d}” which has the same capabilities as your example (God I hope not). Would it be justifiable if Val told you that Mootools is more extensible than Sizzle just because it can do that, even if “the syntax may not be to your liking”? I don’t think so.

Don’t pass judgement solely on syntax, because whatever syntax the engine uses, it’s whether or not it could correctly parse the DOM that matters. And Mootools has already shown that–it just so happens that Mootools prefers code that actually looks good.

So let’s get back on what really matters: whether or not Sizzle really outperforms Mootools.