4 ms·

Sizzle (Against the centralization of open source)

15 points by teej 18y ago

mindaugas 18y ago
Diversity is good.
- omouse 18y ago
  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 18y ago
    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 18y ago
      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 18y ago
        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.
teej 18y ago
I apologize for the editorialized title, but Valerio didn't give me much with which to work.
jacobian 18y ago
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 18y ago
  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.
mcav 18y ago
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.
thenduks 18y ago
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.

15 points by teej 18y ago

mindaugas 18y ago

Diversity is good.

omouse 18y ago
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 18y ago
  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 18y ago
    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 18y ago
      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.

teej 18y ago

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

jacobian 18y ago

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 18y ago
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.

mcav 18y ago

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.

thenduks 18y ago

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.