My selector engine is probably not so popular but it also implements a “match()” method based on CSS selectors compiled to Javascript functions which are then cached for the lifespan of the page. With time it would be clear that this is the most needed method; “select()” and “$$” are the past…and made our life difficult.

Many of the libraries still do not realize a “document-order” problem exists !!!

I respect the decision of the Mootools library, everybody love his way of doing things and want to keep their brand on it. To really share knowledge it is better to pass the information and let people see if it is worth introducing it in their project or skip it.

Everybody made his piece of work in this area and improved the general feeling.

Peace && Love

–
Diego

* CSS selectors are, by and large, all about as fast as the next now. There’s not much benefit to be had as far as speed is concerned.

While I may agree that selectors aren’t going to get much faster – the thing that is changing is the standardization of those selectors. This comes in two forms:
1) From standards bodies, like the W3C, with new methods (for example, querySelectorAll). If the libraries collaborate on a single engine it becomes fundamentally much easier for these new methods to come into being and propagate. It’s taking far too long for querySelectorAll to reach all of the current libraries – it should be happening much faster.

2) In custom selectors. There is no standardization on custom CSS selectors that libraries have. For example – there is the common custom selector [attr!=value]. What does this mean? Is it equivalent to :not([attr=value])? If that’s the case then it’ll match elements that don’t even have the attribute to begin with. Maybe it should be equivalent to [attr]:not([attr=value]). But, again, that’s not standardized anywhere. Having a unified engine allows us to standardize this in one place with a de facto implementation.

Frankly, not using Sizzle will mean that MooTools will always be playing a game of catch-up. Right now jQuery, Prototype, Dojo, and YUI are all looking at using the library – that only leaves one odd library out. I’m not attempting to put undue pressure on your team – it’s absolutely your decision – but you’ll definitely be in a position, if all the libraries use Sizzle, of constantly trying to catch-up to what is implemented in the de facto implementation.

* Sizzle caches selector results, which we could add to MooTools if we liked and we might, but perhaps this isn’t something everyone wants.

That’s something that we’ve been discussing amongst the different implementers. I see no problem with this piece of code being made optional.

* The MooTools coding philosophy is definitely set on having extensible code. Anyone can author custom selectors for the MooTools selector engine and the code in the engine is very clean and understandable to any MooTools user. We’d loose some of this if we moved to Sizzle.

This is the point that I’m most confused about. I will put money down, right now, that Sizzle is more extensible than any other CSS selector engine in any of the major libraries – MooTools included. jQuery selectors have been, traditionally, very extensible but I went far beyond that with Sizzle’s implementation and you can extend any selector in virtually any direction. If there are any specific extension concerns I’d love to address them but as far as I know there really aren’t any.

* There’s something to be said about autonomy. By having its own selector engine, MooTools can add functionality and manage its own needs.

You can absolutely add your own functionality to Sizzle – in fact a number of libraries are already doing it. For example jQuery has :hidden and :visible – but keeps them within its engine – they are not a part of Sizzle. Both Prototype and MochiKit are looking to do this, as well. That’s the beauty of the extensibility here. Such an extensible architecture means that you’ll be able to add your snap-in your own functionality.

* While adding Sizzle might be a nice gesture to the community, illustrating that we can all get along together, it may not offer any other big benefits (if you don’t consider any of the Pros above big benefits).

I’m not sure what is being referred to here. It’s important to note that it’s not just illustrating that we can get along together – it’s actually getting along together. A lot can be said for standardization. If there wasn’t some form of standardization between browser vendords, for example, we’d be in a much rougher place right now.

* One could argue that healthy competition is the reason we have fast CSS engines like Sizzle in the first place. If we all consolidate then maybe that innovation slacks off. One could counter that by saying that selector engines are so fast now that it’s really quite negligible and that any likely speed increase won’t come through further iteration on the JavaScript.

Two points:
1) You’re assuming that the only driving force of performance improvements is a specific outside force (such as another implementation). But you’re forgetting the biggest outside force of all: The users. In the jQuery project we’ve been making constant performance improvements to a variety of methods and components – because it’ll make the code faster for the users – NOT because there’s some 3rd party test suite that demands we have faster numbers. With so many minds at the table (all the major libraries) it’ll mean that this library will be in front of the majority of JavaScript users, in one way or another. It will be compelled to become faster.

2) While the competition has been good, it also has its ugly side. For example, not a single major JavaScript library implements document-order multiple selectors (e.g. returning “h1, h2, h3″ in the order in which they’re in the document – not all h1s followed by all h2s, etc.). No library does this because they would get instantly decimated on SlickSpeed. It’s going to be really important, going forward, that we start to match the published specifications (Selectors API) more closely, otherwise we are going to confuse users and break sites. Competition certainly hasn’t helped libraries to progress in this nature.