Articles by ‘Valerio Proietti’

MooTools 1.3 βeta 1

Written By Valerio Proietti, on Tuesday, April 27th 2010, 6:25pm

MooTools 1.3 beta 1 launches today. Lots of bug fixes and improvements, and all that jazz. Before presenting you with a random rundown of features, let me be clear about something: MooTools 1.3 is (or will be) 100% compatible with every public documented API of MooTools 1.2. So chill already.

Anyways, here’s what’s new:


MooTools 1.3 moves away from the $name functions. Most of the useless ones, such as $chk (god knows why I thought it was a good idea to have $chk), were completely nixed. Some of them moved to the proper object’s namespace ($merge » Object.merge, $pick » Array.prototype.pick). Some others were renamed without the stupid $ in front ($type » typeOf, $defined » nil). In the end, there are a lot less global variables now. You can refer to the 1.3 documentation to have a proper list of what’s changed. Keep in mind that the old version of the methods will still work, by default. There will be a way in the future to “compile” MooTools without the compatibility stuff, but the feature is not ready yet.

From types with love

Every native type has now a from method that will try to convert every object passed to that type. Array.from, for instance, replaces both $A and $splat. Function.from will return a function that returns the passed in value, if it wasn’t a function itself. String.from… well you know that at this point, don’t you? We also changed how we internally handle Native types, but that should be none of your concerns, since they were handled with private apis anyways.

Generating your own MooTools, from your own computer

It is now possible, easy, and even perhaps recommended to generate MooTools (and its plugins) yourself. Last few months I’ve been working, on and off, on a pretty advanced projects-builder. It’s called Packager, it supports multiple project dependancies and has a very similar syntax of what’s used in the Forge right now. It’s written in php and you can use it from your php webpages to dynamically include JavaScripts for development, or you can build a single .js for production from the command line.

If you care to build MooTools and MooTools projects for yourself, you should take these steps:

  1. Clone MooTools 1.3b1.1 from github.
  2. Clone whatever other Packager-ready MooTools project from github (color, table and touch, for instance, are my Packager-ready plugins).
  3. Clone Packager itself from github.
  4. Read Packager’s README. Pretty much everything you need to know is in there.

Ofcourse, Packager itself is not limited to MooTools, MooTools plugins or just javascript projects. A tutorial post on how to use Packager for development is coming soon (few years tops).

If you dislike php, worry not! There is also a Django builder, called Depender, written by our Aaron Newton, on github as well. I really don’t know how it works, as I don’t do python, but I do know it’s scope is way greater than that of Packager. Depender can, for instance, dynamically build your MooTools for production use, like that. But don’t take my word for it, go check it out on github.


The most notable new feature in 1.3 is Slick. Slick is our new, shiny, super fast, exhaustively tested, pure-javascript selector engine. There will probably be a dedicated Slick post in the following days (or months, given our relaxed release cycles), but here’s a few Slick-facts for those who haven’t checked it out already:

  • Slick is a MooTools-family project by MooTools developers Thomas Aylott, Fabio Costa and yours truly. It can be forked from github, free of charge!
  • Slick is an incredibly advanced evolution of our previous selector engine.
  • Slick is written using only pure-javascript, none of the MooTools apis are required. It can be used in any project or framework, and it does not require MooTools to function (though the MooTools DOM components do require Slick).
  • Slick is speedy, blows away the 1.2 selector engine by 50%, at least. We will give you detailed data in the post dedicated to Slick.
  • Slick supports every selector you can think of. Seriously, every one of them. I promise you.
  • Slick is customizable, you can make your own pseudo-selectors, your own attribute-selectors, and many more your-own kinds of things.
  • Slick supports reversed combinators. You might not know what they are, but they are pretty darn cool.
  • Slick has a detached parser. You can parse a css-style-selector string and get back a property-filled object.
  • Slick perfectly supports XML documents.
  • Slick is slick!

On another note, thanks to the Slick’s parser, you will be able to build an element using a css selector. Let me give you an example of this cool new feature (courtesy of our amazing Christoph Pojer):

Creating an element using an object (the 1.2 way):

new Element("input", {"id": "someID", "class": "someClass1 someClass2", "disabled": true});

Creating an element using a selector string (the coolest way):

new Element("input#someID.someClass1.someClass2[disabled=true]");

In conclusion

As I get back to work on an exciting number of totally amazing upcoming MooTools projects that you know nothing about because you don’t follow me on github, I’ll leave you with a few useful 1.3 links:

UPDATE: There was a “merge” problem with beta1, so we quickly fixed it and re-tagged beta 1.1.

Have fun with 1.3! I know I will.


The Dollar Safe Mode

Written By Valerio Proietti, on Monday, June 22nd 2009, 10:39am

Since the dawn of time, MooTools used a method named $ to get an HTML element by it’s id or direct reference. This method name, being the coolest and shortest you can find in JavaScript, is also used by a number of other javascript frameworks and libraries for similar functionality. Now, we do not think including 2 libraries or frameworks is OK. It’s not. Never. It’s an overhead of duplication you do not want to have. However, you might not have the full control of the page in some circumstances, and we recognize that. That’s why we implemented this: Dollar Safe Mode™. It’s nothing special really, but it should help in those situations where including multiple libraries is not your choice (because if it is, quite frankly, you’re doing everything wrong. Pick one, will you? And make sure it’s MooTools :-)).

MooTools 1.2.3 DOM stuff doesn’t depend on the presence of $ anymore. The method that used to be $ is now called (short for identify). The method $ is still assigned when not already present in the page, and aliased to

But let me show you how it works:

Let’s say you have mootools.js and a fictional JS library called jLib.js. Both use a method called $.

This is what it used to happen:

Scenario 1: Include mootools first:
<script type="text/javascript" src="mootools.js" />
<script type="text/javascript" src="jLib.js" />

jLib would “steal” the $ method from MooTools. MooTools doesn’t work unless jLib has some sort of no-conflict mode of its own that will allow you to prevent it from “stealing” $ from MooTools.

Scenario 2: Include jLib first:
<script type="text/javascript" src="jLib.js" />
<script type="text/javascript" src="mootools.js" />

MooTools would “steal” the $ method from jLib, which may or may not work without it.

What happens now:

Scenario 1: Include MooTools first:

<script type="text/javascript" src="mootools.js" />
<script type="text/javascript" src="jLib.js" />

MooTools checks if a method called $ exists; if not, it defines it. In this scenario, MooTools defines it as it doesn’t find anything named $, being included first. jLib “steals” the $ method from MooTools. MooTools doesn’t care. MooTools now doesnt need $ to properly function. You can regain control of $ simply by reassigning it to its alias ($ =

Scenario 2: Include jLib first:

<script type="text/javascript" src="jLib.js" />
<script type="text/javascript" src="mootools.js" />

MooTools checks if a method called $ exists. It does find it, being included last, therefore it doesn’t define it. You can directly use or assign your own var to it, or manually assign $ to, if you would like MooTools to have control of it.

As you can see, it’s pretty straightforward. In short, MooTools doesn’t need $ to function anymore, and doesn’t steal it from other frameworks when included after them.


The above applies for MooTools-Core and MooTools-More. However, MooTools plugins use the $ method, therefore, while not breaking MooTools by including jLib, you will break the MooTools plugins. If you desperately need plugins to be multiple-framework compatible, and you the other frameworks to have control of $, there are a few things you can do.

The first, most obvious and recommended option is to replace every call to $() with by hand. It doesn’t take more than 10 seconds with a simple find and replace. This is probably what plugin authors should do, if they wish their plugin to be dollar-safe.

Another option is to encapsulate the plugin using a closure. This might come handy if you are processing a plugin that isn’t yours:

var X = new Class({
    initialize: function(element){
        this.element = $(element);

it should become:


    var $ =;

    this.X = new Class({
        initialize: function(element){
            this.element = $(element);


As you can see, we’ve simply assigned $ as a local variable, using a closure. Everything in that closure will use as its $ method. Remember to export the global variables though, as vars defined in the closure will stay private. I like to export globals using this., but you can use window. as well.

Please note that MooTools will probably remain incompatible with other frameworks that modify native prototypes, as there will probably be more name clashes. This isn’t a cross-framework compatible MooTools version by any means, nor does it want to be. The whole point is not to “steal” the dollar function from other libraries.

And that’s pretty much it about the Dollar Safe Mode™ in MooTools 1.2.3.

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.

A New Name for MooTools

Written By Valerio Proietti, on Wednesday, April 1st 2009, 12:00am

UPDATE: Sincere thanks to all of you who actually believed this was real news! April Fools’ wouldn’t be as much fun without you.

The MooTools project has been around for quite some time now. We’ve seen a few releases, some great, some less great (1.0). We’ve coded tons of plug-ins, scripts, websites, applications and desktop applications using our beloved MooTools. However, the community is really starting to get tired, tired of this project name. I mean, seriously, we’re really fed up with cows. We even tried to “sell” it as My Object Oriented Tools, but we all know that’s a stretch, and a pretty bad one.



Written By Valerio Proietti, on Thursday, December 4th 2008, 11:34pm

During the last couple of days, there has been a discussion in various places about JavaScript frameworks implementing Sizzle, the new CSS selector engine by John Resig, which is allegedly the fastest.

Resig wrote Tom an email, saying that he would be pleased if MooTools joined the other frameworks by implementing Sizzle in its codebase, replacing our own selectors engine. I don’t really know how many frameworks are actually thinking of using Sizzle in place of their own selectors code, as the only source I can find for this is Ajaxian.

Their information about Dojo wasn’t correct, so I’m assuming that information about other frameworks is incorrect as well. I do know that Dojo is considering including Sizzle as part of the Dojo foundation, based on an email Dylan Schiemann wrote to Aaron Newton. As I understand it, Sizzle would become a Dojo Foundation project, with the ultimate goal of including it into Dojo Toolkit. They have this idea of having the major framework developers all contribute to a unified CSS selector engine.

Now that you know the general picture, let me explain why this is a bad idea not only for MooTools, but for any framework other than Dojo and jQuery.