jquery vs mootools: my initial thoughts
Introduction
I’ve been using jQuery regularly for my new job now for about 3 weeks or so. I’ve used the selectors, event handling, short cuts/handlers, animations, plugins etc. Nothing too fancy, but in general, a descent exposure. I’d like to compare it with Mootools. And while I do rock a Mootools skin on my phone, I’m going to try and remain as objective as subjectively possible. I’m going to try and stay positive about the differences and give use-cases for using either.
Gut Reaction
jQuery is fast to learn, easy to use, and passes the ‘thinking’ to the framework. It allows you to do incredibly powerful client side stuff without knowing too much of the inner workings, worrying about being specific and explicit about your syntax or organization, and most importantly lets you get this stuff done quickly.
Mootools on the other hand requires you to be explicit. You want to create a node with 4 children and easy of them have a bunch of inline attributes? Cool, do it manually, instead of specifying a string of html which the engine will parse and DOM-inize for you (jQuery can do this). Most prominent for me: jQuery is very smart and very easy to use, but lacks a certain elegance due it’s lack of explicit control; Mootools requires more work and overhead to get something done, but is very organized and beyond the learning curve, more meaningful.
Example
To create a series of nodes in jQuery, it’s as easy as this:
var html = ‘<div id=”div-one”><span id=”span-one”>yo yo</span></div>’;
$(html).prependTo($(’#random-node’));
In Moo, it’d be something like this:
var first = new Element(’div’,{’id’:'div-one’});
var two = new Element(’span’,{’id’:’span-one’});
first.adopt(two);
$(’body’).shift().adopt(first);
One is easier/more implicit than the other. However the other is much more explicit, and easier to follow for a foreigner who isn’t too familiar with the jQuery syntax, rules and behaviors.
Optimization/Speed
I don’t know too much about jQuery’s speed. I believe that at this point we’ve got to the point where an extra 10 milliseconds isn’t a do or die or decision maker for what framework/library to use. But with that in mind, one of the great things for Moo is the ability to compartmentalize only what is needed for client side behavior. Everything is kept as a separate stand alone, window based class, where as jQuery seems to throw in a lot of other code into one batch which is mutually dependent.
This goes back to my gut reaction though. For a new comer, I don’t want to try to determine what classes/objects I’ll need. I want a script tag that has almost everything that I need. No playing with downloader apps to pick and choose what my project will need. Mootools therefore introduces a higher level of (initial) complexity, but brings with it greater than control, and again, explicitness.
Community
Up until this point, I’ve more or less tried giving opinions for and against both libraries, but in this category (Community), there is a winner hands down: jQuery. I don’t really know what the reason for this is. I would say that jQuery has been more organized in their community/developer evangelism, which is completely true, but I don’t think that’s the real reason.
While Mootools is still trying to get it’s community plugin system up and rung (MooForge, I believe), I think a core reason it’s the direct and simplicity of jQuery. I think it was able to garner such a strong following because the barrier to entry is to incredibly tiny. I don’t need to understand JavaScript syntax, programming syntax, or the inner workings of client side development. The very syntax that I love about Moo (e.g. new Element(’div’).addClass(’oliver’).addEvent….) is also probably what turns people off. The fact that I need to be so direct about what I want done is something that many people probably don’t want to deal with.
Conclusion
But away from my tangent, the jQuery community is amazing. So many plugins, organized horizontally and vertically by jQuery themselves. So many resources to learn the syntax, deconstruct plugins to understand the code, etc. While my obsessive compulsiveness when it comes to coding syntax and practices would never allow me to fully embrace and adopt jQuery personally and independently of where I work full time, I can understand fully it’s benefits. I’ll always evangelize Mootools whenever I can, but after this exposure to jQuery, I’ll understand where it’s most useful and for whom Mootools would really be welcome to.
Client side framework’s should be called client side libraries; here’s why:
This isn’t a really important post, it’s just something I think need’s to be expressed and accepted; it must be accepted. Mootools, YUI, jQuery, Dojo etc. are great. They help a person with very tedious javascript techniques, speed up your applications, and make the UX much richer.
But they are not frameworks. I know this probably just seems like a semantics issue, but I want to make it clear that they are not frameworks, they are libraries. From http://dictionary.reference.com/browse/framework
frame⋅work [freym-wurk] Show IPA
–noun
1. a skeletal structure designed to support or enclose something.
2. a frame or structure composed of parts fitted and joined together.
3. the construction or sale of frames.
4. work done in, on, or with a frame.
A framework should be referenced only when your development is surrounded or incased by some structure. On the php side of things, this makes sense; an MVC based framework since every piece of code you write it part of the execution of the framework. On the client side though, it’s not so clear cut.
While you can work inside of a client side library as if you were in a framework (eg. creating new, framework-specific, classes), most of the code you write is simply using the library to help it out. As an example, you attach event handlers, create and manage JSON, make ajax calls, etc. All of this you can do natively, or you can have the library help you out. But when you use one of the library’s helpers, you’re not tied to it. You’re still writing native javascript, just short-cutting through the library’s helper methods and naming conventions.
I’m not sure why this deserved a post, such a long post at that. I suppose as I learn more about true frameworks, I’m realizing that semantics like this really do matter. When I write in CI or Cake, I have to fall in line with their file, naming and folder conventions. I need to work inside of a controller, which is triggered by the framework. I need to define the interface in view/template/layout files, which are loaded and compiled by the framework. And I need to access the data set through their ORM, which is managed by the framework.
JavaScript isn’t like that.
Now while the specific cases I’m talking about (YUI,dojo,jQuery,Moo) are in my eyes libraries, that’s not to say that there couldn’t be/aren’t client side frameworks. I imagine javascript/ajax driven applications (large ones like gmail or a few Ycombinator/startup’s) have client side frameworks.
They have these systems in place where you have to work inside of them; the work is delineated among an MVC pattern, or some sort of separation of logic. I think that’d be really cool to check out, but because of the nature of javascript, I don’t think it’s as necessary as it is on the server side. Maybe I’m just saying that because I haven’t really been exposed to one, but client side JS is more modular and sparse than server side development, and for that reason having a library to help you tap into short cuts makes tons of sense.
My last point though, is that while I’ll always consider these javascript extensions libraries, I can definitely understand how some people would call them frameworks due to the way they use them. If you constantly are creating new framework-specific classes that follow standard programming practices (eg. hierarchy, casting, separation of logic), I think it’d be fair to see you’re using the library AS a framework. I’m cool with that. Lets just be clear about how the extension is used by the general public.