Sizzle (Against the centralization of open source)

> "It sounds like jQuery's CSS selector engine prior to Sizzle wasn't all that good either."

jQuery's old selector engine was (and is) faster than MooTools - especially so for selectors that developers actually use: http://docs.jquery.com/Release:jQuery_1.3#Sizzle_Selector_En...

> "John Resig could've easily reused one of the selector engines already available instead of implementing Sizzle."

No, we really couldn't have. All of the major JavaScript libraries have their own engines that depend on their own stacks. They use their own helper functions, internal coding styles, etc. - making them virtually impossible to cleanly extract and insert elsewhere. Sizzle is a "clean" code base. Not only was it written from scratch to be IP clean but it also has no dependencies on any other libraries, making it super-simple to deploy.

> "Which now sounds like it's not that much of an improvement anyway or at least has a poorly-written benchmark suite."

The post by Valerio is quite dated - it was written in December of last year after which Sizzle underwent a number of revisions, getting it ready for its final release. Namely their two major concerns were both addressed: That caching was being used to inflate performance numbers (query caching is no longer used in Sizzle) and that Sizzle was unfairly performing fast because it hadn't yet been integrated into a 'host' library (it has been integrated into jQuery and is still provably faster).

Sizzle (at the time of its inclusion in jQuery 1.3) was 49% faster than jQuery's previous engine - over 2x faster than MooTools' engine.

> "Going up to another project and asking them to use your new code is, in this case anyway, kind of rude."

Uhhh... I didn't? MochiKit, TinyMCE, Prototype, Yahoo UI, and Dojo all contacted me to discuss integrating it into their libraries (it should be noted that this isn't just a "Dojo and jQuery" thing - it's much larger than that). I extended the courtesy to MooTools and they opted not to participate - which is their prerogative.

> "It's most likely that John Resig wrote a new engine for the same reasons MooTools won't adopt Sizzle: the barrier to changing another group's code is much higher than changing your own."

Absolutely. Of course, to do this previously would've required a complete fork of an existing project (such as just forking jQuery's selector engine). Sizzle is designed to make it dead-simple to integrate. Since multiple libraries are all working to integrate the library it's a given that the codeb ase will be optimized as best as possible with no extraneous code and with a no-fork-required integration route.

> "In terms of submitting patches, in terms of philosophy, and in terms of a community's familiarity with the code."

Well, in terms of submitting patches - it's simple, Sizzle uses Git (on Github), so does MooTools. There's not much in the way of philosophy regarding a selector engine - this is pretty low level code. I think everyone can agree that they want the code to: 1) Run fast 2) Be extensible 3) Fix browser bugs. In terms of familiarity - this is once place where MooTools would've been able to see a huge benefit - they could've increased the number of people who could send in patches to their selector engine from "a handful" to "all of the major JavaScript library authors and developers" by having a unified code base.

> "because [the] result would be one JavaScript framework"

Nothing of the sort. Sizzle isn't replacing a full JavaScript library - it's one cog in the engine. It's a cog that is in every single engine and has to be designed in a very specific manner in order to run optimally. Standardizing on this cog doesn't require that the car look like a yugo - it just means that all cars get the best possible experience with the least amount of effort.