Sizzle Power in MooTools?

Wednesday, December 3rd, 2008 @ 8:18 pm | filed under: 'Industry' News, MooTools, Optimization

There’s a lovely post on Ajaxian today that the Dojo community is now voting on whether or not to swap out their own selector engine for Sizzle, Jon Resig’s CSS selector engine. Several other frameworks are considering doing the same thing. jQuery is using it already of course, but Prototype, MochiKit and others are all looking into it.

One the one hand, it kind of makes sense for frameworks to work together for these types of things. Why invent the same wheel over and over again? What about event management? Garbage collection? Why not consolidate a lot of this stuff?

As I’ve written previously, I think that frameworks are really only different from each other at the core and at the edges. That is, the way they do things at their most fundamental and abstract levels (like inheritance management and whether or not the extend JavaScript’s native objects – that sort of thing) and also the interface – the actual syntax they provide. But CSS selectors? Who cares about that? So long as the selectors use the CSS3 standards (perhaps with a few extra ones thrown in for good measure) the interface is the same, right? I mean, jQuery(‘div.foo’) vs $$(‘div.foo’) – the interface – what those methods ($$ and jQuery) return is what matters – who cares what the engine is that finds all the divs, right?

This is middle-ware. Sure, a year or two ago, the selector engines in frameworks were very different and some where far faster than their counterparts. But the MooTools team released Slickspeed and set off an arms race for selector engines. This competition was really good for everyone and is the reason that almost all the frameworks are so fast now. Why keep hacking at this problem if it’s basically solved. The only way that selectors are going to get fasters is if the browser developers continue to optimize the JavaScript engines.

So, as I see it, here are the pros and cons of swapping out the MooTools’ selector engine for Sizzle.

Pros

  • MooTools benefits from development contributed by all the other framework authors. Someone on the Dojo team figures out how to do something faster, and whammo, MooTools gets it, too. The obverse is true as well – MooTools can contribute to the speed and stability of other frameworks in the same way.
  • It means fewer bugs that the MooTools developers have to squash. When new browsers show up that introduce new capabilities, core the developers don’t have to drop everything to rework things.
  • It sets a precedent for the notion that the framework teams out there (including the MooTools team) don’t have to write everything themselves. Let’s focus on what makes our frameworks different and delegate the things that make them similar.
  • It makes it easier to move from one framework to another. Custom selectors and the like are available to all frameworks.
  • More clout can be had with the browser vendors if all the frameworks are using the same standard.
  • It would show that the frameworks can actually agree on something for a change and that this isn’t a competition.

Cons

  • 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.
  • Sizzle caches selector results, which we could add to MooTools if we liked and we might, but perhaps this isn’t something everyone wants.
  • 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. I have since been corrected here: Sizzle is very extensible.
  • There’s something to be said about autonomy. By having its own selector engine, MooTools can add functionality and manage its own needs.
  • 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).
  • 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.

Are there other pros and cons I haven’t thought of? I feel like I’m missing something, I dunno.

What are your thoughts as a MooTools user (if you are one)? Does this even matter to you? Do you have a preference? Would it make you happy to see MooTools adopt this standard bit of code or would you rather see MooTools maintain its own query engine?

Do tell.

I’ve posted a followup to this post that responds to some of the comments left here and elsewhere on the net.

No TweetBacks yet. (Be the first to Tweet this post)

9 Responses to “Sizzle Power in MooTools?”

  1. Aaron N. Says:

    There are some good replies to this over in the Google Group:
    http://groups.google.com/group/mootools-users/t/7396f0f8a17fd856

  2. ejohn.org/ Says:

    Just to reply to – and clarify – you ‘Con’ points:

    * 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.

  3. Implement Other Selector Engines (e.g. Sizzle or Peppy) into MooTools? | Garrick Cheung Says:

    [...] a selector engine instead of using their own. Apparently I was not alone in this thought as Aaron Newton has posted his thoughts and pros/cons. Here’s my two [...]

  4. Dojo’s Dylan Schiemann and jQuery’s John Resig On My Sizzle Post » Clientcide (Formerly CNET’s Clientside) Says:

    [...] on my previous post, John Resig wrote a lengthy response to my post. I’m going to quote it and respond to it here so I can insert my comments after his various [...]

  5. No Sizzle For Moo » Clientcide (Formerly CNET’s Clientside) Says:

    [...] MooTools dev team discussed the whole sizzle thing at great length over the past few days. I posted about it quite a bit and there was a lot of talk on the Google Group for MooTools users. I’ll [...]

  6. Sizzled off by MooTools | Read.WhoCouldDiz.Be Says:

    [...] made a public statement on the project’s blog. Even Aaron Newton, former CNET developer, brought a few pros and cons around the new CSS selector [...]

  7. diego Says:

    John,
    my NWMatcher is not a major library, but it implements “document-order” multiple selectors and I don’t feel decimated by speed I believe many others feel decimated…

    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

  8. MooTools: No Sizzle | Garrick Cheung Says:

    [...] the beginning, before Valerio posted about Sizzle. Aaron Newton posted about pros/cons of MooTools implementing Sizzle, followed by another post, “Dojo’s Dylan Schiemann and jQuery’s John Resig On My Sizzle [...]

  9. Henrik Lindqvist Says:

    The whole point of creating “toolkits” is to promote code reuse within it. So why relying on others to implement such a vital part. And writing a good selector engine is quite trivial. Look at the source for our selector implementation. It’s both smaller and faster than most.