Sizzle

Written By Valerio Proietti, on Thursday, December 4th 2008, 11:34pm

During the last couple of days, there has been a discussion in various places about JavaScript frameworks implementing Sizzle, the new CSS selector engine by John Resig, which is allegedly the fastest.

Resig wrote Tom an email, saying that he would be pleased if MooTools joined the other frameworks by implementing Sizzle in its codebase, replacing our own selectors engine. I don’t really know how many frameworks are actually thinking of using Sizzle in place of their own selectors code, as the only source I can find for this is Ajaxian.

Their information about Dojo wasn’t correct, so I’m assuming that information about other frameworks is incorrect as well. I do know that Dojo is considering including Sizzle as part of the Dojo foundation, based on an email Dylan Schiemann wrote to Aaron Newton. As I understand it, Sizzle would become a Dojo Foundation project, with the ultimate goal of including it into Dojo Toolkit. They have this idea of having the major framework developers all contribute to a unified CSS selector engine.

Now that you know the general picture, let me explain why this is a bad idea not only for MooTools, but for any framework other than Dojo and jQuery.

There are several reasons why a project like MooTools would never include a third party library like Sizzle in its codebase. First of all, we already have a very fast, very manageable and solid CSS selector engine in place. I worked on it a lot, I know how it works, and I know that if it ever needs a fix, every MooTools collaborator can just git it and fix it, right away. Every Mootools collaborator knows how MooTools works, what our code practices are, and how to submit either a patch (if they don’t have Git credentials), or patching the code themselves.

With Sizzle, I would have to submit a patch to the Dojo codebase, which would have to be passed through Dojo. This leaves the possibility that the patch could be rejected, leaving us with a part of our library that doesn’t fit with our core philosophies.

It is largely a matter of code itself. MooTools has its own very strict code rules and conventions. For example, everyone working on MooTools knows that if they have to detect Explorer, they need to use Browser.Engine.trident, everywhere. If a developer doesn’t do that, he would probably be yelled at by myself. By including a standalone library like Sizzle, we would be breaking our own rules. MooTools does a great deal of work by abstracting common functionality and reusing these abstraction everywhere, for both ease of update and code readability. By including a standalone library like Sizzle, we would be breaking this paradigm that has worked so well for us so far. But most of all, we would be breaking the very essence of MooTools, being one single entity, perfectly balanced and in harmony with all of its parts.

Sizzle itself is well written, don’t get me wrong, but I honestly don’t think it’s any better that what we currently have. First, Sizzle is a very big script in size compared to our selectors engine.

Second, it (unintentionally) highlights a shortcoming in SlickSpeed by caching every expression’s results. John has a speed folder in his Sizzle GitHub repository, where he is comparing a selectors engine to real-world frameworks. SlickSpeed runs every expression five times, recording the median result. Since Sizzle caches the results, Sizzle results will always come out five times faster than anything else, assuming the code is as efficient as every other framework’s.

Third, as some of you might already know, MooTools post-processes every node resulting from any query. This tends to make things slower. Sizzle however is a pure engine, therefore makes no post-processing at all. This results in a very unfair comparison.

In an effort to test the true efficiency of our CSS selectors engines, I have made a modification to SlickSpeed, so that it runs every test only once, and a couple of modifications to the MooTools code. This special testing version of MooTools no longer “extends” the resulting nodes (I did that by simply adding a method that passes an optional parameter to the default function getElements, as I cannot pass parameters using SlickSpeed), and it uses querySelectorAll where available, just like Sizzle does. This way we can have a true comparison between engines, instead of frameworks and engines.

Feel free to test my results in every browser available to you. As you can see, the Sizzle engine is slower in many browsers.

Even assuming Sizzle were faster than MooTools in every test, it would be unwise to adopt it.

The Dojo Foundation and jQuery have it easy. The Dojo people can just work on their own code repositories, where everyone knows what to do and how to contribute. It’s basically the same thing for jQuery: Sizzle is copyrighted by John Resig. He will always have a way to add/remove/modify whatever he pleases. Us outsiders, however, won’t have it as pretty. We would have to gain the approval of the Sizzle project before making changes, limiting the power we have over our own codebase. As with any project, there is always a chance that a patch that we submit won’t be accepted. In that case, we’re stuck with code we don’t like.

This centralization of code would create a dangerous precedent, eliminating competition in the marketplace and choices for developers who rely on frameworks. Quoting Wikipedia:

[A] monopoly exists when a specific individual or enterprise has sufficient control over a particular product or service to determine significantly the terms on which other individuals shall have access to it.

It is often argued that monopolies tend to become less efficient and innovative over time, becoming “complacent giants”, because they do not have to be efficient or innovative to compete in the marketplace. Sometimes this very loss of psychology efficiency can raise a potential competitor’s value enough to overcome market entry barriers, or provide incentive for research and investment into new alternatives.

I’m not saying that John Resig seeks a monopoly over CSS selector engines, but that’s sure what it looks like. Competition and innovation will stop if everyone uses the same piece of code. Yes, competition and innovation.

Sooner or later, it will become too cumbersome trying to make Sizzle, or any other “shared component” fit our selfish, OCD-driven developer needs. No sane contributor will be eager to take the extra steps to contribute to different parts of our libraries, and in the end we’ll have contributors completely ignoring the selector side of it. Personally, I would never ever take my developers through the process of learning two different sets of project guidelines just because they want to contribute to the selector engine and make modifications.

As I’ve said, MooTools developers know MooTools stuff. That’s what MooTools is all about: MooTools stuff. This is the way it should be for every other framework, otherwise, it’s kinda pointless having your own. Unifying portions of frameworks would be the end of independent innovation, and we would become reliant on John and Dojo to make it better.

Or we could fork it, which would negate any proposed benefits, like having all developers of all frameworks work on a common piece of code.

If MooTools were allowed to submit any code which we wanted, we would have to assume that the same would be true of all other framework projects adopting Sizzle. Without any serious form of control, it would soon become a monster script that fits nobody’s needs.

Citing a bold sentence in this Ajaxian article:

It’s very likely that Sizzle will eventually expand into other areas of JavaScript libraries (such as DOM manipulation and event binding).

Let’s face it: every selector engine, every part of our libraries has benefited from the others. Where they diverge is not an indicator of which framework is superior to another. Rather, they are differences in philosophy. If everyone were to use the same, shared codebase, these awesome open source contributions and general advancements will stop, and users wouldn’t be able to choose the approach which works best for them. I don’t want to see that happening.

The very reason we have many JavaScript frameworks is because we want to do the same things, differently. Each one has its own way to code, its own way of solving problems. By including something that’s not MooTools in MooTools, we would make MooTools be less MooTools (and more jQuery, in this case).

So, if using one shared selector engine is ok, where do we draw the line? Is it ok to use a shared DOM manipulation library, or a shared event library? What makes our framework ours? If we start replacing core parts by outsourcing them to Dojo, our frameworks will just be a dull layer for code we didn’t even write, and we will lose credibility.

Why use a layer when I can just use the real deal? Why would I use MooTools, if it’s just a layer for Dojo or jQuery code? Don’t even try and justify that it’s not, because the code would be on Dojo servers, administered by Dojo foundation rules. Its Dojo’s. We at MooTools prefer MooTools code, by MooTools coding standards and rules. And I’d be surprised if many frameworks are willing to give this all away for nothing.

45 Responses to “Sizzle”

  1. Kit Grose says:

    While I agree with the point of this article, and I’m happy to have a MooTools-official response to the Ajaxian post, I’d like to know; why doesn’t MooTools cache expression results (as Sizzle does to get an effective 5x speed increase); I know selector queries are very likely to be run over the same DOM tree looking for the same nodes quite regularly in production code, or at the very least, subsets of a query (e.g. $$(‘.class1 .class2’) and then later in the page $$(‘.class1 .class3’)).

    Is it just something to do with the test? Or a specific decision made for performance/memory reasons?

  2. Julio Capote says:

    Right on. Reinforces my choice in js frameworks.

  3. Thomas Aylott says:

    I am Thomas Aylott, and I approve this message. Oh, and tacos rule.

  4. Mourner says:

    I totally agree with all your points, Valerio. I really wouldn’t want Mootools selector engine to be replaced by Sizzle because it’s absolutely awesome and besides I know how much such integration may suck from my own experience (I’m a developer of a lightweight mapping framework).

  5. Luis Merino says:

    @Kit Grose: I presume it’s pretty obvious that caching makes sense when you do not run every selector, just only once. But the benefit MooTools and its paradigm would get from cache shouldn’t be a real deal, and I’d say sometimes counter productive. @Thomas Aylott: Gee, I’ll really sleep well tonight man :D hah

  6. Christoph Pojer says:

    MooTools was always different, this makes it even more clear. At least someone stands up to fight. A unified Selector-Engine is not what we need, we just need standards compliant browser engines.

    With the addition of querySelector(All) to the major browsers selector engines can be dropped anyway in a few years (Depends on IE, as always).

  7. Pete B says:

    I think the hype around Sizzle is a little out of proportion when you consider that it’s advantages will soon be eliminated by the presence of querySelectorAll, already implemented in Webkit and shortly to be in Firefox.

    Totally agree that everyone using the same selector engine would be unethical, and anti-innovation, and a selector engine that does not even support the same things as querySelectorAll at that.

    Totally agree that it is nonsense that Mootools should adopt a different selector engine when it already has one that performs well and is integrated fully into the framework.

    It looks like a no-brainer. What’s the fuss? Why is John Resig so keen to get other frameworks to adopt sizzle (if he really is writing letters)? It seems to me a little egotistical.

  8. Andy Kernahan says:

    I am in complete agreement; relying on a third party component for a core aspect of Mootools is not the correct path.

  9. nfq says:

    I think Pete B sums it up well. I’ve had this nagging feeling for a while now, that John Resig doesn’t just care about great code, but always about wanting to be an internet legend. This sizzle debacle feels way to political, in that that the way John as gone about it feels like lobbying. Observing from the outside, it stinks and the reasons to not include Sizzle in MooTools, let alone any other framework, is a no-brainer. Valerio, much appreciate the clarity in the way you’ve presented the MooTools case!

  10. Radoslav Stankov says:

    I agree totally with you :) And one of the problems I see adopting Sizzle is that Sizzle is ‘naked’ and can’t take some advantages on some predefined methods in Mootools and also I don’t know how how extend() can be implemented in Sizzle’s code

  11. pagameba says:

    Well reasoned. I think it is important that Valerio took some significant effort to understand why Sizzle appeared so much faster and to create a fair comparison. Had a fair comparison still showed a substantial difference in favour of Sizzle, I’m sure he would have spent many hours trying to understand why and improving MooTools. Healthy competition drives innovation! For the record, Sizzle won 2 out of 3 test runs on my ffox3 (OS X) but the results were so close as to be meaningless.

  12. Chris says:

    I just ran your test and Sizzle was faster, making this statement an outright lie:

    “As you can see, the Sizzle engine is slower in every single browser.”

    Might want to reword that. It’s a little harsh to begin with.

  13. Carlos Rodriguez says:

    I am in complete agreement as well. I don’t know why any framework would want to include a third party component when they already have code in place to do the same. Cristoph makes an excellent point about not needed unified Selector Engines but instead needing “standards compliant browser engines”

  14. Olmo says:

    @Chris, come on give it a break. If you are desperate for proof try it with all the browsers. Try FFx 2. Try IE 6/7.

    Great article Kami. I share the same sentiments. Viva la resistance.

  15. Dylan says:

    This is Dylan from Dojo… I’d like to clear up some perhaps misconceptions, but also explain why we’re interested in this.

    1. Dojo was started with the goal of creating a great open source JS toolkit to stop reinventing the wheel. Obviously with the proliferation of toolkits, we failed in that goal overall :) (this goal was before the coining of the term Ajax), but we did reduce our personal reinvention significantly.

    2. We like working with others, and we work hard to respect IP issues (we make all code that’s part of Dojo be contributed under a CLA) so that people can use Dojo without fear of being sued because someone copied code not available under an open license.

    3. As a corollary to #1, when John mentioned Sizzle, we were skeptical, but we wanted to keep an open mind. In order to address #2, we asked where Sizzle was going to live, because copyright John, with no clear way to contribute, add patches, and contribute would not be ok for us, and would just lead us to forking anyways. Alex, Peter, and I from Dojo Toolkit, suggested this to John, and he said, ok, let’s see if we can make this work as a Dojo Foundation project. Basically in some ways this is my fault for “just asking”.

    4. Dojo Foundation is not the same as the Dojo Toolkit… think of the foundation as Apache with much more autonomy and very few rules. Sizzle will join the Dojo Foundation, and at the point in time at which Sizzle works well with Dojo, Dojo will adopt it.

    5. Selector engines are a commodity… frankly I have better things to do with my time than make Dojo’s selector engine better… it’s good enough now.

    6. querySelectorAll does make selector engines less relevant, but as you are quick to note, it doesn’t cover all possible extensions being conceived, and likely never will be enough for all toolkits. And we’re stuck with IE 6 and 7 for a while.

    7. Sharing code on this reduces our overall maintenance cost, and gets the best query selector engine devs working together… that’s useful, and still encourages competition (through what makes it into Sizzle, and your extensions).

    8. The code is going to still be open and licensed in a way that you can pretty much do whatever you want with it, including forking, applying more aggressive patches to it, etc.

    9. Having some consistency on things like this can help browser vendors more quickly implement the things we’re actually using, and optimize on performance around it.

    10. John Resig is not the devil, or trying to hijack JavaScript. Is he sometimes pompous or arrogant? Sure. Do any of us agree with everything he says? Absolutely not! Is he trying to become an internet legend? I think he already has achieved that status, whether it is deserved or not.

    11. Toolkits exist to fill in the gaps between browser releases… we can iterate faster than browsers can. They also exist to create APIs that we feel are personally better than what browsers give us. In many ways what we’re trying to do here (and I say we but really I’m just along for the ride) is come up with a standard and an implementation on that standard faster than browsers can. But we’re also trying to create APIs that are better than others, and this is where I see the MooTools resistance, which is a fair point and position.

    It amazes me how fiercely and aggressively we fight sometimes over something we give away for free! I met Tom at Adobe MAX and I think we got along pretty well. I think if we all met face to face, we’d probably get along pretty well (except for my dreadfully bad jokes perhaps), and would respect the work of each other even if we don’t always agree (which is a good thing).

    If I was part of the MooTools community (which I’m not), I would suggest:

    • taking a fair look at the work being done, and see if it makes sense to get involved whether you choose to use Sizzle or not. If Sizzle sucks compared to your code, then either ignore Sizzle or consider working with us… there’s really little to lose in my opinion
    • assume that in either case (using Sizzle or not), there are no nefarious goals, and that we’re acting genuinely
    • we should consider if there are places where Dojo and Moo could work together or collaborate on things independent of this.

    I’m easy to find if you want to email me… dylan at dojotoolkit dot org

  16. Tom Trenka says:

    “With Sizzle, I would have to submit a patch to the Dojo codebase, which would have to be passed through Dojo. This leaves the possibility that the patch could be rejected, leaving us with a part of our library that doesn’t fit with our core philosophies.” . Actually, this is not true at all. There’s a difference between the Dojo Foundation, and the Dojo Toolkit (though the naming makes it confusing). All the Dojo Foundation really is is a non-profit, like the Apache Foundation. If and when (since it looks pretty likely) Sizzle becomes a Dojo Foundation project, all it basically means is that it has the building weight of the Dojo Foundation behind it—which means you’re guaranteed a specific license and clean code history. . Even MooTools could become a Dojo Foundation project, if you wanted that legal backing—and that would mean nothing in terms of the Dojo Toolkit and MooTools merging. . Also, though I have not investigated yet, I think it’s pretty unlikely that John would willingly pull something like gaming SlickSpeed just to make it seem like his code is the fastest. . Otherwise, while I agree with some of your sentiment…I personally (i.e. none of the opinions expressed represent the Dojo Toolkit or its subsidiaries ;)) wish that the go-it-alone attitude I get from this post (and others you’ve written) wasn’t so strident. As Dion mentioned in that Ajaxian article, we started Dojo based on merging 3 JS toolkits (in terms of both code and ideas)—and we try to remain open.

  17. dc says:

    pagameba, Chris: not sure why your tests would be off. Ran three tests on FF3 and Mootools was 100ms faster in all three.

    I don’t see any reason adopting 3rd party code when the Mootools devs obviously know what they are doing. Mootools would lose credibility and respect if it were to adopt Sizzle. Kudos to Valerio for proving their own ability in a fair environment and sticking to their own beliefs and philosophies.

  18. Christoph Pojer says:

    I just wanted to add what I pointed out on #mootools already: It doesn’t make any sense to cache the results of a selector query. If you want to “cache” and reuse the result, put it in a variable yourself (like var els = $$(‘selector’) ). I do not see a reason why one would execute a selector on the same unchanged DOM-Tree. Internal selector caching brings more problems than it solves. Let alone the misuse for DOM unrelated selectors (like div:storage(test=blah) which is possibly in MooTools through extending the Selectors).

  19. keif says:

    When I ran the test on FF3 on OS X Sizzle was faster (but it also threw an error on one item, and we’re talking 5ms faster).

    Didn’t test it on the rest of the plethora of browsers, as I find the speed argument irrelevant at this level (we’re splitting hairs).

    Dylan’s response is very apt, and I agree with his summation - something that I’ve seen echoed from other moo users in the group/blog postings - look at sizzle, see if it’s an area we can take ideas from and incorporate into our code (at the very least).

    So, is Resig a dick in real life or what? He seems cocky online, but man, from his work with Sizzle I’m seeing him fry (ba da bum!)

  20. Léonie Flowers says:

    Here are my selenium test-results… (sizzle / mootools) FF2: (4 / 6) FF3: (7 / 3) IE6: (6 / 4) IE7: (3 / 7) IE8: (6 / 4) OP9.5: (4 / 6)

    result: there is no significant difference in speed. The difference was in most cases just some milliseconds… mootools never threw any errors, sizzle did ;-)

  21. Kevin Le says:

    I’m glad to hear your good decision of keeping Mootools pure. Sizzle will no doubt put pressure on Mootools when it expands in other areas and as a Mootools user, I hope Mootools will be reactive well and even proactive in some cases.

  22. Eugene Lazutkin says:

    Just out of curiosity I ran SlickSpeed Selector Tests on browsers installed on my computer (Ubuntu 8.10 64-bit). The first number is Sizzle, the second is “MooTools 1.2.1 with pure nodes returned”:

    Firefox 3.0.4: 222 227 Opera 9.62: 155 157 Midori 0.1.1 (WebKit): 14 20 CrossOver Chromium (Google Chrome/WebKit): 38 45

    Does it mean that Sizzle is faster than your offering? If it is, the difference is not big, which confirms the thesis that selector engines are commodities nowadays.

    To be fair it is worrisome that Sizzle on Firefox and Opera returned some kind of error for “p:nth-child(n)[class] > a”. I hope it’ll be addressed soon.

  23. Robert says:

    Quote: “As you can see, the Sizzle engine is slower in every single browser.”

    FF3 under Linux… Sizzle and your modified Mootools test are 50/50.

    So clearly your blanket statement above is only true for the tests that you performed on your own machine.

    Quote: “I’m not saying that John Resig seeks a monopoly over CSS selector engines, but that’s sure what it looks like.”

    Sure does seem like you just said that :)

  24. David Walsh says:

    If there’s no SIGNIFICANT speed difference, I don’t see any reason to make a move. Using Sizzle because others are considering it is equivalent to “just cuz.”

    Plus, if Sizzle somehow does become much faster than Moo, Moo can adopt then. No reason to do so now.

  25. Graham Bradley says:

    I’m glad you altered the SlickSpeed code to run these comparisons, as otherwise the results are wildly inaccurate. Again I’m seeing that Sizzle is marginally faster, but I’m actually surprised there’s so much furore over a few milliseconds.

  26. Daniel Buchner says:

    Oh Snap! That slickspeed retool really shed some light on this. I would love to have the ability to not extend if it is a ‘light’ option to enable. Such an option sould be useful for generating selector maps and such for scraping and other DOM tree remembrance tools where an accurate path is all that is needed…

    Thank Valerio, you hardly ever voice an opinion in open address, but when you do, it is usually pretty good stuff!

    BTW, checkout CityCrawler.com in about 2 months, you might just think the use of moo is pretty cool!

  27. Paul Hanlon says:

    I can think of one place where it would be a good idea for the libraries to gather around one selector engine - mashups. There wouldn’t be any more confusion over $, while at the same time each library would keep its different way of manipulating the result. The selector engine is the commodity side of a library, and as has already been pointed out, will be replaced by querySelector(All) once Microsoft finally adopt it. I think the monopolist jibe was a bit strong, given the way that it is being shared, all of John Resigs code to date has been released under MIT/GPL, which means you can do anything you like with it, as long as you keep the copyright notice, which isn’t much to ask. Paul.

  28. frank kootte says:

    I think the fact that the 5x speed increase claimed by Sizzle is in fact nothing more than a hoax. When running slickspeed with Sizzle multiple times it indeed shows blazing fast results, but this is purely based on the fact that John uses a cache of result sets and retrieves results from it when a css selector is passed for the x-Th ( x!=1 ) time. However, nowadays dynamic web 2.x pages modify the dom constantly and therefore destroying the use of this cache completely as is is cleared on any element / attribute modification.

  29. Guillermo Rauch says:

    “Comes in at roughly 4x faster in Firefox 3, 3x faster in Opera 9, 1.5x faster in Safari 3 than the other major JavaScript libraries” Funny

  30. Josh Powell says:

    I think the point of Sizzle and Resig contacting mootools isnt that mootools has an inferior CSS selector engine, but that the selector engines themselves have become a commodity. Why redevelop the same thing a different way with every js library only to get par performance, when everyone can use a standard and innovate in other areas instead? The slickspeed tests only prove the point… both selector engines give the same performance. So why go through all of the overhead of maintaining your own when there is an open source version that does the exact same thing?

    The fact that CSS selector engines are commoditizing is a reason to consolidate. There isnt going to be more innovation and creativity with them if it is a commodity. If all of the performance possible has been eked out already in the various engines then there is little reason to have different ones. Why have to learn little quirky differences between the libraries when switching between them? It would smooth learning a new library.

    Right now I can write in Prototype and jQuery and have been thinking about learning mootools as well. It would be nice if all three used the same selector engine so that when switching between them I wouldn’t have to remember which one used which selectors. And if it is commoditized and there is no perceptible performance difference between mootools and Sizzle and prototype, why not everyone standardize on one model?

    A ‘monopoly’ is perfect in this circumstance because it is a commodity and no leaps forwards are expected anymore. If innovation and creativity on the selector engine stopped today… we’d be fine. If that isn’t true, then the selector engine is not yet a commodity.

    So far, Resig is the only one I can tell that has offered up a Selector engine to have everyone use. it’s already gained traction towards being adopted by Dojo and Prototype (at least thats the rumors I’ve been reading), otherwise I’d be all for adopting mootools selector engine, or prototypes, or whoever. it doesn’t matter, it’s a commodity, remember?

  31. Peter says:

    Olmo: “Viva la resistance”? You still think it’s a war, don’t you?

    And I’m touching this because of unhealthy state of today’s JavaScript libraries’ communities. We just can’t get along, thinking it’s a football match or a war.

    It’s false, everybody benefits from new code and new discussions!

  32. Zach Leatherman says:

    Everyone seems to so quickly forget that the reason we have so many competing JavaScript frameworks now is NIH syndrome, which seems to be in full force here. This probably isn’t the most constructive comment, but I felt it needed to be said.

  33. nea says:

    The facts that Sizzle isn’t faster than MooTools selector and implementing it would make the whole package larger is enough of arguments for me. Benefiting from a common opensource libary? Oh please, give me one single example of such benefit. What innovation can you put into a CSS selector anyway? Make it faster? Yeah, we have seen that already. This whole thing takes more attention then it deserves IMHO.

  34. Josh Powell says:

    “Benefiting from a common opensource libary? Oh please, give me one single example of such benefit.”

    Um, ok. How about.. let’s see here, mootools?

  35. Diego Perini says:

    I agree with Peter. It is not a war…it is about making your user happy and deliver quality code.

    Everybody should fix their broken CSS selector implementations instead of playing kid games with numbers.

    Let’s face it, most libraries have partially “invented” and adapted their own specs…tweaked their benchmark up and down several times and even though are not faster in any area on selectors.

    The return result sets must be in the order the elements were encountered in the document. Look at both Safari and FF implementations in case you disagree.

    By not fixing this as a first point will make troublesome for developers to build reliable test units with the pains it will create. And everybody will have to trust these incorrect tests.

    It was the same with XPATH or at least there was a way to force that with an option. With the new Selector API it is not different.

    This is the reason everybody needs to redo their home work or just go with NWMatcher.

    I already suggested some tips to Sizzle that will make easy fixing at least the “document order” but if you believe I am trying to monopolize the world you could just skip that too…

    I can’t say I am a frequent visitor here, though the few times I was, I have found the same bad attitude with collaboration and exactly the same war with John Resig, is that to fill up your time or what ? Better using that time to fix your beloved selectors !

    — Diego

  36. Josh Powell says:

    ok, sorry for the sarcasm, but mootools is a perfect example of a common open source library that is used in multiple projects and everyone benefits from it that uses it. I’m quite shocked to hear someone who is a proponent of mootools, which I assume you are, speaking against open source libraries. I’m also pretty shocked at the level of hostility in these comments.

    “At least someone stands up to fight.” What fight? people collaborating is now a fight?

    “Totally agree that everyone using the same selector engine would be unethical.” Unethical? collaborating with people outside the mootools community is unethical?

    “that John Resig doesn’t just care about great code, but always about wanting to be an internet legend. ” Wow, just wow.

    “Why is John Resig so keen to get other frameworks to adopt sizzle (if he really is writing letters)? It seems to me a little egotistical.” Now, I don’t know John personally. But he’s done a lot of work that makes my life a lot easier. So, I might be a little biased here, but I don’t think trying to get people to work together and share a common code base is egotistical.

    “I agree totally with you :) And one of the problems I see adopting Sizzle is that Sizzle is ‘naked’ and can’t take some advantages on some predefined methods in Mootools and also I don’t know how how extend() can be implemented in Sizzle’s code” I’ll betcha 20 bucks that John would help figure it out if asked instead of attacked for asking if you wanted to collaborate.

    “I think it is important that Valerio took some significant effort to understand why Sizzle appeared so much faster and to create a fair comparison.” Fair? By cutting out Sizzle’s most significant advantage and testing against it? Look guys,

    var myVar = $(‘myId’);

    is caching. John just moved it into the library. and

    $(‘.myClass:nth-child(even)’).hide(); // lots more code in between $(‘.myClass:nth-child(even)’).show();

    is a lot more readable to me then

    var evenTableRowsFor3rdTable = $(‘.myClass:nth-child(even)’); evenTableRowsFor3rdTable.hide(); //lots more code between evenTableRowsFor3rdTable.show();

    “I just ran your test and Sizzle was faster, making this statement an outright lie:” Is it really necessary to be so confrontational and attack someone verbally? A lie? how about they were just incorrect and that on all of the systems they tested it on it was faster and they didn’t purposefully exclude any results that showed this statement to be false and you happened to find a different configuration where it was.

    “Viva la resistance.” resisting what? Working together with other libraries. Is mootools a pirate library? french revolution library?

    “Mootools would lose credibility and respect if it were to adopt Sizzle.”  ??? Wha? Why? Are you implying that people would think that MooTools is inferior because they worked with other people in the industry and adopted a consistent framework for a component of their library that is a commodity? Personally, I think there is a lot more credibility to lose in being the last hold out to not adopt a common framework unless there is a significant savings by not going with it.

    “I think the fact that the 5x speed increase claimed by Sizzle is in fact nothing more than a hoax.” Puffery perhaps, but I don’t think John was maliciously trying to fool anyone. I bet he does have the data to back it up.

    Honestly though people, while some good reasons were given to not adopt Sizzle and with well reasoned logic, there was a lot of unnecessary hating going on. As this is my first experience with the mootools community just let me say, it has been quite unpleasant and leaves me not really wanting to learn and use mootools if I’m going to have to be fighting with people instead of working with them.

  37. David Walsh says:

    @Josh Powell: While the Moo community does have a reputation for negativity, I can say from experience that I’ve seen just as much “hating” by users of other libraries.

  38. Harald ringvold says:

    I’m not that into javascript and javascriptframeworks, but I do try to keep myself updated. After reading up on the different opinions I seem to fall in the “sizzleside”. From reading this and the responses I do feel a little hesitation when it comes to learning/using Mootools. This only hurts Mootools and I hope they don’t take too much damage from it because it’s probably a very good framework which many will come to like. Well, that was kind of the thoughts I had on the subject. If its interesting jQuery is my framework of choice.

  39. nea says:

    @Josh: I obviously meant a common opensource »CSS selector libary for other frameworks like Sizzle«. I guess we are all using frameworks here and there, not only in JavaScript, that’s not the question. The question is, what Sizzle brings or can bring that MooTools already doesn’t have? There is little to none innovation that can be done is as limited task as CSS selector.

  40. Eugene Lazutkin says:

    My general impression of the rant and the subsequent “debate”: guys, check twice, if it is the NIH syndrome talking (I think it is). Having said that: it is up to mootools guys to accept/reject code, ideas, and define policies guiding the toolkit. Whatever their decision is, the rest should respect their wish. Somehow I think that mootools will be just fine with or without Sizzle and/or cooperation with others.

  41. Josh Powell says:

    @nea: “There is little to none innovation that can be done is as limited task as CSS selector.”

    That’s exactly the point. Since there is no more innovation to be had (because of all the innovative work the library developers have already put in), why roll your own? Do not the benefits of going with the standard outweigh the benefits of rolling your own? And even if you have already rolled your own, why not adopt a standard even if there are advantages to your own particular code. All the standards-based arguments apply here.

    Do you want to be like IE (we don’t need no stinking standards) or the rest of the browser community? (okay, cheap shot :) )

  42. kamicane says:

    @ Josh Powell: Your arguments make no sense.

    “ok, sorry for the sarcasm, but mootools is a perfect example of a common open source library that is used in multiple projects and everyone benefits from it that uses it.” MooTools is not a shared piece of code used in other javascript libraries. Maybe you should take a look at http://www.mootools.net

    “I’m quite shocked to hear someone who is a proponent of mootools, which I assume you are, speaking against open source libraries. ” This makes me just think you didnt read the article, so I wont even comment.

    “I’ll betcha 20 bucks that John would help figure it out if asked instead of attacked for asking if you wanted to collaborate.” True, but we dont care. its very well written in the article: we like our code best, and its more mantainable for us.

    “and $(‘.myClass:nth-child(even)’).hide(); // lots more code in between $(‘.myClass:nth-child(even)’).show(); is a lot more readable to me then var evenTableRowsFor3rdTable = $(‘.myClass:nth-child(even)’); evenTableRowsFor3rdTable.hide(); //lots more code between evenTableRowsFor3rdTable.show();” We have a very different concept of readability and code practices then.

    “Personally, I think there is a lot more credibility to lose in being the last hold out to not adopt a common framework unless there is a significant savings by not going with it.” I acknowledge your point of view, but for us is very different. If you didnt get it from the article itself, there is nothing much I can do to make you understand. We just disagree.

    “why roll your own?” Because we can do it better.

    “Do not the benefits of going with the standard outweigh the benefits of rolling your own? ” No.

    “And even if you have already rolled your own, why not adopt a standard even if there are advantages to your own particular code.” Because there are only disadvantages.

    “Do you want to be like IE” Explorer does a very different thing. He doesnt respect W3C standards. Both Sizzle and MooTools Do. But Firefox and Safari, for instance, both do too, and they use very different code. This benefits everyone, much more than if Firefox and Safari used the same Javascript engine. I think you’re missing the point of the article.

    However, I agree that there is a lot of hating going on in the comments (see, we agree on something). Be nicer everyone.

    I have a question for you Josh Powell: Did you even read the article? Because it surely seems that you’ve only read the comments.

  43. w00fz says:

    Josh Powell says: Since there is no more innovation to be had (because of all the innovative work the library developers have already put in), why roll your own?

    How can you say there is no more innovation to be had? :) What’s nice about innovation is that you cannot predict where is it going to go. Would you ever expect 10 years ago what direction would the Web have taken and what we’d have today? Sounds to me you’re hazarding a guess, which surely isn’t good for innovation, it’s just good for stopping it.

    Nice post Valerio, btw.

    • Djamil
  44. Josh Powell says:

    @kamicane: Telling someone their arguments make no sense probably isn’t the best way to make your case or deal with people. My arguments make perfect sense, unless you don’t want them to. You clearly don’t want them to from your open hostility.

    @David Walsh: I’ve never seen/experienced the kind of open hostility people like kamicane are showing coming from the jQuery community or the Prototype community. I’m sure there have been circumstances, but none directed at me.

    @kamicane: I read the article, you don’t need to act like a jerk and insult people. Seriously, all your doing is mimicking the behavior I was addressing in my comment. In that comment, I wasn’t addressing the blog, I was addressing the community responding to the blog. I responded to the blog in an earlier comment but am really more concerned over the communities response.

    By saying that MooTools is not a shared piece of code used in other js libraries, you are really splitting hairs. Plugins are developed for MooTools, they all share the MooTools base code. Everyone who uses MooTools in their development projects extends the MooTools base code for the functionality they need. I’m not going to refute your comments one by one, you’re probably smart enough to figure out what they mean if you want to, and if you don’t want to then no amount of explaining on my part is going to do it.

    @w00fz: I was addressing one particular argument above that was saying that all the selector libraries are just as good and further innovation unlikely, so why should MooTools adopt an open source version. To that I responded, that this is an argument to adopt it, instead of not adopting it.

    @ALL: It’s your library, not mine. Have fun, do what you want. FWIW, in the contest of library names, MooTools wins hands down.

  45. kamicane says:

    “you don’t need to act like a jerk and insult people.” “FWIW, in the contest of library names, MooTools wins hands down.”

    Shows me Its really time to close these comments. Thanks to all of you who expressed your opinion without trolling.