Switching from MooTools to jQuery

Update: This is a really old post; I don't develop apps this way anymore, and I hope no one else does either.

I have been using the MooTools JavaScript framework for a while, but I recently decided that I would try switching over to jQuery. The impetus for this switch came as I was working to optimize one of my intranet applications for broader use.

I maintain many web applications that were originally developed strictly for use at what is now a division of a larger conglomerate. All of these ColdFusion applications are running on a single web server, and as our sister companies have become interested in using them I started to consider the implications of an expanded user base. After some analysis I concluded that, though these applications were designed for maintainability over scalability, the current equipment could adequately handle the expected load increase. Once I was confident that the local infrastructure could support an increased load I began to think about the clients.

One of the new facilities that will be using these web applications is located in Mexico, and available bandwidth to that location can get tight at times for a couple reasons. First, the bandwidth on the WAN going into that facility is less than what is available in the US. Second, the traffic is regulated so that the our SAP traffic gets the highest priority, and web traffic gets the lowest. Since bandwidth could be a concern, I started looking for ways to optimize my pages for size.

As I looked for ways to minimize network utilization a lot of ideas came up, the least of which was switching JavaScript frameworks. I have plenty of opportunities to decrease my network footprint. The first, and easiest step, was to compress existing files. The next item on my list was continuing to expand the use of AJAX (or more maybe appropriately AJAJ, as recently I have preferred the use of JSON over XML). In truth, switching frameworks would save me very little bandwidth. But, it was through the process of examining at the detail level what we were doing that I started evaluating JavaScript frameworks again.

For the most part, I was only using the framework to perform minimalistic DOM manipulations and XMLHTTPRequests. We never wanted the intranet web applications to appear too flashy, otherwise our internal customers would demand that we just give them a "basic" web page in half the quoted time. Therefore, I was not taking advantage of many of the great effects that MooTools offers. I understand that MooTools also offers easy ways to create and extend classes, but I have been using regular custom objects in JavaScript. So, it seemed that my spartan designs weren't taking advantage of MooTools perceived strengths. I just wanted a quicker way to access the DOM and some shielding from cross browser quirks.

So, it was from the perspective that MooTools was too sophisticated for my needs that I began to look for other frameworks. After looking at many frameworks (Dojo, GWT, jQuery, Prototype, YUI), I settled on jQuery. Not to say that jQuery is not sophisticated, it is just that jQuery seemed to focus on the aspects that I needed and left everything else to be loaded as a plugin. From a file size perspective, jQuery is only marginally smaller than the MooTools core version that I was using. From what I was reading, jQuery was supposed to be marginally faster than MooTools, but so far I don't have complaints about either.

Besides for technical considerations, there was one other factor that pushed me towards jQuery. The size of their community and the amount of corporate "endorsement" they seem to have. Normally I like to judge subjects on their merits rather than popularity, but the fact of the matter is that if I were ever to leave my company they would need someone to maintain the code. The larger the community behind a framework, the more likely they will be to find someone capable of managing it. Or, if nothing else, the next person who is responsible could find documentation online. I must say that I do personally prefer MooTools' online documentation format, but there just seemed to be more support in general for jQuery.

I am just getting started with jQuery, so it is possible that I could end up coming back to MooTools again. And, I am not ripping out all of the dependent code that we currently have, so I will be working with both and as I move forward I will document my progress.

Comments (newest first)

Thanks for the great tips. I have been using the YUI compressor, which is good, but makes it difficult to troubleshoot issues in the production environment. I would like to switch to gzip compression on the server as suggested, it's just a matter of convincing the server guys (everyone has a full plate lately with the cutbacks in our industry).

Some of our users have no access to the Internet, so I don't know if using Google's APIs would work for our intrant applications. But, I have never used those and am interested in at least trying them out.

Thanks again for the advice!
I'm a mootools user, but I also plan to switch us over to jquery at some point... whenever we have a little resource bandwidth. The bigger community is crucial, and mootools just hasn't treated their community very well.

Also, if you're not already, you should be using google's ajax libraries api and letting them serve your framework javascript directly. As more websites use this, it's very likely that your users already have the framework cached in their browser. With the popularity of jquery, it's almost a certainty (assuming your users are free to visit other websites).
I have to say - it's admirable that you're thinking *long term* and veighing on a future replacement's likelihood of understanding jQuery based on its popularity.

I've been big into MooTools myself, and have played with jQuery - it takes a little bit of digging in the docs to figure out how to duplicate your code between the two, but it's not impossible or overly difficult.

That being said, have you looked into gzipping your JavaScript components for an added squeeze? I've noticed I can often use and uncompressed JS file (with all my notes and comments explaining how it works) and gzipping it makes compressing it almost irrelevant (unless you're trying to squeeze every kb you can, in which case yui-compressing with gzip makes sense).

Best of luck!
Published: 2009-03-05