-
Notifications
You must be signed in to change notification settings - Fork 12
/
00a-mootoolsvsothers.txt
17 lines (9 loc) · 3.98 KB
/
00a-mootoolsvsothers.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
====== MooTools vs. Other Frameworks ======
I used to work at CNET.com, which is a pretty big corporation with a big web presence. We spent a lot of time evaluating frameworks (documented in our blog at [[http://clientside.cnet.com]] - which is now [[http://www.clientcide.com]]) and ultimately settled on MooTools.
When people ask me which framework to choose I can only tell them what my opinion is. My personal opinion is that you really can't go wrong with Dojo, YUI, Prototype, jQuery, or MooTools (there are others out there - don't snipe me because I left a good one out! Remember //it's a wiki//.). These frameworks are all good stuff. They all have their different focuses and approaches to problems. Some focus on very different philosophies.
MooTools and Prototype both believe strongly in altering the prototypes of native elements (String, Array, Function, etc. - except Object, never Object!). YUI, jQuery, and (I think?) Dojo don't do this. Both YUI and jQuery are highly namespaced, which makes them ideal for environments you don't control completely, while MooTools won't play nice with other frameworks that use function names like $ or modify the native objects themselves (Prototype being the most notable). The only downsides to the namespacing are that the code is sometimes a little verbose (esp. in YUI's case, not in jQuery's though) and they'll always be slightly slower than methods added to native prototypes, though it's unlikely that this speed hit will be noticable to you unless you are iterating over a LOT of objects. These things are not bad things, it's just the way these frameworks are.
The advantage to modifying the native elements (aside from a slight speed advantage) is that you can add methods to these elements and extend their functionality. It's the difference between "hi".alert() and alert("hi"). It's subtle, but the former example is how javascript itself works. The downside is that if you define a method (like, say, Array.each) and something else in your environment (another script) defines the same thing, one might now be broken. The positive side is a more elegant model for adding functionality to things (at least I think so).
Additionally, some frameworks focus on re-creating a somewhat traditional inheritance model. MooTools focuses on this and highly encourages code reuse and modular designs. All frameworks have methods to create reusable code - I'm not saying they don't. But the heart of MooTools is based on this, and regardless of other frameworks that may or may not also focus on this aspect, it is MooTools' primary focus. Javascript has a //prototypal// inheritance model, and MooTools (and similar frameworks) create a structure to take advantage of this model in a way that will be more familiar to developers more used to languages like Java.
MooTools also is designed in a modular fashion so that you don't need all of it to make a page work. If you only need Ajax, you can deliver less Javascript.
If I were to sum up what makes MooTools special, it's that it makes Javascript better. It focuses on the Javascript programming language and seeks to streamline it, but not deviate from the basic principles of what makes Javascript javascript. It's not trying to look like css, and it's not trying to look like C++ or Java (though its class architecture is certainly more similar to Java than traditional javascript in some ways). Other frameworks do this too (and here I'm thinking of Prototype). What MooTools has that Prototype doesn't (er, the last time I looked anyway) is a set of animation routines and a few plugins (like sortables and drag and drop). If you use Prototype, you must include both it and another library like Scriptaculous. MooTools modular design is also a //much// smaller footprint than Prototype + Scriptaculous.
I'll reiterate that choosing any of these frameworks isn't a bad thing to do. Look at the strengths of the other options. Choose the one that suits your needs and your design principles and offers the right mix of flexibility and functionality.