jQuery vs Mootools

I made the switch from Mootools after working on a project at Amazon which involved a heavy amount of OO javascript. I loved the class-based architecture that mootools afforded me. But Amazon used jQuery and one of their sites used prototype (gadzooks!). Introducing a new framework didn't seem feasable. I really looked hard at just grabbing the moo4q framework and just using the mootools class architecture.

The problem I ran into was that mootools extended the js native objects - like function, object, array, etc. No big deal, right? Except when you consider that many developers use "for (item in collection)" - which may not be the standard (dev.mozilla.org warns against this), but was the reality nonetheless.

Extending natives in js will infect every collection with additional methods which will throw errors when you traverse them using "for (item in collection)". Whether or not that is a best practice is an academic argument. In the real world, you want your code to be encapsulated, namespaced, and not to infect other code on a page that you may not have full control over. Imagine if the facebook "like" button code extended natives. How many broken sites would result?

Then I really looked hard at the YUI module pattern. I hadn't really paid much attention to this pattern until I really began to see its elegance. This article sums up the issues quite neatly. Note that mootools and prototype have essentially the same class structures, so the article speaks to both frameworks. Isaac is right about being attached to frameworks versus a deep understanding of the javascript language.

jQuery is really the obvious standard for saving time using a well-known framework. I have things I really like and dislike about it, but I think its near universal usage makes it the obvious choice.

Combining the YUI module pattern and jQuery was my choice in this new javascript toolkit. If I ever need to marshall my components for other things, I can simply write a framework-agnostic version of whatever component I need without relying on the gnarliness of writing a plugin, or being painted into a corner because my architecture is driven by a framework-dependant class structure. Using the language itself as my architecture gives me the portability I need. It would be a huge pain to rewrite my value sliders without jQuery, but I would really only need to do a search and replace and write my own versions of the various jQuery functions I use.

So you may be wondering why I am recreating things like tween, move, etc. When these script libraries are already available and have been written thousands of times already?

Well for starters, I will admit I have written move and tween functionality as far back as 1999 when I was hacking away as a noob. So I know the essence of the behaviors fairly well. I also love the mental exercise of creating something from scratch. But I am also an android/java dev, and I was able to take the easing equations from my tween architecture and implement them in a tween class I wrote myself.

Yep, that's right. I have a tweening architecture for the android that I wrote myself that can use all the flash easing equations for my transitions. When I first developed Cosmic Child, I was daunted by the limitations of the animation framework built in. Also I could find precious little help online discussing the best practices for animation. So I had to write a multi-threaded tweener with no help - not one of my friends knows java.

But I digress.

The other virtues in writing my own framework is it enables endless extensibility without having to work within someone elses plugin or jQueryUI. If for instance I decided to animate a gradient or a rotation, I could caffeinate myself, roll up my sleeves, and extend my own code to provide that functionality. Doing it within someone elses framework could get ugly and be a recipe for insanity.

So feel free to play with these controls. Pop open the DOM explorer and peek around. Send me feedback or questions if you are interested in using anything.