At the beginning of 2009, MooTools was a single thing - one library maintained by maybe 5 or 6 people who actively pushed code into it. It’s hard to reconcile this with where it is now. Let’s see, first, MooTools was split into two in February - MooTools Core and MooTools More. The principal developer, Valerio Proietti (the creator of MooTools) focused most of his energy on MooTools Core with the help of several other developers, and I’ve focused most of my efforts on MooTools More, the official plugins for the library. While Valerio and others continue to refine the core, the -more team has brought the number of plugins for MooTools from around a dozen to nearly sixty.

Part of what changed was our active recruitment for people to be involved in our development community. Our developer mailing list went from about a dozen people on the mailing list with 4-6 people actively pushing code into MooTools to around 50 developers on our mailing list with somewhere around 15-20 people actively pushing code. These numbers tell part of the story; of tremendous growth - as much as 400-500%.

At the same time, there have been a lot of new things happening that may be slightly off your radar. For instance, a MooTools user named Piotr Zalewa showed up one day out of nowhere with a paste-bin app for MooTools that lets you create stand alone working code examples with HTML, CSS, and JavaScript which he launched at http://mooshell.net. Immediately upon joining the developer list he started adding features and working with others on the list to make it better and better and the result has been phenomenal. The usefulness of our user mailing list has gone up dramatically as users show up asking questions with working examples (or, more often, broken ones that they need help with). Other users can edit the shell and save a new version, responding with a link that shows exactly how to solve the problem. Daily we see how MooShell has affected our ability to help our users and we’re happy that MooShell is now an official MooTools project. Expect to see these working demos in our documentation early this year (to a demo of this in action just scroll down to the “Demo” section here).

There are a number of other new additions to the library that are still somewhere between pre-alpha up to beta states. There’s the Depender application that lets you build libraries on the fly. MooTools ART, a canvas adapter for MooTools, continues to come along. Slick, MooTools’ new selector engine is in testing phase and we hope to see it released early in 2010. We just released the MooTools 1.1 to 1.2 Upgrade Helper which should help those still using 1.1 to adopt the current release. MooTools 2.0 is still under heavy development, but we’ll be releasing MooTools 1.3 early this year with some new features. Even stuff that we don’t release, like a new search engine for mootools.net.

And then there’s the MooTools Forge, our new user-created plugin catalog. The Forge alone would be enough for me to call 2009 a big year for MooTools. It is absolutely what MooTools was really missing. Developer Guillermo Rauch cranked out a slick bit of technology that closely integrates with Github and makes it easy for developers to update and maintain their plugins. In only a month or so there already 100 plugins in there with more added daily.

All of these things, this proliferation of output and creativity, stem from one small change that happened early in the year. Something that in many ways no one outside our developer community would know about or even have noticed: MooTools went from being the work and property of one person to being a project owned by its community. For the roughly two years previous to 2009 that MooTools was around, it was developed almost entirely by Valerio. It’s true that other people, such as myself, contributed to the work with Valerio as the gatekeeper. The MooTools code has always been elegant and easy on the eyes to actually look at, and this grooming was a product of that single guardian who cared deeply that the code always be as clean and elegant as possible. It was uncommon for anyone to make a commit to the project without Valerio coming through and tidying it up, always making it just a little better and in the process teaching us how to be better developers.

In February of 2009, the first little step happened with the split of MooTools Core and MooTools More. The code in -more is still methodically groomed and maintained, but not by Valerio. The -more team does this service for each other, each checking over the others’ work and making it a little better, a little leaner. As we actively recruited people into the developer list, we had more and more people working on different things. Selector engines, paste-bin applications, plugin libraries, canvas adapters, a search engine for mootools.net, test frameworks, and more; it all became far too much for one individual, even two or three, to be the gatekeepers.

At my job at Cloudera, I have the privilege of working with Doug Cutting, who brought Lucene, Nutch, and Hadoop out through the Apache Foundation. Doug spent a bit of time with us talking about how Apache develops open source software and after a few weeks of work we produced a founding document for how MooTools projects will be developed and governed. This document, our “charter” is influenced heavily on Apache’s processes, though not as rigid as we don’t have their scale issues (yet!), but it’s had a remarkable influence on our development team. All the things I’ve listed in this lengthy post have sprung up as a result of this change. What started as a split (-core, to –more and -core) has now grown into a federation of projects that we govern as a group. And that federation of projects, that freedom to just make things happen, is now filtering out into our community with the Forge.

So when I look back on 2009 and ask myself what MooTools accomplished, I look at all the things we released, all the code we wrote, and all the new people contributing and think of those things as side effects. The thing that really happened in 2009, and it took all year to do it, was MooTools became a project owned by all of us. Valerio is still guiding it, but we’re no longer rate limited by his ability to pay attention to all we can create. And so projects move forward with their own teams, and plugins get released by enterprising individuals on the Forge, and users send us bug reports using MooShell to demonstrate the problem. All these things are spectacular. But what really happened was that (tiny at first) shift to belonging to everyone who contributes.

When I consider 2010, my mind is awash. In one year our team grew by several hundred percent and the number of projects being actively worked on did the same. Our community has better tools to share their work. 2010 is going to be less about MooTools itself and far more about what we, as a community, make with it. If 2009 was all about the MooTools developer community coming together and taking things to the next level, 2010 is going to be about our community of users, and the possibilities there are endless as far as I can tell.

So consider this a challenge, an open invitation. Surprise me.

Several weeks ago I had the pleasure of addressing a large crowd of Joomla developers at their conference in New York. The Joomla community is a fantastic bunch and the time I spent there talking about MooTools was perhaps some of the best I’ve had. The people present were very interested in MooTools and as well they should be. Joomla ships with MooTools built in and there is a large community of Joomla plugin developers who end up using MooTools because of it. Unfortunately, it still ships with 1.1.

A few months ago we, the MooTools team, decided to start focusing more on helping the Joomla community with their upgrade woes and began to re-address the compatibility code for 1.1 to 1.2 in earnest. When I spoke in New York to the Joomla team there and said that our goal was to have something to help them upgrade available by the end of the year, there was, dare I say, rawkus applause.

Well, here it is, Dec 31, and I’ve kept my promise. With the help of many of the MooTools Dev team (Chris Pojer, Darren Waddell, Nathan White, and others) we’ve finally got a compatibility layer that actually works and, more importantly, helpes you upgrade.

First, it logs warnings to the console (such as Firebug) and helps you find the places in your code that need updating. The script is not a compatibility layer as much as it is an upgrade helper. Hopefully this will help us retire 1.1 for good.

Secondly, easily half of the work, if not more, was spent creating a test environment for it. When MooTools 1.1 came out, we didn’t have a test framework to run against the code. When we released MooTools 1.2, we did, and it shipped with tests for most of the functionality included. So to make this compatibility layer, we had to go write tests for all of 1.1 (about 400 individual tests), then write the upgrade helper, compatibility code, and then run the tests from 1.1 against the 1.2 code base with the upgrade helper loaded. Creating the tests for a deprecated code base is no fun but I’m glad we did, otherwise the compatibility code would be in far worse shape.

But as a result of all that work by the MooTools Dev team, I can say that the helper script we released today is likely to cover about 95% of all the changes between 1.1 and 1.2; the other 5% being essentially un-hackable. Still, for most developers, it should cover all their work.

Seeing 2010 roll in with people dropping 1.1 is a great way to start it. If you’re still running 1.1, now is the time to move on.

You can find out more about the upgrade helper on the MooTools Blog.

For those of you who didn’t notice, MooTools released it’s long vaunted user generated plugin system today - The MooTools Forge [accompanying blog post].

First, this is just awesome news, and a big tip-o-the-hat to Guillermo Rauch, who wrote the app. For those of you who have been around our community for the last three years, the forge was always something we were “working on”. There have been many versions created over the last few years, and many other community created initiatives, that didn’t quite do what we wanted. Guillermo jumped in and built a great system, closely integrated with git, that, well, it kicks ass.

The Clientcide Libs

I’ve uploaded four plugins to the forge as part of the launch (Tabswapper, MenuSlider, HoverGroup, and dbug). I chose these because they were just the simplest plugins that I could release; they just don’t depend on much and they do one thing. Releasing Stickywin, for example, represents a much greater challenge.

One of the things the forge requires is individual git repositories for each plugin. This means that I have to split up my one big repo into lots of little ones, rewriting my download builder, docs engine, and other tools to make these things easy to manage. Consequently, moving things into the forge is likely to be a long and laborious task. For the moment, the four plugins I’ve released are just duplicate files of what’s in the single Clientcide repo, but eventually, once I’ve split them all up, I’ll remove all the files from the Clientcide repo and then include them all as submodules. For the time being, they will be duplicates, and releasing them will happen as I have time (which is not very much these days).

Good Times

I’m really excited about MooTools here at the end of 2009. I hope to make a longer post here looking back at all we’ve done this year, but certainly the Forge release will be a big highlight. 2010 has a lot of interesting things coming, I’m sure, but perhaps the thing I’m excited most to see is all the good things that the MooTools community creates and uploads to the Forge.

2009 has been a very busy year for MooTools and I’ve spent much of my time working on things other than Clientcide (like MooTools and Cloudera Desktop). MooTools More continues to grow - the latest releases (1.2.4.1 and 1.2.4.2) are full of all sorts of new features (over 50 plugins if you exclude all the date localization files), but you’ll probably recognize some old friends. Mask looks a lot like Modalizer, Spinner like Waiter, Form.Request like Fupdate, etc. That’s because in an effort to make MooTools more feature rich I and the other MooTools developers have been moving our work into the official project.

As such, Clientcide 2.2.0 is really a bug fix and compatibility release. There are very few new features but that’s because, in a way, all the new features are in MooTools More.

Here’s what’s new in 2.2.0:

• Modalizer is deprecated in favor of Mask
  • compat file is just the deprecated library; does not convert to Mask instances but rather just returns Modalizer as it always did
• StickyWin.Modal has new options for Mask; this is a breaking change
• Removed Element.Delegation (now in MooTools More; unchanged)
• Deprecated DollarE
• Deprecated DollarG
• Fupdate is now Form.Request in MooTools More; see compat files
  • Fupdate.Prompt is now Form.Request.Prompt
  • Fupdate.Append.Prompt is now Form.Request.Append.Prompt
  • Fupdate.AjaxPrompt is now Form.Request.AjaxPrompt
  • Fupdate.Append.AjaxPrompt are now Form.Request.Append.AjaxPrompt
• FormValidator got renamed in MooTools More to Form.Validator (the old name is preserved); updated FormValidator.Tips to Form.Validator.Tips (again, the old name still works).
• Collapsable is now Collapsible (that’s correct, I cannot spell). The old name is preserved (though the file name itself changed; update your build scripts).
• HtmlTable moved to MooTools More. No breaking changes, but the -more version has new features.
• Added Italian, Spanish translations for Simple Editor
• New StickyWin features
  • Z-index Ordering!
  • changing default value for allowMultipleByClass in StickyWin to true
  • Added setCaption method to StickyWin.UI
  • onUpdate event for StickyWin.Ajax
• added detach method to MooScroller
• dbug should now work in IE8
• offset options are now additive for pointy tip
• numerous bug fixes

For the most part compatibility is preserved. There’s that one breaking change in StickyWin.Modal where the options for the modal layer are different. I can only test this so much, so if you find areas where the compat files don’t provide coverages, please file a ticket.

I’ve also updated the download builder on Clientcide to use the now open source builder called MooTools Depender. Check out the blog post on MooTools.net if you want to know more about it. One cool thing about that you might find useful it is the ability to re-download a script you created with a given url. Now, when you download a script, the header includes a url to re-download the library with the same selections. This should make upgrading libraries a little easier.

I know what you’re thinking. It’s been 3 months since I last posted. My last post was all about how you can pay it back to MooTools, and since then I’ve been taking my own medicine.

MooTools 1.2.4 released today along with MooTools More 1.2.4.1. In this release, I’ve pushed 274 commits into the codebase (out of 398). There’s a LOT of new features in it, but some should look familiar.

For instance, my Waiter class is there, now called Spinner. And my Modalizer class is there, now called Mask. Oh, and Fupdate finally got a decent name; it’s Form.Request.

But there’s a lot of other stuff in there, and that’s not even the only place I’ve been cranking. There’s also a dependency loader for lazy loading MooTools scripts called Depender. There’s an all-JavaScript version and a server side implementation (that’s way faster; available as PHP or Python/Django).

And then there’s MooTools ART, which is awesome. It’s the beginning of a UI system for MooTools plugins.

Rather than go over all this stuff in detail though, I’ll just point you to the blog post I wrote over on the Cloudera Blog, which outlines all the cool stuff we’ve been building with all these new toys. There’s even a fancy screencast.

The Clientcide Libs and MooTools 1.2.4

But you’re probably asking yourself, what about the Clientcide plugins? Well, obviously I haven’t forgotten about them. First and foremost, it should be rather obvious by now that much of my work is now being pushed into MooTools instead of released here. It makes sense mostly, as the plugins get reviewed by the other MooTools dev team members and the result is always better. There are still a few plugins here that don’t belong in MooTools More and to that end I’ve been maintaining them, occasionally adding features.

The current version of Clientcide - 2.1.0 - should work fine with 1.2.4. The catch is that the upgrade path to switch to the new instances of the things that moved (for instance, Waiter moving to MooTools More and now being called Spinner), isn’t super duper easy. I do plan on authoring compat layers for some of these scripts, but not all of them.

What does this mean if you’re using these libraries? Well, you can keep using them. But I’m not going to maintain Waiter, for instance. I’ll focus on Spinner. Converting from one to the other should be relatively straight forward, but since they both work in the same space (because they have different names), you should be able to use either one or both.

Look for a release in a week or so of the next version of Clientcide for MooTools 1.2.4. There are several bug fixes and I will have some compatibility layers for some of the plugins. In the mean time, you should be able to update to 1.2.4 without any issues.

The Exceptions

The only exception here is that MooToosl More 1.2.4 includes a few plugins that are almost direct copies of what I have in 2.1.0, namely HtmlTable and Element.Delegation. If you’re using either of these scripts, you can just ditch the copy you get from me and use the ones in 1.2.4.

I get a lot of emails and tweets saying how awesome MooTools is. Sometimes people want to donate money or give us credit on their work in some way. Others ask how they can contribute. If you want to “pay it back” to MooTools, you can do so by:

• fixing bugs in our ticket list (lighthouse)
• submitting patches for bug fixes and features
• writing blog posts about interesting things you learn in the process of developing w/ MooTools
• get involved in our user forums and help those who understand it less than you
• release code you author that others might find useful

We don’t need credit in any overt manner. Your work should be all the credit we need. We would much rather see you involved in the community than any other form of gratitude.

I mentioned last week that I’ll be speaking at the Rich Web Experience in Orlando in December (1-4). Their site is finally online and you can see the lineup. It’s good stuff. I think this is shaping up to be the best JS conference so far this year, but of course I would say that.

Also, there’s this:

FYI…. Rich Web Experience 2009 is the first to offer all-inclusive pricing for attendees - registration, flight (continental U.S.) and 3 nights lodging! This offering allows individuals to get approval without having to jump through the traditional travel hoops!

Visit the site for more details and to see the schedule and stuff.

You can also catch them on twitter: @richweb2009.

Many of you may have noticed looking at the schedule of speakers and events at the Ajax Experience (this September in Boston) that many of the speakers from previous years are not present. I will not be attending, and the same is true for the Prototype team, the Dojo team, the jQuery team, as well as speakers like PPK and others. There’s a reason for this that I won’t go into, but I think it will suffice to say that the conference is shaping up to be a little less… complete this year.

Instead I’ll be speaking at the Rich Web Experience in Orlando, FL, Dec 1-4. I’ll be giving a few talks there (3 or 4) and it’s looking to be like a much more interesting conference. If you’re into MooTools I hope to see you there and if you’re into JavaScript and rich web apps in general, then I think the conference should be worth the trip. There’s not a lot of detail on the RWE site yet, but I hope to see some stuff up soon. You can actually get past the “coming soon” page and into the bios of speakers from the last conference and get an idea of the kinds of topics covered.

If you end up going to the Ajax Experience this year, please let me know how it goes. I’m curious to see how it fairs without any representation from all the frameworks…

In my last article I talk about using an instance of Events to allow for loose coupling of functionality to limit dependencies as well as the use of singletons. There was a comment at the bottom of that article that I thought worth sharing and expounding upon:

I’ve been using Class.Occlude and occluding to document.body when I need a singleton. Works like a charm. - Kris Wallsmith

I thought this was a great idea and thought I’d explain what he means for those of you perhaps unfamiliar with Class.Occlude.

What Class.Occlude Does

Class.Occlude allows you to define a class that is tied to a DOM element (as most are) and to prevent that class from creating more than one instance for that DOM element. If you created a class that, say, validated a form, and you wanted to ensure that the user (the JavaScript user - not a site visitor) of your class didn’t attach two instances of that validator to the same form twice, as doing so would result in, say, a state where it was impossible to submit the form, you could use Class.Occlude to ensure that even if two instances of the form validator were created, only one would do anything. Indeed, the second time you tried to instantiate the validator class you would just be returned the first one. Here’s what it looks like:

var FancyFormValidator = new Class({
  Implements: Class.Occlude,
  property: 'FancyFormValidator',
  initialize: function(form) {
    this.element = $(form);
    if (this.occlude()) return this.occluded;
    //...the rest of  your awesome validation logic
  }
});
var fancyValidator = new FancyFormValidator($('myform'));
var fancyValidator2 = new FancyFormValidator($('myform'));
//fancyValidator === fancyValidator2

Using Class.Occlude to Create Singletons

So what Kris does (per his comment) when he wants an instance of a class but wants to ensure that there is only ever one instance, he occludes the document body. This means that even if you try and create a new instance of that class, if you’ve already created one, you’ll be returned the existing one.

For example:

var SingleFoo = new Class({
  Implements: Class.Occlude,
  property: 'SingleFoo',
  initialize: function(arg1, arg2, etc) {
    this.element = $(document.body);
    if (this.occlude()) return this.occluded;
    //the rest of your stuff goes here
 }
});
var foo1 = new SingleFoo(a1, a2, etc);
var foo2 = new SingleFoo(b1, b2, etc);
//foo1 === foo2

A clever solution, if you ask me.

I got an email today asking about how I use singletons in my own development environment and I thought I’d post my response for anyone who might find it useful.

Here’s the question:

Whats the best way to define some
code, assign it to a global object and have it run all at once?

I use MooTools server-side quite a bit in my ASP code using JScript
and we have need for global singleton objects to be around (such as
our logger). As there are no clear best practice ways out there of
doing it I’ve started and stuck with something like this:

var LoggerObject = function() {
// Logger code
}

var Logger = new LoggerObject()

which is ok but feels like I’m missing something. How do the pros do
it, whats the advantages/disadvantages to other methods?

Now, for those who aren’t familiar with the concept, a singleton is a class that designed to have only one (or, perhaps, a limited number greater than one) instance. In JavaScript, any object can inherit from any other object and you can’t really prevent this, so in the truest sense of the term, there’s no such thing as a JavaScript singleton.

MooTools gives us a function called “Class” which helps us manage inheritance between objects. Creating an object that is an instance of a class is done with the “new” operator:

var myWidget = new Widget()

If you wanted to create a class and immediately cast it into an instance, you could do the following:

var myInstance = new new Class({...})

The double “new” invokes the function returned by class and returns an object - an instance of that class. There’s rarely a reason to do this. In fact, the only reason I can think of is if you want that class to extend another:

var myInstance = new new Class({
    Extends: SomeOtherClass,
    //new properties go here
});

The problem with this pattern is that it doesn’t really get you much. JavaScript is all about objects, and there are better ways to accomplish this task.

I use objects (as singletons) all the time for my application code (almost never for plugins obviously; those are meant to be extended and instantiated). I often use a “site” object to attach methods and manage state (such as if the user is logged in, their username, etc). I just make this a plain old JavaScript object, like so:

var mySite = {
    login: function(username){ this.username = username; },
    showWelcome: function(){
        $('welcome').set('html', 'Welcome ' + this.username);
    }
};

There’s nothing special here - this is how JavaScript works. It’s important to note that classes in MooTools exist to give us functionality and to let us derive functionality through inheritance. If I create a class called Widget and I later want to make a version called Widget.Ajax, I can extend Widget and add only the ajax parts. With singletons, the whole point is that you aren’t going to create more than one of them.

However, there are some other things that MooTools’ Class gives us, such as mixins (classes that are meant to use Implement to imbue the target class with their properties). Examples here include the Events and Options mixins that give instances methods like setOptions and addEvent. In these cases you can still use the object declaration above and then extend the object:

var mySite = {
    login: function(username){
        this.username = username;
        this.fireEvent('login');
    },
    showWelcome: function(){
        $('welcome').set('html', 'Welcome ' + this.username);
    }
};
$extend(mySite, new Events());

Working this way obviates the need for the clunky “new new Class” pattern and it’s more intelligible in my opinion.

Event Arbiters

Which brings me to a common practice I use when I build applications. When I build a site or application I try to make things as modular as possible. I make it so that my site works without any JavaScript first, then I start adding in the UI goodness with ajax and animations and sortable tables and all that jazz. I also make the JavaScript itself modular. Everything that can be a class I make a class. The stuff that’s left over is the code that instantiates those classes.

But what if the code that instantiates one widget needs to get information from another widget? For instance, what if our Welcome widget needs to know the state of the Login widget? Well, if our Login widget stores it’s state on the mySite object, then the Welcome widget can just inspect that, right? That’s cool; if the page loads and mySite.username is undefined then the Welcome widget knows the user isn’t logged in. All good.

But what happens when that state changes? What happens when the user logs in? Now we need an event - onLogin or something, but that means that Welcome needs to attach itself to Login and now we’ve lost some modularity because we’ve introduced a dependency. Welcome can’t work without Login. In this case, this doesn’t seem like a bad dependency to have - after all, a welcome message without login functionality doesn’t make much sense - but there might be dozens of other widgets that need to do things when the user logs in and we may want those widget to work even if the user doesn’t log in. Further, we may want to load the Login widget only on demand - when the user tries to log in for example. We can’t do that if all our widgets need to attach events to the Login widget.

This is why I make mySite an instance of Events. mySite doesn’t really have any native events per se. Rather, other classes attach events to it and fire events for it. So, in our puzzle above about our Login widget, instead of all the other widgets attaching an onLogin event to Login, they can attach it to mySite, and then our Login widget fires that event not on itself but on mySite:

var mySite = new Events();
var Login = new Class({
    //...login logic and stuff
    loginSuccess: function(username){
        mySite.username = username;
        mySite.fireEvent('login');
    }
});
var Welcome = new Class({
    initialize: function(){
        this.showMessage();
        mySite.addEvent('login', this.showMessage.bind(this));
    },
    showMessage: function(){
        $('welcome').set('html', mySite.username ? 'Welcome ' + mySite.username : 'Please log in');
    }
});

Now our classes are no longer dependent on each other. They are both dependent on mySite but that was always the case. They can each come and go as they wish without really caring about the other. This increased modularity pays off later as your site grows in complexity. Some pages may have some widgets and some may have others. You can attach logic to the mySite object without having to really manage those dependencies.