How Many Flavors of Linux Are There?
It’s hard to write about what you like about an open source project that that solves (or at least attempts to solve) a problem that other open source projects are also trying to solve (using different methods). It looks like you’re competing with each other, but really all that’s going on is that two groups of people share a problem and are the kind of people who enjoy solving that kind of problem and have their own specific ideas about how to do it. How many flavors of Linux are there?
I was encouraged when I read this article by Charles at doublerebel.com entitled “Class Inheritance and jQuery.” I was encouraged mostly by the tone. This is the first posted response (other than the comments) to a long post I wrote a few days ago that discussed a lot of topics, one of them being jQuery and its remarkable popularity.
When I wrote that post, I went out of my way to make the point that jQuery is different than MooTools, but not, in my view, either inferior or superior. Just different. It’s just a different group of motivated people solving a similar problem in a different way, and obviously they’re doing something right. I also expressed a sincere desire to not argue about which framework is better – we aren’t fighting each other here, we’re fighting the browsers.
Chuck’s post is great. I was waiting with some apprehension when I posted my thoughts for it to spark a rebuttal that maybe missed my point and instead followed the “framework war” path – which helps no one. But Chuck’s post is exactly the kind of discussion I want to have.
Part of that post discussed one of the things I like about MooTools – namely, it’s use of “class” based inheritance. These aren’t really classes in the formal sense; they’re still just JavaScript objects with properties. The thing that you can do with them is imbue them with properties of other objects and extend them into still more objects that inherit from them. This leads to the real point I was making about pattern based development.
Chuck writes:
jQuery gets a unfair bad rep for extensibility — the sheer popularity of jQuery means that a large number of users aren’t using jQuery to its full potential.
I develop with jQuery the same way Aaron develops with MooTools — when I see a pattern emerging, I create a plugin and extend jQuery. It’s simple to create your above example — just use jQuery.extend! (More detailed example here.)
And then he sets me straight about something I quoted from Richard Worth (jQuery contributor) presentation at the Ajax Experience:
He [Aaron] mentions to call a plugin method, the code would be:
“jQuery(domId).pluginName(”methodName”, [arg1, arg2]);
– I hope I have that right.”It can be that way, but with a properly designed plugin it’s as easy as:
$(domEl).plugin.method(arg1,arg2);
This is good to know, as the former syntax, to me, is a bit clunky (again, that’s a personal preference).
But the best part of his post is this bit:
I think Resig feels much the same way I do about how class-based design can often be overly descriptive, and a waste of bytes.
Which is one of my big points in my other post: it’s about personal preference. I really, really like using classes in my work and find that, while they take more bytes to write, they save bytes in how extensible and reusable they are. But Chuck doesn’t, and that’s totally cool.
In case my previous post didn’t make this clear, both jQuery and MooTools are fine solutions to DOM scripting (and the same can be said of Prototype, YUI, Dojo and others) and they each have their own ways of solving similar problems. I, personally, prefer to author my work in shallow, extensible classes, and what was a realization to me was that there’s nothing about jQuery that would prevent you from doing this. The fact that MooTools itself is written this way has trade offs, which is why choosing a framework is so much a matter of personal preference.
Follow @clientcide on twitter to get notified of new posts.
To follow me personally on twitter, follow @anutron.