Keep your 2 barrels of Mootools, I am keeping my barrel of jQuery


As I was latetly assigned to a new project at my new job, the question of the choice of the javascript framework to use raised. My fellow co-workers were used to Mootools and our talented HTML integrator had already used some Mootools code in here work.

So Mootools would it be.

jQuery was the only javascript I had really worked with and I took this as a great opportunity to learn something new. So I went for it quite enthusiastically.

After a few weeks have passed by, I start to get my own opinion on the relative lacks and strengths of both frameworks. Note that I am still a new user of Mootols and my opinion will probably evolve.

As I am a little lazy, this post will be organised as a comment of the one from Aaron Newton of Clientcide, which he posted on

As you might have already gotten it from the title, my opinion is not exactly always matching his’.

2 good frameworks

jQuery and Mootools are 2 good frameworks. When playing the “who is using what” game, jQuery presents a very impressive reference list. But if Mootools’list is shorter, it can be proud of containing some prestigious names that suffice to prove its quality (w3c, vimeo, netvibes etc.)

I obviously agree with Aaron Newton on this point: none of these two frameworks is a bad choice.

The mottos say it all

Indeed, mottos say long.

[..]f you go to the jQuery site, here’s what it says at the top of the page:

jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.

..and if you go to MooTools, this is what you’ll find:

MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API. [..]

Am I the only one to find that one of the two mottos is a little more arrogant than the other? Seriously?…

« .. designe for the intermediate to advanced Javascript developer.».. .

The important fact here is not about the truth of the statement (personally, I consider Mootools as being very usable by a beginer). The important fact about this statement is that the Mootools team addresses people who consider themselves as confirmed developers.

Aaron even goes further this way by, if I sum it up, considering that “If you are interested in JavaScript and what makes it interesting, powerful, and expressive, then, […] MooTools is the better choice.

I strongly disagree with this last point. Actually, I even think that liking Javascript is a reason not to use Mootools. But more about this later.

The Learning Curve and The Community

Indeed, the jQuery community is much broader than Mootools’ one. The author is skipping an important point here: The bigger your community is, the more you get reported bugs, the more developers you have to work on them and to improve th code base, the more contributors you get to develop and share plugins.
When talking about stability, frequency and importance of release, there again, jQuery is an enormous step ahead.

As an example: Maybe I am not lucky but a just a couple of days after I started using Mootools, I encountered a annoying bug. In Mootools More, the Form validation does not work on select elements.
Just try to implement a callback for elementFail and you won’t get ever anything in your element variable.

The bug is referenced and corrected on Github for a while: But it is still not fixed yet in the official download version.

What Javascript is Good For

The author here briefly describes the prototypal approach of the object model used by Javascript. His conclusion is that “the bad news is that vanilla JavaScript doesn’t make these powerful things very useful or accessible”.

Huuh? oO? What?

OK, I agree that the prototypal model is (too) often unknown of developers. The excellent article from Steve Yegge on the subject and “Javascript, the good parts” from the also excellent Douglas Crockford, will help the curious ones to get an insight on the subject and about how Javascript implements it.

But how can one say that the language is responsible for making these powerful things useless or inaccessible?
Here how you declare an object in javascript:

var my_object = {
	property: ‘a property’,
	method: function(){
		alert(‘Hello World’);

And here is how to inherit from this object:

var tmp = function(){ };
tmp.prototype = my_object;
var my_herited_object = new tmp();

OK, maybe I am not totally sincere. The last bit of code may not be that obvious to everybody. But still, where does Javascript make it useless or inacessible?

Mootools makes Javascript itself more fun

Aaron Newton explains here that Mootools is trying to make Javascript better, to make it “the way it should be”.

So, Mootools extends the prototypes of the native types to bring them missing functionalities.

Let’s just remember here that the augmentation provided to Element are mainly focused on the DOM manipulation, a domain where jQuery is excellent.
The other “ameliorations” given to the native types, like Array or String are sure welcome, but they are not a Mootools exclusivity.
jQuery also includes some helper functions, without integrating them to the native prototypes.

Finally, Mootools proposes its famous Class concept.
The author pretends here that Mootools is not trying to introduce a class-based object model in javascript but that its purpose is instead to simplify the use of the prototypal model.

Sure… And I am the Queen of England…

Simple question then: Why call an object/namespace that is dedicated to simplify the use of the prototypal model with the name of its concurrent model?
In practice, the use of Mootools Class is clearly a mimic of a “classical” class object model.

Assuming that the will of Mootools was really to facilitate the use of the prototypal system, the term “Class” can only lead to confusion for the developer.

I like Javascript for, among other things, its prototypal approach. And because I like Javascript, I do not need Mootools Class system.

jQuery does not provide any “inheritance model” for one good reason: it is already built in Javascript and works perfectly well.
The additional layer provided by Mootools is confusing and unnatural to me, and should, I believe, be to any javascript developer.

jQuery makes the DOM more fun

Another sophism from the author. jQuery would only be a “toolbox” dedicated to the manipulation of the DOM only, where Mootols would a real, much more abstract and noble “framework”.

The fact is it is false.

The main thing is that jQuery is focused on utile things. Even if, notably thanks to node.js, we start seeing some javascript running out of the browser, the truth is the huge majority of the existing javascript worldwide is interpreted by the browsers.
And the manipulation of the DOM is, indeed, a very important point for the developer.

But reducing jQuery to the DOM handling is fallacious. The Ajax layer, the utility functions we already talked about or the processing of events by groups introduced in 1.5 do not have any direct relation with the DOM.

Anything You Can Do I Can Do Better

Let’s skip this chapter where the author is trying to convince us without any evidence that the scope of Mootools is wider than jQuery’s one.
I already explained how useless the so-said extra area covered by Mootools was to me.

Mootools Lets You Have It Your Way

Let’s skip it too.

I just do not understand one willing to mimic Mootools.

When manipulating the DOM, Mootools is incoherent and verbose.
On all the Class stuff, everything can be done simpler and cleaner in vanilla Javascript.

Chaining as a Design Pattern

Where we are explained that we can access the properties of an object that is sent as a result of a function.
Thank, we knew it already.

Reusing Code with JQuery

Here again, we are told that using jQuery, we can only manipulate the DOM.
I am sorry Aaron but far before knowing Mootools, I was creating, using and _even_ using some inheritance principles in Javascript.

A little word on “There’s not a lot of complexity here, which makes it easy for anyone to write jQuery plug-ins – they’re just single functions.”
Let’s just remember that, contrary to a language like PHP, in Javascript, a function is an Object, that we can freely define and use complete objects in it, or other embed functions.
Because functions are closures, they can also access everything outside themselves that were accessible from their definition scope.
There is actually no limit to how complex a function can be.
Actually, the whole jQuery framework (I use this word on purpose) is one single function.

The point about jQuery-UI also looks out-of-subject to me. The way jQuery-UI is included in jQuery is not dictated by jQuery. It is just a choice from the jQuery UI team. Let’s just remember one simple statement that one may have forgotten:
This is all javascript. The source is right there. We can code around the way we want.

Reusing Code with Mootools

First a word about the extension of the native prototypes.
Personally, I am balanced on this question.

Of course, I find (too) dangerous to modify or extend the behaviour of objects that are share across the whole execution context and then, most probably, by other scripts and libraries (including Google Analytics or Maps).
On the other hand, I can understand how tempting it can be to have a trim method right from any String.

Using an inherited prototype is not a solution as this would obviously imply lots of tedious casts.

The alternative, and my personal choice, it to externalise these functions, like jQuery does with c jQuery.trim() for instance.
Of course, we loose in syntaxic quality by writing jQuery.trim( my_string ) rather than my_string.trim() but at least, we are sure that we do not interfere with an insane external programmer who decided to use String.trim as a way to give the current date.

About the use of CSS selectors

One question: What’s the use of the $ function in Mootools?

It is just an alias for document.getElementById, does not provide any additional value and introduces some confusion with $$.

Let’s just remember that $$(‘#myid’)[0] will give the same result as $(‘myid’).
So, the purpose of $ would be to save 4 chars?

I am starting to assume that the $ function’s real purpose is to conflict with other frameworks like jQuery or Prototype.

About the Namespaces

Let’s finish with a point that I have not talked about yet and that I suspect Aaron Newton to avoid.
This point is one of the big ones that make me think Mootools won’t ever be my favourite framework.
I am of course talking about the use of namespaces.

While we can see jQuery’s constant effort to limit its impact on the window namespace to the two $ and jQuery variables, we cannot say the same thing about Mootools.

Mootools is not very shy when talking about exposing its insides to the global world.

We of course get $ and $$ but also a lot of other ones: Element, Class, Slick. If you use Mootools More, some more objects wil also be set globally: Form, FX etc.

Seriously, what is the risk another script uses a variable named Form?
Quite high if you ask me.

For a framework “designed for the intermediate to advanced JavaScript developer”, I find this is quite a big noob mistake.


As you may have understood, I am not a Mootools fanboy. jQuery of course does not need me to still be the dominant framework for a while.

Let’s just remember somethins that may have been forgottent during the reading of this post: Mootools is not a bad framework.
The only fact that the w3c or netvibes use it for their site should be enough to be sure about it.

But I have some points of disagreement with Mootools: I find it infatuous, too buggy for me and for a large part uselesss or even counter-productive.
Yes, this is a little proselyte _I would spend my time doing other things that writing this post if I would’nt want people to read it.
To me, Mootools is promoting itself by using a corporatist argument being “Mootools is for 31337 ; jQuery is for Noobs”.

I think this argument is bullshit. And I do not like corporatism. Real 31337 are open to the world.

You still can have good reasons to choose Mootols over jQuery (or any other framework) but please don’t fall into this gross trap.

PS: If you want to learn more on Javascript, I invite you to consult the essays and media from Douglas Crockford.

  1. I work with jQuery, Mootools and sometimes YUI.

    Every time I am given the choice I will avoid Mootools. One of the major reasons for this is the forced use of the un-Javascript like Class() constructor. The adoption of this approach severely limits flexibility and the ability to resolve problems in legacy code.

    If I want a quick solution I’ll use jQuery which offers good documentation and a professional approach with lots of examples.

    If I want a solution soundly based in solid programming architecture I’ll use YUI.

    MooTools has always been the shakiest of the JS frameworks in my opinion and every time I have contact with it I find my fears confirmed.

  2. Je développe depuis un bon moment en javascript en utilisant jQuery et son système de plugin. Depuis peu de temps, je m’essaie à Mootools, j’y ai développé quelque “classes”. J’ai lu pas mal d’articles de comparaisons (ou pseudo-comparaisons) des deux frameworks (oui, pour moi aussi jQuery est bien un framework). Y’a du bon, et beaucoup de mauvais.

    Je suis dans l’ensemble d’accord avec cet article. J’ai aussi ressenti la même chose concernant Mootools qui s’annonce pour les non-débutants réduisant jQuery aux débutants. Souvent les développeurs utilisant Mootools dénigrent jQuery, mais pas l’inverse. Pour moi, jQuery et Mootools n’ont pas les même approches et pas le même but. On peut pas vraiment les comparer.

    J’ai cependant deux choses à dire. La première est que j’aime le concept de “classe” de Mootools. Ca me plait, vraiment. Sans doute parce que je suis à la base un développeur php qui a commencé directement par de la POO et enchainé avec Java en cours. Il simplifie aussi (et rend moins moche ?) l’héritage comme le permet le JS.

    Ensuite, je constate également que j’ai du mal de bien structurer mon code avec jQuery. Et je ne parle pas du code au sein même d’un plugin mais de l’ensemble du code d’un application web. C’est peut-être un problème venant de moi et pas de jQuery. Je n’ai cependant pas ce problème avec d’autres langages ou frameworks.

    Si je me suis intéressé à Mootools, c’est d’une part pour remplir ma curiosité du fait qu’on en parlait beaucoup et parce qu’il est intéressant de se remettre (et ses choix) sans arrêt en question, surtout en informatique. Mais pas uniquement. Je voulais voir si Mootools pouvait m’aider à structurer mon code pour un application web fonctionnant en grande partie en JS. Et j’ai cette impression que oui. Maintenant, je suis encore relativement jeune dans Mootools et peut-être que mon avis changera.

    • xavier
    • September 26th, 2012

    Pour ma part, j’ai utilisé pas mal de framework différents pour le javascript. Pour avoir pratiqué Jquery et mootools, je suis resté, pour bien des raisons sur mootools.

    Quand il a fallut faire des gros CMS sur mesure, des backoffice complexes, des intranet, j’ai pu voir les limites de JQuery. Dès j’ai voulu faire une application entièrement en objet et bien structuré, j’ai dû fuir JQuery qui ne le permettait pas (ou alors qui le permettait, mais de façon sale à mes yeux).

    Je ne suis pas d’accord sur beaucoup de points sur l’article, car là, j’ai l’impression que l’auteur compare les framework pour faire du web de site vitrine ou juste embellir l’affichage à coup d’ajax et de plug in. Dans ce cas, n’importe quel framework peut être satisfaisant.

    Pour des phrases comme ça :
    Rappellons $$(‘#myid’)[0] donnera exactement le même résultat que $(‘myid’).
    Est-ce que le but de $ est réellement d’économiser 4 caractères ?
    Je pense que c’est surtout que le‘tonid’) qui a remplacé $(‘tonid’) fais référence directement à getElementById plutot que de parcourir tous les noeuds avec une expression régulière pour retrouver ce que l’on cherche.

    Après pour tes exemples d’héritage en javascript. On peut tout refaire en javascript. pourquoi faire un $(‘#tonid’).html() en Jquery alors que javascript permet de faire document.getElementById(‘tonid’).innerHTML ? C’est parreil pour les class et mootools. On a une syntaxe propre, un développement dédié à ça, les avantages du framework (le jour où ça évolue ou s’optimise, pas besoin de reprendre ton code) etc…

    Donc pour moi, je préfère la syntaxe de mootools, la structure et rigueur à adopter pour développer en object. Mais si c’est pour faire 3 appel ajax dans un coin et de la validation de formulaire, Jquery sera plus simple à mettre en place pour les novices de mootools ou du js qui sont plus accessibles et plus simple si on ne creuse pas pour faire une usine à gaz.

  3. En dehors des multiples bugs de mootools et de sa faiblesse à maintenir une rétro-compatiblité, c’est surtout 2 points qui me choquent:

  4. l’injection du paradigme POO Objet orienté Classe
  5. l’extension des prototypes natifs js
  6. Concernant le premier point, utiliser des classes en Javascript est comparable à vouloir faire de la programmation fonctionnelle en PHP. On peut tricher pour y ressembler mais on va dans ce cas contre la logique de fonctionnement du langage.
    cf la conclusion de Douglas Crockford sur le sujet:

    Concernant le deuxième point:

  1. No trackbacks yet.