Tuesday, January 27th, 2009
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