Wednesday, May 20th, 2009

jQuery vs. MooTools

Category: Articles, jQuery, MooTools

Normally when you see a title like jQuery vs. MooTools you get ready for the flame bait. You would expect it even more so if you found out that someone from one of the frameworks wrote the post!

Well, Aaron Newton did just that, and I think he did a very good job at trying to keep as unbiased as possible. He can never be perfect since he has a certain viewpoint, and in fact in some ways when you come from that view you can easily under-share your points.

This isn’t a rushed piece. Aaron has been thinking about these things for quite some time, and has really pondered it.

It is a fairly long piece, and includes:

  • MooTools Makes JavaScript Itself More Fun
  • jQuery Makes the DOM More Fun
  • Anything You Can Do I Can Do Better
  • MooTools Lets You Have It Your Way
  • Chaining as a Design Pattern
  • Reusing Code with jQuery
  • Reusing Code with MooTools
  • Decision Time
  • Discussion
  • Posted by Dion Almaer at 7:31 am

    3.9 rating from 68 votes


    Comments feed TrackBack URI

    “I think he did a very good job at trying to keep as biased as possible. ”

    Were you making a sarcastic comment here, or did you mean to say “unbiased”?

    Comment by tiengow — May 20, 2009

    biased … a freudian slip ;) ?

    Comment by digitarald — May 20, 2009

    I don’t know if that’s sarcasm, but I wouldn’t say exactly that the article is unbiased. As much as Aaron may have wanted to be unbiased, his personal experience makes it really hard to accomplish that.

    Anyway… I always find the point of “simulated class based inheritance” quite… pointless. Actually I see it very much as a failure. It’s a well-known and accepted idea that when you learn a language, you shouldn’t bring your previous-language ideas and constructions. In fact, you can get this same idea from some of the comments to Aaron’s article. Even in the article, he argues about style. In fact, he suggests JQuery feels like “an almost completely different language”.

    But still, Mootools (as do others) feels the need to implement an approximation of class based inheritance, which is -imho- completely foreign to Javascript, instead of trying to work with Javascript’s style of inheritance.

    I know Javascript’s model does look strange if you come from class-based languages, but not trying to figure it out and instead trying to implement a class-based inheritance approximation, seems wrong to me.

    Probably it’s me the one who’s wrong, I know, but anyway this is how I feel about this topic.

    Comment by Venkman — May 20, 2009


    JavaSCRIPT is not really an object-oriented language. It has objects, yeah, but it isn’t oriented toward them. They’re an after-thought. It is class-less. And, yeah, that makes it half-baked. No inheritance, no hierarchy, makes for a very primitive time. These are concepts, not constructs ripped from other languages. That’s why it is becoming class-based in the next iteration. It is the same transition that PHP (also originally a script language) undertook between version 3 and 4.

    Comment by MaratDenenberg — May 20, 2009

    I’m not sure how I feel about this one. I transitioned into Javascript from Actionscript quite easily. Then AS3 came out and the big push to start coding with classes and whatnot began. I’ve made the transition from AS2 to AS3 readily enough but I can’t get myself to be as comfortable with that programming style. I’m sure that I’ll have the same issue if they implement this in Javascript.

    I guess I need the big project where I can clearly see the advantages of programming with that mindset to get over the hump. Unfortunately I just don’t see that happening anytime soon.

    Comment by travisalmand — May 20, 2009

    @TNO: Basically you’ve got two options. You can avoid using any class approximations until true classes are available in the language (could be a while). Or you can start using them now and take the risk that your mind might be too ‘warped’ when the real thing comes along. Of course, I think this is silly. Every language does some things in its own way and within any language there are many different approaches to various problems. There will always be new concepts to learn and that learning process is a GOOD THING. Besides, shying away from something that might accomplish what you need now because something marginally better could come along at some point in the future is surely a mistake.

    Comment by okonomiyaki3000 — May 20, 2009

    @MaratDenenberg: Class based is NOT the only definition of object oriented. Prototype based languages are absolutely object oriented, and I would say, more object-oriented. Look at Self, the language that inspired JavaScript and other prototype based language if you don’t believe me.

    What I believe Venkman to be pointing out, is that instead of trying to force in class style inheritance, just use prototypal inheritance because that’s what the language supports.

    In my own personal experience, I came from a Java background and when I first looked at JavaScript I thought the same as almost everyone else, “Where are the real classes? This is dumb.” But after you learn more, and play with it, and open your eyes to a range of languages, you might find that JavaScript does find an elegant place in the range between object oriented and functional languages.

    There are a lot of wrinkles in the language, though, I’ll grant you. I think that creating a prototype chain is clumsy, and instanceof and typeof are practically useless to list a few.

    One of the most beautiful things about JavaScript is how malleable it is.
    I think its great that jQuery can use a functional style, while Mootools does something more class based. Personally, I think that there is a use for class style patterns, but I don’t think that we need classes built in. I think prototypes are good enough, and all that would really be needed is a better way to call super.

    Comment by genericallyloud — May 20, 2009

    An excellent article. Another excellent article here: which ends with the following quote: I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake. On a personal note, the idea that javascript suffers because it doesn’t work like java is both ridiculous and sad. Please accept that you made a mistake 15 years ago by ridiculing what was obviously the future of application development. Should have joined us in the revolution. Hopefully, your attempt to reintroduce monarchy to a free society will fail.

    Comment by nataxia — May 20, 2009

    I think the prototypal inheritage model could be improved to make it easier to work with when it comes to inheritage. The main issue I have with the default model is the way to call parent methods. For example:, 1, 2,3); is not as nice as this.parent(1, 2, 3) as many OOP JS frameworks provide. However this could be resolved at the language level if there was a way to access the base prototype of a subclass. Like base.someMethod(1, 2, 3);.

    But I would still love to see classes in JS they provide a more strict logical unit and it should be easier to optimize the language if you have strict classes. Just look how V8 needs to auto generate static class types based on the prototypes. But having two OOP models one class based and one prototype based in the same language is kind of weird and both serves it’s purpose.

    I think most of the people who nag about the class model of other languages like C++/Java/C# haven’t really used them and come from a script world it’s easy to dismiss something you don’t understand. I think those languages are more beautiful since they provide order not chaos, I think JS is just to dynamic some times.

    Comment by Spocke — May 20, 2009

    @marat – javascript is object oriented. It is just prototypical instead of classical. It looks like this:

    var personPrototype = {
    ‘type’: ‘human’
    ‘rename’: function (name) { = name;

    var Person = function (name) { = name;

    var Person.prototype = personPrototype;

    var marat = new Person(‘marat’);
    marat.rename(‘Marat Denenberg’);
    alert(; // Marat Denenberg

    Comment by seasoup — May 20, 2009

    All this arguments about using classes in JavaScript miss the mark, I think. While frameworks like Prototype and MooTools use the “Class” name for it’s constructor functions, all these functions do is allow objects to inherit from other objects. This is not Classical inheritance nor is it trying to be; this is simply exposing Prototypal inheritance in a more convenient API. They aren’t classes in the Java sense. They’re objects. They are objects that inherit from other objects. this is precisely what JavaScript is built on.

    Arguing for or against classical inheritance completely misses the point.

    I can tell who, in this comment thread, actually read the article and who didn’t.

    Comment by anewton — May 20, 2009

    My problem is not with a Class emulation in and of itself as a sugary abstraction, its with the extra fluff and special rules the library implementations can come with that clash with the flow of the language with its word play. This is what people need to be wary of when they use them, its not a black and white issue as you’re making this out to be.

    Comment by TNO — May 20, 2009

    The one point that Aaron makes in this that really rings true for me is the difference in syntax. I’ve always found jQuery’s syntax to be counterintuitive for exactly the reasons Aaron illustrates. This is also a reason I prefer the classical inheritance model, because it leads to a syntax that is more obviated and self-describing. Libraries like Ext JS and MooTools lead, in my mind, to more readable code.

    Speaking as someone that has had to maintain others’ code, but more often is the one writing the code that others will maintain, this is one of, if not THE single biggest concern. I’ve always hated the term “code” when talking about programming because the more it really looks like code the less comprehensible it is. In fact, I wish someone had come up with a better idea than the basic C syntax most languages are now based on. I guess we hate typing so much that brevity is more improtant to most people than readability, which to me is the wrong answer.

    Of course, I don’t have a better answer either, otherwise I’d be rich :)

    Comment by fzammetti — May 20, 2009

    “What I believe Venkman to be pointing out, is that instead of trying to force in class style inheritance, just use prototypal inheritance because that’s what the language supports.” – by genericallyloud

    Thanks. You summarised that very clearly :)

    I meant exactly that. And also that it’s a bit (just a bit, ok?) incoherent arguing against one library because it promotes a certain style that feels to the author too different from Javascript while arguing that it’s a good thing that the other library implements some sort of class based inheritance, which is in itself quite foreign to the language.

    Comment by Venkman — May 20, 2009

    Again, to reiterate, despite the fact that the actual function is called Class, all it does is make it possible for objects to inherit from other objects. It’s just an API for prototypal inheritance. It’s absolutely NOT foreign to the language; it IS the language.

    Comment by anewton — May 20, 2009

    I’ve been coding in JS since it was LS (for whatever that’s worth) and I can honestly say there are times I truly do wish that JS had more of a classical approach to OOP (classical inheritance, public/private members, yada, yada, yada). Yes, I realize JS is playdoh on steroids, its so flexible it can practically kiss its own ass and you can build any of these things in through clever use of closures, etc..etc. And we all love that flexibility-but I don’t see the harm of having more classical OOP features built into the language itself if we get to keep JS’s flexible nature. Think of this as having your cake and eating it too. If this did nothing else but unify the various classical OOP emulators floating around by Newton, Resig, Edwards, Slocum et. al it would be worth it for that alone.

    Comment by coryn1 — May 20, 2009

    MooTools Lets You Have It Your Way

    Hmm. I could easily implement MooTools’ hover syntax in jQuery in just a few lines… but who would want to? There’s a reason people are developing jQuery syntax for MooTools and not the other way around!

    jQuery doesn’t have class-based inheritance in the core, you can find it in the LowPro plugin. I would argue jQuery is built to be the more maintainable and reusable of the two languages — jQuery code reads like English to me, and the sharing and support from the plugin community is amazing. Even Aaron notes that with jQ “it’s easy to get started and see quick results but…can turn into code that’s harder to reuse and maintain (but really that’s up to you; it’s not jQuery’s problem, per se)(Emphasis mine)

    jQuery is extended properly with plugins where needed. jQ is easy to use, that’s why there are so many bad examples out there. Many inexperienced coders use jQ, that doesn’t mean jQ is any less powerful.

    Comment by doublerebel — May 20, 2009

    @anewton, to me, it’s you the one who misses the point. At least you seemed to miss the word “approximation” when I argued about how some libraries (not only Mootools, and not nly Mootools and Prototype) try to implement an “approximation of class based inheritance”.

    I would be very surprised if you could tell who has read tfa, but I for one, have. And have read such things as “You pass Class an object (above, we pass an object with members like “isAlive” and “eat”) and this object becomes the prototype of every instance of that class. To create an instance, you call it like this: … ” (emphasis mine). I might entertain your claim of it being just an API over prototypal inheritance, but then again if he talks about classes and instances, I tend to believe otherwise.

    Comment by Venkman — May 20, 2009

    @venkman – The jargon of reusable objects in Prototype is lacking, and consequently we call these things what they appear to be – what we have jargon for – “class” and “instance”. In reality they are all objects, some of which inherit from others. In JavaScript if we have obj1 and obj2 and we set obj2’s prototype to be obj1, what do we have? What is obj2? What is obj1? child? parent? inheritor? Fighting over jargon isn’t helpful, so we call them “classes” and “instances.” But they are still just objects whose prototypes are set to the others. It’s not an approximation of Java or any other classical language.

    @doublerebel – You write:

    Hmm. I could easily implement MooTools’ hover syntax in jQuery in just a few lines… but who would want to? There’s a reason people are developing jQuery syntax for MooTools and not the other way around!

    I doubt it. jQuery is a subset of MooTools functionality. This is not meant as a negative statement (indeed, for many, it is a positive thing). But this is one thing that MooTools can do that jQuery cannot. You cannot implement MooTools with jQuery; jQuery’s scope is focused on the DOM. While you can certainly duplicate MooTools, you’d be doing it in vanilla JavaScript. Again, this isn’t meant as a negative statement. But it is a limitation of jQuery (not a fault!).

    I’ll reiterate what I say in the article, MooTools nor jQuery are different, with different purposes and different philosophies. I did my damnedest in the article to convey this point effectively and to assert that neither framework is a poor choice to learn (ideally, people would invest time to learn them both before making any decisions). I have a personal preference that falls in line with MooTools, but there are certainly things about it that can be much better, just as the same is true of jQuery. That’s why we’re still iterating on these frameworks.

    Discrediting MooTools because it embraces prototypal inheritance, a mainstay of the language, is a matter of preference, not fact. jQuery’s lack of this functionality (and again, I’m focused in the article on the cores of both frameworks) is a deciding factor *for me*, but that’s ok. If you don’t like this pattern, don’t use it. That’s kind of the whole point of the article: both are different and different philosophies and choosing one is more a matter of personal taste than it is one of merits and demerits of each library.

    Comment by anewton — May 20, 2009

    I prefer Prototype’s OO which also has proven very effected for my tens approaching a hundred classes (who gets to count them when they can be anywhere?)

    One of the things I like about Prototype’s OO is its “$super” for referencing the parent’s constructor and methods. I am not even sure if it can break anything in the process, but so far, so good. I do make plenty of use of “$super” in every class I create because every class I create has to depend on a common ancestor so it’s a flat hierarchy, it can be two or three classes deep even though deeper than that is a little rarer.

    To me, OO in JavaScript works like Ruby’s OO to some extent given my tweaking of it so I am pretty happy as I understand the shortcomings.

    Also, I know folks who plead “prototypical inheritance” and “Java style classes” won’t find what they could probably want when I make use of this OO thing provided by Prototype and some tweakings.

    I find it kind of funny actually. Folks who don’t want any classes means that they want the “flattest” programming experience possible, which also means that I would not want to see their code. Folks who want Java style classes will end up with some of the worst experience when they try to bend JavaScript too much to their likings, and will not understand why they are in the minority.


    Comment by jpedrosa — May 20, 2009

    @anewton: I’ll pass over the fact that the jargon is not lacking and simply say that calling things by names which do not correspond to what they are just because those names are familiar to you, somehow doesn’t click as “right” to me. If you’re comfortable with it, fine, of course. But I’m not.

    Comment by Venkman — May 20, 2009

    C’mon all, let’s stop the discussion. We all know the Moo kicks jQuery’s ass.

    Comment by mawe — May 20, 2009

    mawe, that’s not a very useful comment.

    Comment by anewton — May 20, 2009

    @Venkman – Is your point that MooTools is trying to be something its not because of Aaron’s choice of jargon? Just because he (and a great many others) prefer to use familiar terms to describe design concepts of prototypical inheritance, does not mean that MooTools is stretching the language beyond what is intended. It is simply an indication of personal preference. A rose by any other name…and all that.

    As a matter of interest (really, truely); what terms would you use to describe his example?

    In JavaScript if we have obj1 and obj2 and we set obj2’s prototype to be obj1, what do we have? What is obj2? What is obj1? child? parent? inheritor?”

    Comment by sixtyseconds — May 21, 2009

    @sixtyseconds you can, if you want, call obj1 parent and obj2 child. But, as you can see, that example is unrelated to the need of using terms like “class” and “instance”.

    For the rest of the argument: I’ve never said anything such as Mootools trying to be something its not. I haven’t said either, that Mootools was stretching the language, and it would never occur to me to say what’s “the intended use of a language”. In fact, I haven’t made any criticism to Mootools in particular.
    I’ve criticized: 1. As a personal preference, the fact that some frameworks/libraries feel the need to approximate class based inheritance. 2. What I think is a small inconsistency in this article (not in Mootools): arguing against a particular style promoted in one library because it “feels too different to the language”, but arguing in favour of the other library because it approximates something (or, if you really want it that way, “uses a certain terminology for some things but in the end it’s just an API”) which I feel is quite different to the language (classes and instances).

    I’ll end my part of the discussion here (because I don’t see this getting anywhere). I’m really sorry if any of you have felt in anyway aggravated or have felt your favourite library was being criticised or whatever.

    Comment by Venkman — May 21, 2009

    Mmm well I don’t know a lot of mootools, but is very interesting to see the differences of this two frameworks ;)

    Comment by hquinn — May 21, 2009

    I think it is hilarious that a massing mob of coders sees the prototyping in JS as something bad. That is like saying this to a person utilizing CSS to make Sprites: “Oh my god man! What are you doing!?! The word ‘Sprite’, it can only be used to mean a tasty, clear beverage produced by the Pepsi Corporation! What sacrilege! Outrage, outrage I say!” – hahahaha, lame!

    This is a language that HAS PROTOTYPING for a reason Captian Obvious! Even Crockford has written enhancements by prototyping, I cry a tear :p for the haters! This whole “purist, prototyping in JS is wrong” thing is complete BS.

    Anywho, the word “Class” is just a word. Words don’t even really exist anyway folks; a chair is a ‘chair’ because some stupid cave man made a rock that was cool for sitting on and had to call it something more than a grunt! Stop throwing up all these lame logical fallacies to boost a baseless argument against an intended feature of JavaScript.

    Comment by csuwldcat — May 21, 2009

    I don’t see the benefit of MooTools trying to be like Javascript. Whats important as always is being consistent and having good documentation. Can you find their methods in any Javascript language reference? Of course not.

    In the end its just the style, features and preference.

    Comment by dizzyed — May 23, 2009

    @dizzyed, actually, many of the extensions to native prototypes are based on the actual JavaScript 1.5, 1.8, etc specs. So yes, you can, for some of them.

    Comment by anewton — May 24, 2009

    Someone forgot to mention about issues running Mootools under Konqueror or is those issues fixed now?

    Comment by Iumentum — May 27, 2009

    after reading that I feel even more compelled to do not stop using jQuery. Thanks, Aaron!

    Comment by daitro — May 27, 2009

    I thought the article was great – there’s a mad rush to learn all things jQuery – and I can’t help but feel it’s something of a double edged sword. I’ve only been coding JS for a very short period of time – and as such am faced with the dilemma of continuing to study vanilla JS, or learning a framework.
    – jQuery is immensely popular, very fast to implement, has a superb selector system BUT I feel it obscures the language it’s written in. If you spend your time learning jQuery, that’s great from a practical and immediate POV, but I think it would leave you stranded in the long game.
    -MooTools seems less aimed at providing out of the box gimmicks, and more about addressing the failings of JS itself, while retaining the syntax of it’s host language. This – to me – is a big selling point as my priority is to study JS at it’s core as opposed to a lib’s syntax. The big negative (in terms of your average small fry coding company) is that it won’t permit ramshackle JS implementation – mixing and matching libs and scripts. This is prohibitive when you join a team that has established a mix and match methodology. From my brief experience – JS coding rarely gets afforded the same sort of dev time as server-side and you’re almost expected to deploy ready mades – thus prohibiting MT use.

    So, my twopence worth: in the short term I would deploy jQ for certain aspects of development simply for the sake of time, expediency and compatibility with other coders code, but from an academic perspective, and for the long game, I would want to study and implement MT + vanilla.

    Comment by sunwukung — June 1, 2009

    thought very well but are nevertheless, a bit of bias.

    Comment by masini — February 8, 2010

    Leave a comment

    You must be logged in to post a comment.