Tuesday, March 10th, 2009

More MooTools in MooTools More

Category: MooTools

MooTools Core developer Aaron Newton recently took on the task of coming up with a complementary library to the MooTools framework that would provide enhanced capabilities beyond what the standard JS MooTools core lib could, or should, provide. The results is a new project called MooTools More which aims to provide Moo developers with a set of official plugins which are well documented and supported by the team. Yesterday, the More team released their first beta which currently includes:

  • Class extensions including a Binds mutator, easier refactoring, chain pausing and more.
  • New Native extensions including more love for String and Array, plus a fully featured Date Native and a URI extension to make managing links downright fun.
  • More Element love with help for managing text selection and relative positioning (put this box’s lower right corner next to the upper right corner of that other box…)
  • Form love including a robust and extensible form validator and a class for displaying hint text over an input.
  • Extended Request functionality including JSONP support and Queuing.
  • Support for language localization for classes that output text (days of the month, months of the year, form validation errors, etc)

You can download the files here:

If you’d like to get involved in the project, the team has created an official wiki which outlines how to help and submit code changes.

Posted by Rey Bango at 11:59 am

4 rating from 42 votes


Comments feed TrackBack URI

Actually, MooTools–up to 1.11–already had a complimentary set of ‘enhanced capabilities.’ It was not until the release of MooTools 1.2 Beta 1 in Nov 2007 that the ‘enhanced capabilities’ was separated from the framework, thus creating Mootools-Core and Mootools-More. The move to separate -core from -more was one borne out of practicality: -core contained the essential and -more the other nifty stuff.

And while Aaron did create a complimentary library, it was a third-party one called ClientCide libraries (the history of which is another story). In the recent move to create Mootools More as a separate project, much of the ClientCide code was officially adopted and merge with what is -more from 1.2.

So while the Mootools More project (note the lack of a hyphen) could be considered as a “new” project, bulk of it is really just an improvement of the ClientCide library, the old -more and some parts of -core that are now moved to more. Or to put it more bluntly, Mootools More is just a restructuring of much of the Mootools codebase–meaning almost all of the awesomeness from the new project was already in Mootools (since 1.11 at least) to begin with.

Comment by GarrickCheung — March 10, 2009

+1 Garrick

Aaron is doing a stellar job on the project though.

Comment by sixtyseconds — March 10, 2009

Quick glance at the source and I am find things like:

if (Browser.Engine.trident){
var range = this.createTextRange();

I understand that this is beta, but surely this is a case of browser detection that is so obviously unnecessary, its unforgivable. Is this not sufficient:

if (this.createTextRange){
var range = this.createTextRange();

Please, for the sake of good practice, update this!

Comment by RyanMorr — March 10, 2009

@Garrick is correct that vast majority (but not all) of the new MooTools More is basically a combination of the old mootools-more and about 1/3 of the Clientcide libraries. But the real news here isn’t that these scripts have moved and been cleaned up a bit, but rather that More is now decoupled from the development of the Core and that the More project will be growing constantly and iteratively. Expect to see releases for MooTools More every two or three weeks, while the Core continues to be updated every several months.

@Ryan you make a good point. We’ll discuss it and see if we’ll change it, but I think your point is perhaps a bit over-dramatic. The main point is that the methods work for all the browsers we support. I realize the topic of browser detection vs. feature detection has been debated a lot here and I don’t mean to start off that war. I’m a little less interested in whether or not the methodology here meets the general public’s approval and more interested that it works. We can change how the methods work tomorrow if we decide, but so long as they continue to work, that’s all that matters.

Comment by anewton — March 10, 2009

@anewton, It isn’t so much feature testing in the example I provided as it is object detection. The 99% rule is bogus, all I had to do is upgrade my browser version to figure that out.

Comment by RyanMorr — March 11, 2009


Be careful what you view as the “right way” in relation to feature sniffing and browser detection bro: I recently started to write a FF extension and was mandated to use jQuery 1.3 for it (I prefer Mootools). Low and behold jQuery’s new “feature detection” proved to be an Achilles Heal…what happened when I tried to pull jQuery 1.3 into the FF extension shell? jQuery started hyperventilating, then it passed out and hit its head on a bar stool on the way down because in the browser chrome its feature sniffing is completely borked! Holy-f_cked-up-js Batman! I of course didn’t mind because I prefer Moo and when I went to include that lib…sha bang, sha boom, thong song! That shit worked like a charm.

Comment by csuwldcat — March 11, 2009

FYI, I’ve changed this script (in github) to use feature detection after a bit of discussion with the team. Thanks for the feedback.

Comment by anewton — March 11, 2009

Leave a comment

You must be logged in to post a comment.