What is this crap?<p>* Heard of $.extend?<p>* jQuery also feels like JavaScript.<p>* 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.<p>* MooTools documentation is pretty bad. I abandoned the library because figuring out how to do <i>anything</i> was a chore. And there are no books on it.<p>I like the last argument the most: MooTools is better because it's less popular.<p>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.
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!<p>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?!?!<p>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.
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.<p>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.<p>3. Speed is debatable, but in either case, they're quick enough not to matter which is what you need.<p>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.<p>5. $("<a />").attr("href", "<a href="http://juliocapote.com" rel="nofollow">http://juliocapote.com</a>");<p>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.<p>7. jQuery's documentation in general is excellent.<p>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.<p>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.<p>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.<p>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.
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.<p>I made the switch about a year ago and haven't looked back since.
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.<p>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?<p>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.<p>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.<p>We're spoilt for choice these days: best to sample as many js libs as you can and stick with whatever feels right.
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.
Ok, i have used both in both open social environments and large corporate websites.<p>//<p>//<p>==MooTools==<p><i>-very simple, very light, almost minimalistic<p>-the community is more on the "creative" and "artist" side of things, the site just looks well designed<p>-Mootools becomes unmanageable in a mixed framework enviroment</i><p>//<p>//<p>==jQuery==<p><i>-great for the medium sized website<p>-unobtrusive, allows you to rename the jQuery object<p>-architecturally simpler, but highly abstracted<p>--does not map to native javascript, so its a ton of work to pull jQuery out of your JS.<p>-HUGE community<p>-hundreds of Plugins<p>-has inside influence with Mozilla, Webkit, and now IE<p>-documentation wiki, when something is broke, anyone can fix it.</i><p>//<p>//<p>==reasons to use neither==<p><i>-framework lifecycles are hard to manage right now<p>--websites with thousands of lines of code can be hard to upgrade to new versions<p>-developers need to learn Javascript 1st and then the Framework<p>-Caja breaks most frameworks<p>-Half of Opensocial users are on Caja containers<p>-debugging can be easier on native code.</i><p>//<p>//<p>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.<p>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.