

Why MooTools (or Why not JQuery) - reazalun
http://juliocapote.com/post/52467447/why-mootools-or-why-not-jquery

======
thomasmallen
What is this crap?

* 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.

------
jamongkad
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.

~~~
mechanical_fish
_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!

------
halo
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.

~~~
halo
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?

------
notanumber
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.

~~~
while
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?

------
astrec
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.

~~~
Jasber
My biggest problem with jQuery plugins is people using $() instead of
jQuery(). This breaks functionality for people like me who insist on using
jQuery().

~~~
LogicHoleFlaw

      jQuery(function ($) {
        $('#someId').doSomething(); // blahblahblah
      });
    

That's my preferred method of invoking jQuery. I get the convenient $() syntax
without clobbering namespaces.

~~~
thomasmallen
Sorry, but you're both wrong. Best practice is this:

    
    
      (function($) {
          // Plugin code
      }) (jQuery)
    

And you'll see it in UI and most other good jQuery plugins.

~~~
LogicHoleFlaw
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>

~~~
humanchimp
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.

------
compay
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.

~~~
subbu
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

------
jdavid
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.

------
gregwebs
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.

------
jcapote
Point 3 fixed. Thanks.

------
juankaviviri
oye el jayquieri ese ta depinga este tipo tremendo caballo

