There's so much of this that's just factually incorrect it's really hard to give the weight of the article any credibility.
To start, "Dojo" != "The Dojo Foundation". The foundation is a nonprofit (US 501c6, as it happens) entity that exists to hold open source IP -- usually web related -- in a neutral place. "Dojo" is a JavaScript web framework; its IP is held by the Dojo Foundation.
In other words, Dojo : Dojo Foundation :: Apache : Apache Foundation (except that to Dojo Foundation has far fewer requirements on member projects than the ASF). If I want to submit code to CounchDB, it doesn't have to work its way through the Apache web server contribution process. If I want to contribute to Sizzle, the Dojo contributors have no bearing on its acceptance.
Second, Sizzle has an extremely permissive license. Moo (or any other toolkit) can pick and choose how to participate, at any level from just poaching a good idea or three to full contributor/committer status (merit willing, I'd assume). They can even fork if need be. The fact that a major contributor to an open source project seems to completely miss the basic tenant of open source is scary and shocking.
Finally, this argument against the "centralization" of code is... well, again, it's counter to the entire spirit of open source. The ramifications of this argument are intensely scary. I can use of the dozens of languages on my laptop to parse XML using libxml2, and I don't have to worry about each language having subtle differences.
I could go on and on with examples like this; the fact is the code reuse, and the separation of pieces into libraries is part of what makes open source so much more productive than the alternative.
If MooTools doesn't like Sizzle for technical reasons that's totally fine, but arguing against code reuse appalls me.
It sounds like jQuery's CSS selector engine prior to Sizzle wasn't all that good either. It's Sizzle that's the new code here; John Resig could've easily reused one of the selector engines already available instead of implementing Sizzle. Which now sounds like it's not that much of an improvement anyway or at least has a poorly-written benchmark suite. Going up to another project and asking them to use your new code is, in this case anyway, kind of rude.
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. In terms of submitting patches, in terms of philosophy, and in terms of a community's familiarity with the code. These are all legitimate grounds to oppose code reuse in open-source projects, which cannot be the right solution, 100% of the time, because result would be one JavaScript framework, one programming language, one browser, and one Linux distribution.
> "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.
Use what performs the best. If that's Sizzle, fine; if not, seriously consider whether it remains in your library's best interest to use an inferior library when a better open source one could be used instead. If problems arise, you could always fork.
Diversity is a waste of time in this case. It's better to work on this "centralized" piece of code and create new forks based on it since the code is a damned good starting point. Don't the MooTools people have more important shite to work on anyhow rather than solving a solved problem?
The point is, Sizzle doesn't solve a problem for them. John Resig suggested to -replace- their CSS selector engine with Sizzle, not to use Sizzle in place of building their own.
You don't think ongoing performance issues and bug fixing are problems? If the MooTools selector engine were entirely bug free (I'm not claiming that it's full of bugs, just that without knowledge to the contrary I'm going to assume that it's like most other software projects and has at least one or two) and as fast as Sizzle, then yes, changing engines would be more work for no obvious benefits.
However, if they can get measurable performance improvements and increase the number of eyeballs on the bugs on that one portion of their code, then that seems like a win to me. There are plenty of other reasons why they still might not want to integrate Sizzle, but this one doesn't strike me as compelling.
My post was a rebuttal to onmouse's insinuation that MooTools didn't already have a mature, fast, & functioning CSS selector. Valerio's post quite clearly stated that, at the time, there wasn't a measurable performance improvement. Regardless of his misunderstandings about the contribution process, he wasn't ready to trade his team's control and design philosophy for dubious performance gains. That seems perfectly reasonable to me.
To start, "Dojo" != "The Dojo Foundation". The foundation is a nonprofit (US 501c6, as it happens) entity that exists to hold open source IP -- usually web related -- in a neutral place. "Dojo" is a JavaScript web framework; its IP is held by the Dojo Foundation.
In other words, Dojo : Dojo Foundation :: Apache : Apache Foundation (except that to Dojo Foundation has far fewer requirements on member projects than the ASF). If I want to submit code to CounchDB, it doesn't have to work its way through the Apache web server contribution process. If I want to contribute to Sizzle, the Dojo contributors have no bearing on its acceptance.
Second, Sizzle has an extremely permissive license. Moo (or any other toolkit) can pick and choose how to participate, at any level from just poaching a good idea or three to full contributor/committer status (merit willing, I'd assume). They can even fork if need be. The fact that a major contributor to an open source project seems to completely miss the basic tenant of open source is scary and shocking.
Finally, this argument against the "centralization" of code is... well, again, it's counter to the entire spirit of open source. The ramifications of this argument are intensely scary. I can use of the dozens of languages on my laptop to parse XML using libxml2, and I don't have to worry about each language having subtle differences.
I could go on and on with examples like this; the fact is the code reuse, and the separation of pieces into libraries is part of what makes open source so much more productive than the alternative.
If MooTools doesn't like Sizzle for technical reasons that's totally fine, but arguing against code reuse appalls me.