I’ve just finished swapping out the Javascript library used on BigHugeLabs.com from Prototype/Script.aculo.us (P+S) to MooTools and I thought I’d share my reasons as well as my impressions for the benefit of any other developers thinking of following a similar path.

A little background...

BigHugeLabs.com allows visitors to use dozens of “toys” to make fun projects out of their digital photos. On any given day it is visited by around 40,000 people and approximately 40% of those are first-time visitors.

Why switch?

I really like Prototype and Script.aculo.us but my main problem with both of them is their bulk. They just do way more than I need. The entire P+S stack (I was using version 1.6.5) comes in at over 250k. It’s monstrous and those 16,400 new users every day had to download the whole thing. I don’t even want to think about what the site was like for dial-up or mobile users.

I also have a strong dislike for the Script.aculo.us documentation wiki. “Clear” and “organized” are two adjectives I can’t imagine anyone using to describe it.

But a bigger problem with Script.aculo.us than the documentation is that the visual effects sometimes stutter and skip. Even the Script.aculo.us home page staggers and stutters into view as the page loads. In one case recently I was trying to simply slide a small DIV about 100 pixels down a full page. No matter what I tried, I just couldn’t get the effect to run smoothly. With MooTools, it just worked. Granted, it could have been pilot error, but the bottom line is that MooTools gave me exactly the result I wanted.

A final swaying factor were some of the built-in effects. In particular, I think the Bounce easing transition, Accordion, and Fx.Elements are awesome.

Implementation

Switching out the libraries was straightforward. MooTools uses similar syntax and has a 1:1 replacement for everything I was already doing with P+S (except one). Swapping libraries was a simple matter of searching for P+S code and swapping it with equivalent MooTools code. The one exception is that MooTools doesn’t implement Element.hide() or .show() out of the box. Fortunately, it’s a simple workaround (by extending the Element class, for example).

The entire conversion took about 12 hours spread over four days. That includes some extra time I took to rewrite the few XML proxies I had as JSON and refactoring where it presented itself. I thought about abstracting all of the MooTools Javascript into my own classes so that if I ever decided to switch frameworks again all of the code that would need to change would be in one location. But I was already finished with the entire conversion before that thought got any traction. Anyway, it would have probably tripled the amount of work for a dubious payoff (I may never switch from MooTools).

Final thoughts...

All combined, the switch has allowed me to shave 190k off of BigHugeLabs.com’s Javascript, shrinking it down to a much more reasonable 56k. That’s a savings of almost 3 gigabytes of transfer per day. And the experience of first-time visitors should be improved as the site loads more quickly for them.

MooTools’ superior documentation and demos made it a breeze to pick up. It’s not perfect, but most everything works as advertised.

From a construction perspective, working with it just feels better to me than P+S. It’s a subtle point but MooTools just seems to be a better fit for my style.

Comments

1. JGJones on 2007-12-19 11:34:32 wrote: I prefer the MooTools myself too - it’s smoother and more responsive too from an end-user point of view. " better fit for my style." - you say Mooo! a lot? /me runs. ;-)

2. RahulMax on 2008-01-29 03:27:56 wrote: Same opinion here.I’m just a starter in web designing and recently started doing javascripts. I didn’t know that mootools existed until i was fed-up with Scriptaculous and desperately googled for some other libraries… Your 3GB per day transfer rate savings is wonderful!!Mooooo!!