Comments on: Mootools vs. jQuery: Speed, Smoothness, Friendliest

By: trent

trent — Wed, 07 Sep 2011 19:03:12 +0000

I believe in recent time Mootools has hurt itself in a way while trying to innovate. Its difficult for large projects to commit to a framework which has been changing so drastically over the past few releases. While Mootools has been doing some really nice work, especially in terms of inheritance and object orientation, they make it difficult to just drop in the new version and feel confident it will work (without some type of backwards compatibility addition). That being said it may be that Mootools has a completely different objective than jquery, and constant change and innovation is their goal.

I believe it is almost to the point where they need to stop in their tracks and examine where they are. Take all the good stuff, trim the fat, and create a new library. Looking through the documentation there are a lot of similar functions, at some point there has to be overhead and redundancy.

For example the Element object has methods erase, eliminate, empty, dispose, and destroy. While yes, they do different things, to me it ads confusion and 5 different functions with very similar names doing very similar things. Also with: inject, grab, adopt, etc.

I would do a good cleanup of all the methods. Move any core object extensions from More into Core. And leave More with UI type modules. Just my 2 cents…

By: Peter Drinnan

Peter Drinnan — Wed, 07 Sep 2011 11:38:07 +0000

I use Joomla and therefore I am stuck with MooTools but I find that a lot of plugins now use jQuery in noConflict mode. without noConflict mode for jQuery I think Joomla would just die off because MooTools is just a a leftover from the past that is still being dragged around by the Joomla core files.

By: jgarcias

jgarcias — Thu, 20 Jan 2011 02:24:11 +0000

I agree with Kamlesh. It took me a while to get used to jQuery syntax and its documentation was not so clear to me.
Anyways, let’s remember that jQuery is a library that grows with every new plugin and widget. It was created thinking of web designers and people with few javascript knowledge to manage the DOM easily and fast. However, jQuery can’t say it behaves the same for all browsers.
On the other hand, mooTools is a Framework created for Web Developers and Programmers in general. It is compact and can reuse code easily by creating classes, it is Object Oriented and its syntax is clear and very specific. If your website requires speed and smoothness without sacrificing performance then definitely the answer is mooTools.

By: kamlesh

kamlesh — Wed, 25 Aug 2010 06:44:25 +0000

but it takes a time to code in jquery.

By: Moises

Moises — Wed, 02 Sep 2009 08:58:38 +0000

IE8: 281;140;793;578;All the tests return errors
FF3.5: 78;76;180;190;37 (with 3 errors)
Chrome: 47;32;267;174;47 (No one returns an error)

By: trent

trent — Fri, 26 Jun 2009 15:28:35 +0000

I have a bit of experience with all of the above

By: EW

EW — Fri, 26 Jun 2009 14:48:00 +0000

As a technical recruiter in a very niche space, that being web development in Orange County, I do my best to learn technologies and the differences between them. I really appreciate this blog because currently I am working with the largest employer in Orange County on a very high-end Web 2.0 UI position where Mootools is a MUST.

Many of the front-end Asp.Net developers I’ve spoken to have had exposure to JQUERY, but not Mootools. Do you guys have any suggestions as to where I can find a 6-figure front-end developer with Mootools experience tied to an Asp.Net application?

I really appreciate the thoughts, and think I might start teaching myself light code as a side project!

By: dan

dan — Fri, 29 May 2009 15:28:55 +0000

http://owljs.org/speed/ is kinda broken – stopped after 6 tests

FF3 (3.0.10)

By: choncon

choncon — Wed, 27 May 2009 15:48:01 +0000

Here is other test page, better:
http://owljs.org/speed/

By: trent

trent — Tue, 12 May 2009 11:58:11 +0000

I completely agree. You definitely have to examine what you need for each project before committing to a framework.