Why MooTools (or Why not JQuery)(juliocapote.com)
juliocapote.com
Why MooTools (or Why not JQuery)
http://juliocapote.com/post/52467447/why-mootools-or-why-not-jquery
25 comments
Speed benchmarks aside. I feel his points are valid granted you're coming from a Java/C++ background (where most CS graduates come from anyways). But frankly MooTools feels like it's applying classical OOP to javascript. Whereareas jQuery feels more functional and natural. There is no right and wrong approach (although given the choice I would have js be a statically typed language) it's just that both libs are the love child of their respective creators to work in something they enjoy doing. And have healthy communities to support their endeavors!
Now I'm starting to see one of the posters gripe about jQuery plugins. And for me I think that is by design. jQuery I believe was designed to be a lightweight as possible. Practicing modularity at it's finest. Had jQuery been baked with all the bells and whistles, I do not think it would have attracted a large number of devs. Thinking about it what would SQlite be had it had all the bells and whistles of MySQL?!?!
Now I do not know which JS lib fares better when working with a team. I suspect MooTools (due to it's classical OOP behavior) might win out.
Now I'm starting to see one of the posters gripe about jQuery plugins. And for me I think that is by design. jQuery I believe was designed to be a lightweight as possible. Practicing modularity at it's finest. Had jQuery been baked with all the bells and whistles, I do not think it would have attracted a large number of devs. Thinking about it what would SQlite be had it had all the bells and whistles of MySQL?!?!
Now I do not know which JS lib fares better when working with a team. I suspect MooTools (due to it's classical OOP behavior) might win out.
I suspect MooTools (due to it's classical OOP behavior) might win out.
Does the sight of Java programmers trying to force every other language to conform to Java's type system remind anyone else of Harrison Bergeron? Or is it just me?
(Just in case you didn't take my high school English classes: http://en.wikipedia.org/wiki/Harrison_Bergeron )
Hasn't Javascript already suffered enough? It even has to wear Java's name. Leave Javascript alooooone!
Does the sight of Java programmers trying to force every other language to conform to Java's type system remind anyone else of Harrison Bergeron? Or is it just me?
(Just in case you didn't take my high school English classes: http://en.wikipedia.org/wiki/Harrison_Bergeron )
Hasn't Javascript already suffered enough? It even has to wear Java's name. Leave Javascript alooooone!
"Now I'm starting to see one of the posters gripe about jQuery plugins. And for me I think that is by design. jQuery I believe was designed to be a lightweight as possible. Practicing modularity at it's finest. Had jQuery been baked with all the bells and whistles, I do not think it would have attracted a large number of devs."
Doesn't the use of a plugin system generally increase lightweightness and modularity because you can move more functionnality out of core into optional add-ons?
Doesn't the use of a plugin system generally increase lightweightness and modularity because you can move more functionnality out of core into optional add-ons?
1. I think adding faux-classes in JavaScript is pretty nasty, and is a fundamental design choice in jQuery. The fact it doesn't have it is a good thing in my eyes. I simply don't understand what you mean by "jQuery's SQL-like syntax" at all, but it's probably a matter of taste.
2. I think jQuery smells, feels and tastes like regular JavaScript, but I guess it's a matter of opinion. Even if you don't consider it "regular JavaScript" it's undeniably simple to read.
3. Speed is debatable, but in either case, they're quick enough not to matter which is what you need.
4. This is available in jQuery UI and was formerly known as the Easing plugin. I'm not convinced it's the sort of thing that should be in jQuery core since it's used by a minority of people.
5. $("<a />").attr("href", "http://juliocapote.com");
6. jQuery is only 15kb for the whole thing - 15kb is nothing these days. jQuery contains very little unnecessary bloat anyway, and the bigger jQuery UI lets you choose which modules you want.
7. jQuery's documentation in general is excellent.
8. I don't know enough about jQuery plugins to answer this question - I've had a quick glance at the docs and it looks simple enough so I don't really understand the criticism.
9. It's a matter of taste, but one of the reasons that jQuery caught on so much is because it took a namespace-based approach that doesn't coillide with anything else now or in the future (this has been an issue with Prototype) - this allows you to use jQuery in existing code safe in the knowledge that it won't clobber anything else. There's one other core advantage to jQuery's namespace - you always know where to look in the documentation, plus if something changes you can easily identify which bits are what. I think namespaces are a good idea.
10. I don't understand what you mean by this. People have rallied around jQuery because it avoids cloberring anything else so can be used in all projects, solely makes up for the gaps in jQuery, and is fast and small and has good documentation. There's no conspiracy - it's become popular because it's good.
Everyone has their favourite, but I've looked through all the libraries recently and decided jQuery seems to be the nicest in general. I personally think MooTools feels dated - it seems to be designed to be a prettier Prototype and despite succeeding at that goal other libraries seem better.
2. I think jQuery smells, feels and tastes like regular JavaScript, but I guess it's a matter of opinion. Even if you don't consider it "regular JavaScript" it's undeniably simple to read.
3. Speed is debatable, but in either case, they're quick enough not to matter which is what you need.
4. This is available in jQuery UI and was formerly known as the Easing plugin. I'm not convinced it's the sort of thing that should be in jQuery core since it's used by a minority of people.
5. $("<a />").attr("href", "http://juliocapote.com");
6. jQuery is only 15kb for the whole thing - 15kb is nothing these days. jQuery contains very little unnecessary bloat anyway, and the bigger jQuery UI lets you choose which modules you want.
7. jQuery's documentation in general is excellent.
8. I don't know enough about jQuery plugins to answer this question - I've had a quick glance at the docs and it looks simple enough so I don't really understand the criticism.
9. It's a matter of taste, but one of the reasons that jQuery caught on so much is because it took a namespace-based approach that doesn't coillide with anything else now or in the future (this has been an issue with Prototype) - this allows you to use jQuery in existing code safe in the knowledge that it won't clobber anything else. There's one other core advantage to jQuery's namespace - you always know where to look in the documentation, plus if something changes you can easily identify which bits are what. I think namespaces are a good idea.
10. I don't understand what you mean by this. People have rallied around jQuery because it avoids cloberring anything else so can be used in all projects, solely makes up for the gaps in jQuery, and is fast and small and has good documentation. There's no conspiracy - it's become popular because it's good.
Everyone has their favourite, but I've looked through all the libraries recently and decided jQuery seems to be the nicest in general. I personally think MooTools feels dated - it seems to be designed to be a prettier Prototype and despite succeeding at that goal other libraries seem better.
It's considered bad form to reply to yourself, but "solely makes up for the gaps in jQuery" shouldn't be there in 10 - who knows what I was thinking?
I gave up on Mootools when it became obvious that the community surrounding it was much busier condescending new users than helping them. Combine that with documentation that is severely lacking and the aggravation saved by simply dealing with the more community friendly jQuery saved my sanity and time.
I made the switch about a year ago and haven't looked back since.
I made the switch about a year ago and haven't looked back since.
I'm not exactly sure what you're talking about. I've been in their irc channel for hours at a time, and all the community seems to be doing is helping people with their javascript noob questions, even if they aren't related to Mootools.
The documentation is rather straightforward as well. It's pretty easy to figure out what something does.
Perhaps your contempt is outdated?
The documentation is rather straightforward as well. It's pretty easy to figure out what something does.
Perhaps your contempt is outdated?
I agree about the condescension part, which is very unfortunate knowing the immense potential Mootools had when it was still called moo.fx. In fact I believe it could have reached as wide an audience as jQuery, if the community was more friendly.
What's seriously better? MIT License maybe.
What's seriously better? MIT License maybe.
Griping about jQuery plugins is quite trendy at the moment, which I think can partially be attributed to its audience broading as the lib matures.
Most concerns about plugins and the reputation of their authors apply equally to any OSS software - I wonder how many people acquainted themselves with the author of mod_ssl before loading the DSO into their web server?
Plugin quality does vary, and some of the more popular plugins have become quite bloated as the authors try to cover each and every use case, but the beauty of the license means you can write your own, or strip the bloat/cruft from a plugin that otherwise meets your needs.
jQuery doesn't look pseudo-classical javascript, but that doesn't make it unintelligible gibberish - conversely, I find it a breeze to read and simple, direct and elegant to write.
We're spoilt for choice these days: best to sample as many js libs as you can and stick with whatever feels right.
Most concerns about plugins and the reputation of their authors apply equally to any OSS software - I wonder how many people acquainted themselves with the author of mod_ssl before loading the DSO into their web server?
Plugin quality does vary, and some of the more popular plugins have become quite bloated as the authors try to cover each and every use case, but the beauty of the license means you can write your own, or strip the bloat/cruft from a plugin that otherwise meets your needs.
jQuery doesn't look pseudo-classical javascript, but that doesn't make it unintelligible gibberish - conversely, I find it a breeze to read and simple, direct and elegant to write.
We're spoilt for choice these days: best to sample as many js libs as you can and stick with whatever feels right.
My biggest problem with jQuery plugins is people using $() instead of jQuery(). This breaks functionality for people like me who insist on using jQuery().
jQuery(function ($) {
$('#someId').doSomething(); // blahblahblah
});
Sorry, but you're both wrong. Best practice is this:
(function($) {
// Plugin code
}) (jQuery)
What is the advantage of (function($){})(jQuery) over jQuery(function($){}) ? In either case the jQuery object must be in the namespace, and neither leaves a named function laying about. According to the jQuery API jQuery(callback) is sugar for $(document).ready(callback). The ready event is usually when I want my code to run...
http://docs.jquery.com/Core/jQuery#callback
http://docs.jquery.com/Core/jQuery#callback
The (function($){...})(jQuery) syntax is used by plug-in developers who want their code to run before the jQuery(document).ready event. It is closure, and it's purpose in this case is to protect the global namespace from variables introduced by the script. Closures also have many other useful applications in JavaScript.
This is one technically correct (which is usually the best kind of correct), but the jQuery() invocation has one advantage that I feel makes up for adding "jQuery" to the global namespace which is that the next person that needs to modify my javascript sees my code, they'll see the jQuery right up front and know what's up.
That's what comments are for :^)
I always make the dependency pretty clear in my scripts. Plus, it's a "best practice" in the jQuery community to name your plugins in the form jquery.plugin.js or jquery.package.plugin.js.
I always make the dependency pretty clear in my scripts. Plus, it's a "best practice" in the jQuery community to name your plugins in the form jquery.plugin.js or jquery.package.plugin.js.
They provide a link supposedly showing that mootools is faster than jQuery. However, on my browser (Safari 3.1) jQuery is faster on most of the benchmarks, at times significantly.
Same here. Dojo is faster in my Firefox: Moo:265, jQ:261, Prototype:295, YUI:571, Dojo:190. jQuery is the fastest in my Safari: Moo:141, jQ:132, Prototype:270, YUI:425, Dojo:146
I'm using Ubuntu, Firefox 3.0.3. MooTools is faster than jQuery by 52 ms. But strange enough, Dojo beats MooTools by 144 ms!
jQuery is much faster in Chrome too, MooTools is third after Dojo.
Ok, i have used both in both open social environments and large corporate websites.
//
//
==MooTools==
-very simple, very light, almost minimalistic
-the community is more on the "creative" and "artist" side of things, the site just looks well designed
-Mootools becomes unmanageable in a mixed framework enviroment
//
//
==jQuery==
-great for the medium sized website
-unobtrusive, allows you to rename the jQuery object
-architecturally simpler, but highly abstracted
--does not map to native javascript, so its a ton of work to pull jQuery out of your JS.
-HUGE community
-hundreds of Plugins
-has inside influence with Mozilla, Webkit, and now IE
-documentation wiki, when something is broke, anyone can fix it.
//
//
==reasons to use neither==
-framework lifecycles are hard to manage right now
--websites with thousands of lines of code can be hard to upgrade to new versions
-developers need to learn Javascript 1st and then the Framework
-Caja breaks most frameworks
-Half of Opensocial users are on Caja containers
-debugging can be easier on native code.
//
//
there are things i love about both frameworks and i would recommend either of them to different people, but i think any JavaScript 'rockstar' will need to know all of the frameworks and why one is better than the other.
personally i don't like prototype (sorry), but the namespace is bloated. Why do i have a different interface for css selectors and element ids, jQuery Gets this WAY right. i am finding that i don't like attaching framework objects to element IDs, it forces you to have ids on everything which should all be unique. i am still deciding if css classes make more sense, or maybe a custom attribute makes more sense. the downside to this would be performance. ids are hashed, vs attributes are not.
//
//
==MooTools==
-very simple, very light, almost minimalistic
-the community is more on the "creative" and "artist" side of things, the site just looks well designed
-Mootools becomes unmanageable in a mixed framework enviroment
//
//
==jQuery==
-great for the medium sized website
-unobtrusive, allows you to rename the jQuery object
-architecturally simpler, but highly abstracted
--does not map to native javascript, so its a ton of work to pull jQuery out of your JS.
-HUGE community
-hundreds of Plugins
-has inside influence with Mozilla, Webkit, and now IE
-documentation wiki, when something is broke, anyone can fix it.
//
//
==reasons to use neither==
-framework lifecycles are hard to manage right now
--websites with thousands of lines of code can be hard to upgrade to new versions
-developers need to learn Javascript 1st and then the Framework
-Caja breaks most frameworks
-Half of Opensocial users are on Caja containers
-debugging can be easier on native code.
//
//
there are things i love about both frameworks and i would recommend either of them to different people, but i think any JavaScript 'rockstar' will need to know all of the frameworks and why one is better than the other.
personally i don't like prototype (sorry), but the namespace is bloated. Why do i have a different interface for css selectors and element ids, jQuery Gets this WAY right. i am finding that i don't like attaching framework objects to element IDs, it forces you to have ids on everything which should all be unique. i am still deciding if css classes make more sense, or maybe a custom attribute makes more sense. the downside to this would be performance. ids are hashed, vs attributes are not.
jQuery internals are not hard to understand, other than some of the idioms used for performance enhancements, which are documented. Not that I have looked at MooTools code for a comparison, but at least I have looked at one of them.
Point 3 fixed. Thanks.
oye el jayquieri ese ta depinga este tipo tremendo caballo
* Heard of $.extend?
* jQuery also feels like JavaScript.
* Modular...that's a good one. Very modular when it clobbers the most basic prototypes and wrecks your namespace. Everything in jQuery exists in the jQuery object.
* MooTools documentation is pretty bad. I abandoned the library because figuring out how to do anything was a chore. And there are no books on it.
I like the last argument the most: MooTools is better because it's less popular.
I wouldn't write a post arguing jQuery over MooTools, but I sure wouldn't include MooTools in all but the most animation-intensive projects because of the severe compatibility issues it causes when including non-MooTools scripts.