

Sizzle (Against the centralization of open source) - teej
http://mootools.net/blog/2008/12/04/sizzle/#

======
jacobian
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.

~~~
shadytrees
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.

~~~
jeresig
To respond to some of your specific points:

> "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...](http://docs.jquery.com/Release:jQuery_1.3#Sizzle_Selector_Engine)

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

------
thenduks
It isn't even slightly surprising that the MooTools guys would react to Sizzle
this way.

In short (quoted from the article):

> If a developer doesn’t do [what I think he should do], he would probably be
> yelled at by myself.

That pretty much sums up the typical attitude of the MooTools community.

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

------
teej
I apologize for the editorialized title, but Valerio didn't give me much with
which to work.

------
mindaugas
Diversity is good.

~~~
omouse
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?

~~~
teej
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.

~~~
ionfish
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.

~~~
teej
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.

