MooTools 1.2.2 and the New MooTools More

Written By Valerio Proietti, on Thursday, April 23rd 2009, 7:53pm

Today we’re releasing two goodies for you: MooTools 1.2.2 and the new MooTools More (


MooTools 1.2.2 is a mainly a bug fix release but it also includes an almost entirely new Class.js. The reasoning behind this is that the old Class.js didn’t play nicely with some advanced usages of this.parent() present in the new MooTools-More. We already had the script ready and tested in the MooTools 2.0 branch so we simply “backported” it to 1.2.2. Other than providing the parent fixes, the new Class also features a much more robust inheritance model, especially when dealing with objects.

For example, the objects you implement now in a class are merged if an object with the same name is found in the class prototype:

var Animal = new Class({
    options: {
        color: 'brown',
        says: 'hissss'

Animal.implement('options', {says: 'meow'});

// Animal.prototype.options is now {says: 'meow', color: 'brown'};

This is especially useful when overriding default options in classes, such as Request.

Another object-oriented feature we introduced is that now sub-objects are actually inherited Parent-to-Child. If you implement a new option in Animal, then Cat, which is a subclass of Animal, will get the new option as well, and so will every instance already existing. An example:

var Cat = new Class({
    Extends: Animal

var kitty = new Cat();

Animal.implement('options', {nu: 'one'}); == 'one' //true == 'one' //true

This obviously also applies to methods.

Additional changes to the MooTools Core in 1.2.2 are mostly minor bug fixes.


One of the new features of MooTools-More, since the last RC, is that it is now possible access the previous state of overwritten methods of classes through Class.refractor. An example:

var Cat = new Class({
    energy: 0,
        eat: function(){

Cat = Class.refactor(Cat, {
    eat: function(){
        this.previous(); //energy++!
        alert("this cat has " + + " energy");

This functionality allows users to integrate seamlessly with existing classes, and add to existing methods without the need to subclass.

We’re considering some way to make this behavior more generic for a possible inclusion in MooTools-Core 2.0.

The first RC of MooTools-More produced a lot of feedback and contributions that we’ve integrated as we prepared for our full release. Following this full release of the new MooTools More plugins, we’ll begin adding new features quickly and regularly with what we hope will be biweekly releases.

52 Responses to “MooTools 1.2.2 and the New MooTools More”

  1. dc says:

    Nice, will test this first thing tomorrow! Thanks for all the hard work guys, MooTools saves us a lot of time.

  2. Huy says:

    Yay, can’t wait to test it tonight. Thank you!

  3. Ben says:

    Always great to see an update!

    I downloaded both (core and more, uncompressed & all options selected) and there are some illegal characters in the more file.

    Moreover, when I replace the mootools core/more 2.1 files with these, my application doesn’t work anymore. Are there any changes (Class.js) changes that I’m unaware of??

  4. Mani says:

    Awesome guys.

    One question. Has the new mootools been tested against Safari 4 beta?

    Last time I checked, Class.refactor caused Safari 4 to crash big time. (Don’t know if this is an issue with Safari, mootools, or both).

    Keep up the great work!

  5. DaveW says:

    Sweet progress, now we’re cooking

  6. aaron says:

    @Ben, we ran all of it through jslint and didn’t get any errors. Can you elaborate on the trouble you’re seeing?

    @Mani, the Class.refactor things w/ Safari 4 are fixed by the new Class.js (Opera, too).

  7. Adriaan says:

    Hi guys,

    I just want to know if it is fully compatible with mootools 1.2.1 scripts?

    Thanks for the good work!

  8. Christoph Pojer says:


  9. Rexxars says:


    Thanks for your effort in making MooTools the greatest JS framework on the intarwebs :-)

  10. SixtyMonkey says:

    Very cool, guys!

  11. netweblogic says:

    Looking forward to checking it out, and wish you best of luck with 2.0!

  12. Moonkiki says:

    Moo wrok guys. I was waiting for that release… Do you know if does the cdn on google api playground is yet updated ?

    I’m using mootools and clientcide with google api playground and i wish it updatee alone whne you relaease a new version :)


  13. SamGoody says:

    Great going!!

    This is even more exciting than the name change :)

  14. Timothy says:

    Good work! The refactor is crazy, but in a good way.

  15. gonchuki says:

    nice job guys! comes just in time before I start on a new project. I just love the smell of fresh mootools in the morning :)

  16. aaron says:

    @Adriaan 1.2.2 has no breaking changes, but if you’re using the Clientcide versions of scripts that moved into More, there are changes. I’m working on a compatibility release for today.

  17. Asgaroth says:

    Great Thanks!, I love MooTools any idea when will 2.0 be released? I just cant wait, and I really need the new language feature already xD.

  18. Sean McArthur says:

    Nice work, guys. The changes to Class sound great!

  19. Ben says:

    @Aaron: I found out what is different now. I built my JS classes in a way that mimics how I built classes in Java/PHP, that is I specified class attributes outside of the methods:

    var Obj = new Class({
        some_attribute = new Hash,
            another_attribute = [],
        set : function(key,value) {
        add : function(value) {
    var a1 = new Obj;
    var a2 = new Obj;
    a1.set('key','value'); // this now sets key to value in ALL 
                //objects (including the ones created later on) instead of just in a1.

    I understand the change, and it can all be solved by declaring the attributes in the initialize method, so it’s not a major issue, however, it’s a change that made my code fail and it might happen to others :-).

  20. ksamdev says:

    IMHO, not a good update. Too much taken from Clienside. At least half of new features is not needed and thus no reason to make it available for everyone. I am a little disappointed.

    1.2.1 version was perfect one. I only found interesting in More (out of innovations):

    Class Section Date class URL handling

    The rest (new features, classes, functions) are simple custom code that can be implemented by developers and I do not see reason to put them into Mootools at all. It is not used much mostly in rare cases. Clientside was doing its job perfectly but to put all that into Mootools ????

  21. aaron says:

    @Asgaroth we’re aiming for a summer release of 2.0

    @ksamdev Sorry you’re disappointed. The overhaul of Class.js is a big deal as it fixes issues in Opera and Safari but more importantly more closely preserves prototypal inheritance. This is a big improvement, though a subtle one.

    As for -more, the key thing here is that MooTools is going to start growing it’s plugin library dramatically this year. This first batch is just that - the first batch. Moving the Clientcide libs over to be in MooTools means that they are maintained by more than just me which improves their quality and also means that bugs get addressed more quickly. Expect to see more Clientcide libs move over.

    But also expect to see new contributors in our group adding new plugins. Just as I’ve written and released dozens of plugins on Clientcide, you should expect to see other MooTools developers sharing their plugins in a way that they previously didn’t. This release may not excite you, but the change in direction should.

  22. kamicane says:

    @ksamdev I understand why you might feel that way. However, more isn’t what it used to be: More is now some sort of a repository for official and outstanding MooTools plugins written by MooTools developers. And I hope we all agree that more plugins === good, and more good plugins === better.

    Clientside was doing its job perfectly but to put all that into Mootools ????

    It’s not into MooTools core, It’s in MooTools more ( MooTools core is the same as always (

  23. Virtuosi Media says:

    Congrats on the release. Will you be announcing a process for submitting to More in the near future? I have quite a few plugins that I would eventually like to put forward to be considered after I refine and release them. There are also a lot of other worthy plugins out there that I would love to see in More.

  24. aaron says:
  25. ksamdev says:

    I agree that Core is the same (not counting bug fixes) and only More was extended.

    But mootools should be quite restrictive IMHO to plugins. In principle according to my understanding a parallel with other languages can be drawn, say with C++.

    Mootools Core - is like language itself, say C++, Objective-C, PHP, etc. One may object that JavaScript is a language and Mootools is a framework but Mootools Core completely change the way scripts are written. It looks more like an extension of JavaScript, making latter as a complete language.

    Mootools More - is a framework like STL in C++, Carbon, Cocoa in Objective-C, Boost in C++, Qt in KDE.

    Think for a second about a question: why are this frameworks so successive nowdays? B/c they have only necessary features included, say basic Widgets, Classes for Text processing, I/O system, etc. Nothing else, nothing that can be used only once in a long while. They all very well thought through. Any successive and revolutionary things are simple and easy like Mootools Core.

    I can see that Mootools More in 1.2.1 included only vital items. But version 1.2.2 has some of unnecessary functions that in principle are not needed there IMHO, say Forms Validator, Request Periodical, OverText …

  26. Virtuosi Media says:

    @aaron - Thanks. Is there any sort of objective criteria for something being “well-written” that we can have as a guideline, or at least an explicit enunciation of the general design principles, just so we’re all on the same page? I know that we can all look at the code, but spelling things out might help to minimize confusion. I agree with ksamdev in that the standards for plugins should be high because I think that it reflects on the framework as a whole. At the very least, I would vote for rigorous testing in all browsers for each plugin, which I’m sure is something that’s already being done. Perhaps plugins that haven’t had everything thrown at them yet could be given a beta label? I don’t have any problem at all adding a lot more plugins to More, though, just as long as they are high quality, because you only download the ones you need.

    Also, has any progress been made on the Forge? I haven’t seen anything on it in several months.

  27. Mani says:

    @aaron: It’s awesome that the Safari 4 issues are resolved. Safari 4’s debugger + mootools will take javascript to the next level.

    Thanks again to the mootools team for all your hard work!

  28. Bob says:

    Hi, great news! I am getting following firebug error with my application: “Asset.extend is not a function”. Has anything been changed ? Any hints ?

    Best regards!

  29. Bob says:

    After looking into the new “Mootools more” I noticed that it used to be “var Asset = new Hash({…” and now it goes “var Asset = {…” which somehow breaks my code when trying to extend it.

  30. aaron says:

    @Bob, Asset is no longer a hash (it doesn’t need to be). Just change your extension to do $extend(Asset, {…});

  31. Ollie Maitland says:

    A great update, these updates fix behaviour of the MooTools Class object that were previously difficult (and somewhat lacking documentation). The Class.refactor method looks great to be able to abstract content and data processing (which I why I presume you have given the example you do) so I’m looking forward to benchmarking that with a view of implementing. Excellent updates!

  32. Daniel Buchner says:

    Hey moo guys (and gal),

    I picked up the latest mootools more release and it was throwing errors. Does it have to be combined with Moo Core 1.2.2 to work? I then tried to take only the includes I already had without extras and it still is borking… Binds seems to be coming up as a new dependency, could that be doing it? Maybe somewhere where I have extended things? Do you have a list of breaking type combos that could cause this?

  33. Bob says:

    Thnx aaron. Keep it up!

  34. Jacob says:

    Always a great thing to see Mootools move forward, especially when it comes to elegant enhancements.

    Btw, is that a typo in the first sentence in the “More” section… “through Class.refractor” should read “through Class.refactor” ?

    Thanks again for this great framework! Jacob

  35. Kovo says:

    Does not work at all in IE6… almost as if mootools does not initialize… all MT functions fail/give errors.

  36. kamicane says:

    @kovo: I’m sorry it didnt work out for you. However, we assure you MooTools does work in ie6. If you plan on being more specific, feel free to open up a bug report in the tracker linked in our homepage.

  37. Kovo says:

    Thats fair. Sorry for being so negative. I know it does not help to debug. Im going to try and only load core.js, see if it fixes it. Maybe its a compatibility issue in More.js

  38. Jem says:

    Great news!

    Very excited about the new class changes! Thank you all for your hard work!

  39. Mark Story says:

    Great work guys and gals! I’m glad to see mootools more grow, the clientcide libraries were great but now with more eyes and hands working on them I’m sure they will get even better. Class.refactor is amazing stuff as well.

  40. 131 says:

    I’m sorry to say that, but i’m a little disapointed, i mostly agree with ksamdev, i like mootools because it provide only what i need (and a little ‘more’), i regret a “true” namespacing/repository hadn’t be set up to deal with 3rd modules. I prefer a lot insert dependencies for mt://ClientCide/Class/Class.Bind rather than seeing the “official” More heriting Application specific code, (forcing Localization is a real bad idea, for example) - A.N. that’s still excellent work, that was never my point.

  41. Ryan says:

    looks like great improvements.

    @ksamdev if you don’t like elements of More then you don’t have to use them. plain and simple. Your comparisons of More being a framework itself is severely flawed. Use what you want and ditch the rest. That’s why it’s structured the way it is.

  42. aaron says:

    @131 You must realize that this is just the start. The -more collection of plugins are plugins that the MooTools developers have authored that we want to share. They aren’t like -core which is required - you can’t use MooTools without using -core. But everything in -more is optional, and this is just the first batch. Expect to see new functionality added often. -core updates every 6 to 8 months, but we hope to iterate -more every two or three weeks, adding one or two new plugins as we go along. Hopefully we’ll end up adding one you like at some point.

  43. jay says:

    every function is wraped by Class.wrap. is that a right way? 1.debug will be very diffcult 2,it is very easy to cause memory leak.

  44. kamicane says:


    “is that a right way”


    debug will be very diffcult

    No, as it’s not any more difficult than debugging a function that calls another function.

    it is very easy to cause memory leak.

    No, as the usage of Function:bind doesnt cause memory leaks.

    On another note, we always wrapped class functions, it was just a little more convoluted in previous versions.

  45. jay says:

    @kamicane : well,I don’t agree with the process for Implements. for example,if I implement the Options class,the class function(setOptions) is wraped twice by Class.wrap. On another note,_hidden is not used. I just want to know the benefit of class.wrap for Implements.

    case ‘function’:if (value._hidden) return this; proto[key] = Class.wrap(this, key, value);

  46. kamicane says:


    well,I don’t agree with the process for Implements

    I’m sad to hear that.

    if I implement the Options class,the class function(setOptions) is wraped twice by Class.wrap

    Obviously, that’s not the case. There’s a check in place to prevent that. If it actually did wrap it twice, everything would break up, and we would have definitely noticed.

    If you have any ideas on how to improve further versions of Class, feel free to open up a ticket in lighthouse, or make a patch.

  47. jay says:

    @kamicane There’s a check in place to prevent that

    I am sorry.I can’t find the place for check that and prevent.

    anyway,I absolutely invoke class.wrap twice when I invoke the function(setOptions).you can test it.

  48. kamicane says:


    you can test it

    I assure you we did test it pretty extensively.

    Again, if you have a bug to report, please do so in our ticketing system. I get it, you dont like how MooTools works, but there’s nothing much I can do about it :)

  49. 007 says:

    Another object-oriented feature we introduced is that now sub-objects are actually inherited Parent-to-Child ?

    previous version(1.2.1) also implement that. what’s the difference of the two version? thx

  50. aaron says:

    @007 previously if you implemented an object over another one it would overwrite it entirely. If you did:

    Animal.implement({ options: { says: 'meow'});

    and Animal previously had an options object, in 1.2, options would be overwritten, not blended with this new property.

  51. lordfpx says:


    It’s always good to see progress, unfortunatly, “scroller” is not working very good with this new version… it doesn’t “stop” anymore here and on another page it’s not working anymore and I don’t know why. Uvumitextarea is not working anymore too, strange…

    So I’m back to the previous release :-(.

  52. aaron says:

    @lordpx, could you open a ticket with details?