Tuesday, January 27th, 2009

MooTools. What up?

Category: MooTools

Aaron Newton has written two interesting pieces on MooTools.

First, he gives us history on the library as a way to explain where it is today, and why some people are concerned that the core isn’t moving that fast (which others would call a feature!):

Because the current state of the library is very stable, the core developers are focused more on the things they use MooTools for, rather than improving the framework itself. Development on the framework core is driven by need mostly, and right now, MooTools 1.2 serves the needs of those of us who develop it quite well. That’s not saying that there’s no room for improvement (there are certainly bugs that can be fixed in Lighthouse, but most of these are minor). But for the most part, due to the focused nature of the MooTools core, there’s not a tremendous need to churn through the code constantly.

In other words, precisely because MooTools itself is so flexible and because the core developers are so focused on delivering only what is needed in the framework and not adding features for their own sakes (and relying on the rest of us to fill in the gaps), it means that to a large extent, the MooTools framework doesn’t need a lot of maintenance or enhancement. It does what it does, it does it well, and for the moment, it does not need more than that. Perfection is not attained by adding everything you can, but rather by removing everything you can. Or something.

Then we get to the future, and Aaron talks about the 1.3 upgrade path:

The MooTools 1.3 Upgrade Path
Friday, January 23rd, 2009 @ 2:15 pm | filed under: MooTools | ShareThis

In the last week or so Valerio and others (myself included) have been working on the changes that are headed for MooTools 1.3. You can dig around in git-hub in various developer branches and see some of this stuff flying around, but frankly, it’s all in rough draft mode and is likely to change.

One of the points of discussion are all the $ methods. $type, $lambda, $try, etc. are all in the global name space and kind of just… there. They exist as stand alone methods because, by and large, they don’t really belong anywhere. In an effort to both clean this up a bit so that methods are where they “belong” as well as to clean up the global namespace a little, Valerio and others are discussing where to put these things.

Posted by Dion Almaer at 4:11 am

3.7 rating from 36 votes


Comments feed TrackBack URI

Changing $stuff to $.stuff is kind of the simplest and most obvious way of clearing global name space I can think of.

Comment by nea — January 27, 2009

i think that mootools 1.2 reached a so great level of perfection, that push the born of thousand of plugins… As it happened to 1.11 to 1.2 they are so great in maintaing retrocompatibility, that we have to no worry about it…

Comment by nunziofiore — January 27, 2009

I think you should have included some other important quotes from that article, such as what is being worked on (ie, it’s not just stagnating).

But it’s not like nothing is going on. Just four days ago I had a 3 hour debate with Valerio about some of the inner workings of Class that we’re busy churning away on that will improve it dramatically (albeit in a way that few will notice).

Comment by tj111 — January 27, 2009

Improvement can always occur. If MooTools can improve performance and speed, that will be a big plus.

Comment by cssProdigy — January 27, 2009

The most important point is not clearing the namespace, but putting these utility functions where they belong, for a better and consistent API. In addition, MooTools currently extends the $ object with different functions for the different types of arguments $() accepts. For example, $.element is internally used when a call like $(domelement) is made, and $.string for $(‘myid’). Finally, API-wise, $.exec() for example does not make a lot of sense, considering $ is an element retrieval function.

Comment by Appletalk — January 27, 2009

Leave a comment

You must be logged in to post a comment.