There’s a post over on Ryan Rampersand’s blog today entitled “State of the MooTools” wherein he responds to a comment left on an earlier post he made (MooTools is not dead) and ponders the state of the library:

I want to know what people think of the State of the Mootools. My feelings shift often. I wrote a new edition of the mooWalkthrough; I love moo that much. Other days, I wonder where it’s heading and where to find things. Where is everyone? While we don’t need a super leader, we do need someone to give us regular mootoolers some direction. More than what the core team has done so far.

What are your feelings on the direction of Mootools? The community, the library and the current feeling that Mootools gives off?

I’d like to talk about MooTools a bit and touch on it’s current state, but this requires a little bit of history, so bear with me.

First, a disclaimer

I’m listed as one of the MooTools core developers but I think you can see that I tend to release my code here rather than in MooTools itself. I’ll elaborate on why that is in a moment, but first I want to make clear that this post is my opinion and my perspective. I’m not speaking on behalf of MooTools and its authors, though I consider myself a part of that group.

MooTools r83

When I first read MooTools’ source code when it was released I was immediately impressed. Here’s a bit from my very first post on the framework, back when I was still using Prototype + Scriptaculous:

Well crap. 1) I love the mad4milk guys (makers of moo.fx, moo.ajax, moo.dom, prototype.lite). 2) their new framework looks AWESOME. 3) as always, their libraries are SUPER TINY.

But damn, now I have to learn something new, and maybe rewrite a bunch of crap. This is the problem with javascript. Still, when Prototype + Scriptaculous is 100K, you gotta admire their ability to crank something out in under 20K that will get you nearly the same thing.

After that I posted a much longer follow-up where I talk about what I like about the framework compared to the others that were out there at the time. What impressed me most about the framework was that it was light weight (compared to Prototype+Scriptactulous or YUI at the time), it had a lot of functionality (Ajax, effects, etc), and that it was a robust programming environment (much like Prototype) featuring well written Class based inheritance mechanisms.

MooTools is still pretty low level stuff. Their class creation/inheritance model is really slick and their chainable functions (similar to jQuery’s model – Element.addClass(’x’).removeClass(’y’).resizeTo([100,200]) etc.) are really powerful and tidy.

But right out of the box you get some really nice functionality that you can implement really quickly. You get popup tooltip stuff, you get accordians, draggables, sorting tables, JSON support, cookie handling, event handling, and Ajax (and more).

When I decided to focus on MooTools for CNET, it was apparent that MooTools still had a ways to go. There were no docs, few demos, no tutorial, and a lot of things left to do before you could call it something other than a beta.

So I wrote the docs – just reading the source code and writing the docs taught me more about JavaScript than all my work before that. I reached out to the author of the framework – Valerio – and offered the docs to him. He exploded with excitement and called me (from Italy) via Skype because his emails to me kept bouncing for some reason. That first phone call is the only time I’ve ever spoken to him (we communicate mostly over IM) and it was kind of a funny call as there was lag, the line was noisy, and his spoken English is filled with a strong Italian accent. Still, we managed to communicate long enough over the terrible connection to get our IM information to each other and then we started chatting. I’ve probably written more characters in IM conversations to him than I have written MooTools code.

When MooTools made its first relatively-stable release (svn r.83) it featured a lot of my own work, but Valerio’s productivity dwarfed my own. MooTools has always been Valerio’s vision and he’s been kind of a stickler about what goes in it. I’ve submitted ideas to him countless times and the vast majority of them have been shot down, not because he doesn’t respect my work, but because he wants to keep MooTools focused on doing what it does.

In Valerio’s vision, MooTools should be a framework for developing JavaScript, not a collection of easy to install widgets that anyone can use.

The MooTools Forums

Valerio set up the MooTools forums as a place for those early users to come and discuss the framework itself. Most of the posts were being made by people who understood JavaScript rather well and were wanting to talk about how MooTools worked. Bugs and discussions about features were the main focus and it was a healthy conversation. Over time however, the forum became a support mechanism for people who wanted to use MooTools to accomplish basic things, but many of these posters had no knowledge of JavaScript. Accordion questions showed up nearly every hour it seemed, and apparently these people didn’t know how to search. Very quickly the forums became a hassle and a distraction. There were some great threads and I do miss them some times, but they increasingly became a hindrance that prevented us from moving MooTools forward.

When we moved the discussion group to Google we accomplished three things:

1. We divorce the community and its voice from the developers. If someone goes on an ugly rant on the google groups it doesn’t cover our faces in mud. Every community has a bad apple or two, and we got tired of having our names tarnished by the ones that showed up on our forums (again, the vast majority of people who communicated in the forums were awesome). Oddly, ever since the move to Google Groups, this kind of thing happens far less frequently
2. We took something that we previously had to support off our list. The server MooTools runs on is donated and the forums had a habit of bringing it down.
3. Somehow, by moving the forums to Google, the quality of the posts are just… better. I myself am FAR more likely to post there now than I was on the old forums. Just check this out. I’m one of the most prolific people on the group, mostly answering questions. This is mostly due to the fact that the questions are by people who are actually trying, while on the old forums there were a lot of lazy people who would just post useless questions without code examples or links to examples.

The MooTools community is far better off with the Google Groups than the old forums if you ask me.

The Birth of the Clientcide Libraries

Every line of code I’ve released comes with the unspoken invitation to the MooTools group to take it and use it. I’ve released almost as much code as is in MooTools and indeed, many of my releases have been consumed by the library and I’m happy to see that happen. But I do often get the question – why don’t I publish my code as part of MooTools?

The answer is that I realized the value of two very key concepts in MooTools: 1) its focus and lean nature and 2) its extensibility means that you can always make the framework into whatever you want it to be. As my understanding of how the core of the library really works (how Class works, for example) has only enabled me to bend it to my will more and more.

At some point, I had enough code that I found useful enough to release that didn’t fit into MooTools. The thing is, it doesn’t have to! Anyone can extend the library in any way they choose. It’s so versatile and flexible that there are only rarely things that I cannot do until the next release (indeed, there are only two features that I am waiting for in the next release: post-instantiation mutators and access to the garbage collection for event delegation – and if those ideas sound abstract to you then that’s an illustration of how deep you have to dive into the library before you find something you can’t extend easily).

So I don’t take it as insult when I give something to Valerio and others to consider and they turn it down. By releasing my own code I have greater control of my own solutions, but I also benefit from the community (and so does MooTools).

MooTools 1.2

So when the question of the current state of MooTools comes up, increasingly people are concerned that nothing is going on with the framework. The reasons are threefold:

1. MooTools 1.2 is very, very stable. Indeed, there are only a few issues with it that are really in line for 1.3 – event delegation (based on work by Daniel Steigerwald and myself), some enhancements to Class, and a few minor bugs.
2. The core developers do not particularly enjoy communicating with the community. I don’t view this as a flaw. It’s just that they like writing lots of code while people like me and others like writing about the code they write. Valerio in particular rarely posts to the MooTools blog and has a bad habit of not answering emails (even by me).
3. The core developers are less concerned about evangelizing the framework than others. Simply put, the popularity of the framework is nowhere near as important as the quality of the framework. MooTools lends itself easily to jQuery style development techniques, and nothing is stopping anyone from adding those kinds of functions and methods, but it’s just not a priority to make the framework easier to use. If you know JavaScript (or want to learn it), MooTools is a great choice for you. If you want to just make something animate on your pages and move on, then other frameworks might make more sense.

Diligence Pays Off

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.

So Where Do We Go From Here?

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). Tom, one of the most productive and active developers on the team, just took a job at Facebook and moved out to California (Welcome Tom!). He’s busy settling in at his new digs but I think his new job is good for MooTools (not that I expect Facebook to adopt MooTools outright) in that it basically pays him to write JavaScript all day long in a demanding environment that’s going to throw a lot of use cases at him. I know he’s eager to bring some of what he learns to MooTools and vice versa. Harald Kirschner is still working on the MooTools forge as he has time. David Walsh and I have started trying to post more frequently and twittering away on @mootools and he’s currently working on putting together a download page for all his plugins so that he can formally release them after my urging.

We have a lot of things going on with MooTools. We’re just not great at talking about it. For instance, check out MooTools ART – a project that came together nearly six months ago because Valerio and Christopher needed it. Stuff like this gets worked on so that we can use it. There are thousands of MooTools users out there who are writing their own plugins for their own use but they don’t go through the trouble of releasing it. We’re trying to ferret these things out where we can and post about them (on twitter, here, and elsewhere).

So No, MooTools Isn’t Dead

If you’re wondering what’s going on with MooTools, well, to quote the great Mos Def, “So the next time you ask yourself where Hip-Hop is goin ask yourself.. where am I goin? How am I doin?” What are you doing with MooTools? Why aren’t you writing about it? Releasing it? Contributing it?

So no, MooTools isn’t dead. It’s just in use and its current state is meeting our needs. For those of you who have needs that are more specific or esoteric, I suggest you get busy.

This entry was posted on Wednesday, January 21st, 2009 at 12:28 am and is filed under MooTools. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.