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 http://jqueryvsmootools.com/
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 1.3.1.1, 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:
https://github.com/mootools/mootools-more/commit/358378c5b. 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.
Conclusion
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.
