Not too long ago announcements of two new selector engines came on the scene, Peppy by James Donaghue and Sizzle by John Resig. At the time I had a fleeting thought of how cool it would be if MooTools was as fast or faster than Peppy and Sizzle.
Yesterday, Ajaxian tells us that the Dojo Community will vote on whether they implement the Sizzle selector engine instead of using their own.
Just after reading that I thought whether MooTools would benefit from implementing 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 cents.
Aaron brings up very good pros and cons. I think we should not follow the trend and switch to Sizzle but instead take in what we can and be inspired to improve upon it. We should already be doing that. This would require our awesome MooTools dev team to be up-to-date, but aren\’t they continuously learning?
In this way, we can keep to the \’extensibility\’ philosophy. Besides, if we figure out an even better method, who is to say that other developers aren\’t looking at MooTools and taking from it what they deem better?
Lastly, why Sizzle and not Peppy? Last I checked, Peppy was beating out Sizzle on SlickSpeed. James recently took a stab at documentation for Peppy too.
At the end of the day, it all depends on what our MooTools dev team wants to do because, after all, MooTools was created for their use, and it\’s great if others can use it too.
P.S. Thanks to James Donaghue and John Resig on their awesome work!
I think if you look at the source of Peppy and Sizzle then it will be quite clear why Peppy isn’t something to consider 🙂
I don’t want to offend it but it’s not quite mature (yet), though it passes all test!
I read somewhere that Peppy was using some type of caching. So, in a complete dinamic page, this is useless and speed is not real.
fwiw, the Dojo vote strictly involves the adoption of the Sizzle project to the Dojo Foundation (which is a lot more than just “the Dojo Toolkit”). The motivation is the IP cleanliness, and licensing. It is not an issue of “should Moo adopt Sizzle, too?” … it is one of “Moo can use this code base because it is cleanly licensed and available”
@Javier: Sizzle caches the query results too but only if DOM mutation events are available. Peppy just followed Sizzle in this aspect. See at the bottom: http://jamesdonaghue.com/static/peppy/peppy.js
W3C specifications compliance is a very difficult thing to achieve.
Failing in the most obvious points is the only real thing these frameworks have in common.
A selector engines considered for inclusion in so many frameworks should at least be able to guarantee the result sets are “document ordered” in any case.
This is not what you get neither from Peppy nor from Sizzle, Mootools, YUI and any other popular framework.
You will say I am just an unknown trying to push his solution instead, but really I have been quite for two years I can keep quite for two years more.
My code was released in 2007 and I released it under MIT License for the exact same scope Sizzle had. Unfortunately it is not easy to convince developers and it requires some time until they realize they have to move.
You will find my “mwmatcher.js” on Google Code:
http://nwevents.googlecode.com/
it is released with a companion Event Manager that also handles delegates cross-browser, this was what pushed me write NWMatcher.
Strange enough everybody knows Peppy and not NWMatcher though, have to work on this a bit.
A new release of NWMatcher (v1.1) will be out in a few more days.
—
Diego
@Carl, Javier, phiggins
Thank you for your input.
@Diego
MWMatcher huh? I’ll definately take a look at this one. Thank you for sharing.
Javier,
caching is good, it especially very good if it is used for something that never changes. In NWMatcher I compile CSS selectors to Javascript functions and then I cache them indefinitely.
They are not going to change.
Caching of results sets is a different and more complex matter though and in NWMatcher I decided to give the developers the power to switch results caching ON and OFF or flush it as they see fit in their projects.
LlamaLab got a small and fast selector.
I use peppy in my framework and its quite great. I had no intention of writing my own selector engine and peppy came to save me right when I felt like I had no choice. I never thought Mr.Resig would detach sizzle from jquery, but I was wrong. Peppy does seem to be giving me different results some time but so far a quick look at sizzle and i cant even begin to understand how I’m going to integrate it. Sizzle’s selectors are far more advanced but it only took me a few hours to completely rework my framework for easy integration with Peppy. I’ll test it this week and post my findings.