MooTools

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:

Globals

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.

Slick

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:

• Download the built 1.3 beta 1 release.
• Fork / clone MooTools 1.3 from github, and build it yourself with Packager, or Depender.
• If you want a full changelog, go read the git history, you lazy bastard. Changelogs are so 2001.
• Wondering how those amazing new methods are called? You can browse our markdown documentation right on github.
• And don’t forget to report any issue you find with the beta, compatibility or not! The more reports we get, the fastest we’ll have a final release.

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.

Valerio

Hey there MooToolers. I just returned from speaking at jQuery Conference 2010 in San Francisco on “Object Oriented jQuery with MooTools” and thought I’d share some notes on the experience.

My Talk

If you ask me how I did I’d say I missed a few connecting ideas but got the concept out there and got some people thinking. Several people came up to me afterward asking how to actually give this a shot on their web apps. Also, if you are reading this on a Mac, do this: command + option + control + 8 (⌃⌥⌘8). I think for the first time in the history of OSX this keyboard shortcut was useful. The projector had a hard time with my bright colored code on a black background so I inverted the the whole presentation!

Some of you have read my post Pigs take flight about using the Class module from MooTools to write modular code in a way we all love but use jQuery for DOM manipulation, effects, AJAX, etc. That was the basis of my talk. You can find the slides and a demo at my blog here.

The Demo is especially awesome.

Thoughts

It was very well attended, said to be the largest JavaScript conference ever. There were a lot of really talented people there and all of the speakers did great. I am humbled by the ability of the jQuery team to put together great events and market their library, I’d even say a bit jealous!

It seems at the user level people see frameworks as rivals or something, but at the framework developer level they generally feel like we’re on the same team, working to make the web better.

There was a lot of talk about organizing code, which is a problem that jQuery doesn’t try to solve. I don’t think any other framework can step in quite like MooTools to do it and yet keep the jQuery API in tact when writing an application’s code (thanks to mutators). Another testament that -core is rock solid and ridiculously versatile for JavaScript generally, not just the DOM. I also found that a lot of people didn’t know that you can create custom builds of MooTools to solve all sorts of JavaScript problems.

So, thanks jQuery for a great weekend!

• Slides and Demo
• Pigs Take Flight Blog Post
• jQuery Conference 2010 SFO

Over the past several months we here at MooTools have been contemplating how much of what we do is duplicated effort. When we started this whole project years ago it was because we wanted to do things our own way, but as MooTools and JavaScript in general have progressed, we find ourselves facing the tedium of all the low lying code that has to be written to get Browsers to play nice, not to mention the richer things like our inheritance system and other utilities like effects, DomReady, etc. etc.

At FOSDEM we ended up hanging out with the Dojo crew. We like them; they are always doing interesting things and their framework is one that we’ve always looked at and said to ourselves, “If we ever needed feature X we’d probably just port it from them.” Anyway, at FOSDEM a group of their developers and ours got together and started brainstorming about closer ways to work together. Since then the discussion has gotten closer and closer to where we are now.

MooJo

Starting today the Dojo and MooTools projects will begin merging and joining forces. Part of this is to share resources - more hands coding makes more code, right? But part of it is, well, we’ll be frank, we’re kind of tired of reinventing the wheel. We love the solutions in MooTools, but at the end of the day, the API is all that matters. It doesn’t matter how you detect that the DOM is ready, so long as when it is your code runs. The same could be said for selector engines, XMLHttpRequest, and a whole host of other things. What this means in practical terms is that we just don’t have to do as much work and, to be frank, after 4 years of working on MooTools, we’re happy to cede some of the more tedious tasks to Dojo. Sure, their architecture isn’t quite the same (or maybe even as good) as ours, but it works. This will free our development team’s time to work on their own projects and maybe start getting paid for it, which brings us to the second point.

Making MooJo Profitable

For the past four years we’ve been writing code and releasing it for free. In our talks with the Dojo team we all agreed that all this free time donated to anyone who happened to want our work just wasn’t quite worth the hassle. Don’t get us wrong, writing the code is fun, but it’s all the other stuff. The bug reports, the hand-holding in the forums and on IRC, the constant demand to “compete” with other frameworks (whatever that means). It just sucks the pleasure right out of it. We find ourselves burning nights and weekends to write code for strangers to use and it gets old.

Going forward, the code base will continue to be free, but access to the documentation will require a small “donation” (we’ll probably set a really small minimum, like, say $.25) - frankly, the documentation has gotten too good to be free (we contemplated printing it and just selling it as a book, but micropayments is much more “Web 2.0”). Filing bugs will still be free of course. But we’re working on a system that lets our users put money towards the bugs they care about the most. The bug with the most money donated gets our time and gets in the next release. We think this will cut down on both the number of bugs we get but also help manage expectations. If you have a bug that you think is important, you either need a lot of people to agree with you (which they will if the bug is really broad) or you need to pay a lot (in which case it’s like you’re hiring us as freelancers).

What will we do with the money raised? We’ll probably start sponsoring more meet-ups and sending more people to conferences, but we’ll also be able to compensate the developers who bring you all this great stuff. Certainly no one can argue with that.

Compatiblity

As we begin merging functionality we’ll likely retire large portions of both frameworks. MooTools has a great effects library while Dojo has a lot of solid widgets. MooTools ART will likely get shelved in favor of dojo.gfx, Dojo will likely drop it’s effects libraries in favor of MooTools’ effects which are really nice, much of MooTools More will either be retired (in favor of existing Dojo widgets) or turned into Dojo widgets themselves, etc.

For backwards compatibility we’ll be implementing the “donation” system as well. For the portions of the MooTools and Dojo cores that are deprecated we’ll allow the users to prioritize which parts we offer compatibility for. Same goes for effects, plugins, etc. We hope this new model will encourage businesses that use our awesome frameworks to recognize the value we bring and to compensate us for our time.

If you have any questions, post them in the comments below. Comments are still free - we haven’t implemented the “donation” system for them yet, either.

Update: Yes, this was an April Fool’s joke. We love Dojo and that whole team… but not that much.

Have you extended a Native lately? It’s an incredibly helpful thing. Often people write ugly functions that take a string or whatever as an argument and return some manipulation of the string. Extending natives is a great way to do the same thing, but it is much prettier (aka: explicit, readable, easier-to-debug.)

The Difference:

I’ve seen stuff like this:

fn1(fn2(10, fn3('house')));

Hard to figure out what’s happening. Instead you can write code like:

fn3('house').fn2(10).fn1();    

A Useful, Real Example, zeroPad

I’ve used this in a couple scripts, it takes a number and returns a string with zeros padded in front: 123 becomes ‘000123’. Really handy for filenames and the like. Here’s the ugly version:

Functionally Based Example

function zeroPad(num, zeros){
  zeros = zeros || 3;
  var str = '' + num;
  zeros.times(function(){ str = '0'+str; });
  return str;
};

// usage
doSomething(zeroPad(document.getElementById('myInput').value, 3));

Native Extentions Based Example

Number.implement({
  zeroPad: function(zeros){
    var str = '' + this;
    zeros.times(function(){ str = '0'+str; });
    return str;
  }
});

// so that it works on both numbers and strings
String.implement({
  zeroPad: function(zeros){
    return this.toInt().zeroPad(zeros);
  }
});

// usage
$('myInput').get('value').zeroPad(3).doSomething();

Side by Side:

doSomething(zeroPad(document.getElementById('myInput').value, 3));
// vs
$('myInput').get('value').zeroPad(3).doSomething();

Awesome? Yes. You can do the same thing to:

• Array
• Function
• Number
• String
• Hash

Some say extending natives is a bad idea. Personally, I think it’s awesome—but this topic is a sore spot for some. Extending natives is a feature of javascript itself that any general application framework like MooTools is entitled to use. There could be an entire article dedicated to this topic but this article isn’t it. This article is simply here to show how to use this handy feature.

Flippin’ Sweet Array methods

Arian Stolwijk created this amazing gem: Array.Math. Code samples often tell the story faster:

[2,5,1,6].sum(); // 14
[2,5,6,2].product(3); // [6,15,18,6]
[9,12,15].quotient(3) // [3,4,5]

This is all made possible by extending the Array native, see?

    Array.implement({

        sum: function(start,length){
            var sum = 0, 
                start = start ? start : 0,
                length = length ? length : this.count()-start;
            length = start ? length + 2 : length;
            for(var i=start;i<length;i++) sum += this[i];
            return sum;
        },

        product: function(p){
            var arr = $type(p) == 'array';
            return this.map(function(entity,i){
                return arr ? (entity * p[i]) : (entity * p);
            });
        },

        quotient: function(q){
            var arr = $type(q) == 'array';
            return this.map(function(entity,i){
                return arr ? (entity / q[i]) : (entity / q);
            });
        },

        // and a whole lot more awesome ...

    });

Quick Tips

• this is the number or string, or whatever, when inside the method.
• Return something that makes sense (usually this).
• You can implement several methods all in the same code block.

This is just one more great tool to help keep your code organized and readable.

Javascript development in the browser is all about the Elements. Manipulating the DOM happens every few lines of code. It’s important enough that some libraries provide little more than DOM enhancements. Not to worry though, MooTools provides greatly in this area as well.

$ and $$

Most of you probably know the two document methods getElementById and querySelectorAll; because if you do, you understand how we select elements with MooTools methods. For those of you that don’t, you provide an ID string of an element in to getElementById, and a CSS selector string to querySelectorAll. The functions $ (which is an alias to document.id, see this post on Dollar Safe Mode for details) and $$ are basically equivalent to getElementById and querySelectorAll, respectively. Of course, since it’s MooTools, they’re more than that.

The dollar function, if given a string, will basically call getElementById on the document. If passed an element, it will just return the element, and if you pass an object with a toElement method, it will try to convert it to an element (we’ll explore that more a couple sections down). A key difference you’ll find between MooTools’ dollar function and jQuery’s is this: MooTools’ $() will only ever return 1 Element, and it will return null if no matching element is found. This means unless you’re absolutely 110% certain the element will exist, you’ll need to check the returned value before starting to call Element methods on it.

    var loginEl = $('Login');
    if (loginEl) {
            loginEl.fade('in');
    }  

The MooTools Team prefers two separate methods for the selecting elements; to remove any doubt about what a certain function call may be returning, we have one method for individual elements and another for multiple elements. In this case, it’s preferable to be explicit, instead of relying to ambiguous auto-magic. When we see $, we expect an element if it exists. When we see $$, we expect an array of elements (which, as you know, an array can always be empty). The double dollar function has some neat tricks that are explained in its own section below.

All this talk about Elements, but only about how to select them. MooTools also provides an excellent Element construction API.

new Element()

With vanilla JS (mmm, vanilla…), you’d use document.createElement whenever you wanted to create and add a new element to the DOM. MooTools tries to make the JavaScript API more pleasant to use; part of that is a more consistent and easy to use syntax and part of it is using more Object-Oriented programming practices. It feels a lot more OO when creating objects using the new keyword, whereas the standard way is more procedural.

It turns out that every element you could create inherits from the Element prototype. Specifically, the elements you create through document.createElement would be HTMLDivElement, or HTMLParagraphElement, or whichever element you create. Like I said, they all inherit from the base Element prototype, and then HTMLElement, and so on. MooTools extends the base Element class, so that all elements receive some MooTools love.

MooTools augments the Element native, providing a super-duper sweet constructor. You can provide the tag name, and then an object of properties to set on the new element. The returned object is of the same type as the $ method mentioned above. The properties you can set are fairly extensive, so check out the documentation to learn more about them, but here’s a demonstration.

toElement

The dollar method provides another function: converting the instance of class into an element(-al?) form. This is similar to a toString function, which converts objects into strings when needed. You can define a method in a class called toElement, and return an element to “represent” the instance. Let’s take a look at a snippet from a Person Class:

Several extensions in MooTools More take advantage of this, like Form.Request, Form.Validator, HtmlTable, and others. And many plugins in the Forge use this approach as well. This means that after creating an instance of one of these classes, you can just hold on to the instance in your code. Whenever you want to affect the element that the instance is controlling, you just use $(instance) to retrieve it.

Aaron even cooked up a ToElement mixin, and wrote a bit more about this over here.

Elements

I pointed out earlier that $$ returns an array-like object containing Elements. It actually returns an object called exactly that: Elements. Behind the scenes, MooTools gets an array of all the elements that meet the selector (so it’s still an array), and then extends the array with all the Elements methods. Why would we want that?

All the methods that MooTools adds to the Element native are added to the Elements class as well. You can do some pretty nifty chaining because of this. First of all, you don’t have to check that it didn’t return null. This is because any method you call on Elements, will loop through the array and try to call the method on each individual element. Even with an empty array, the loop won’t cause an error. And any method you call that would normally return a value, will return an array of the values from each element. An example should make this clearer:

    //assigns a click event to all A tags
    $$('a').addEvent('click',  function(e) {
            e.preventDefault();
            alert(this.href);
    });  

    //gets all divs with an id set, and then returns
    //an array of the IDs  sorted alphabetically
    var ids = $$('div[id]').get('id').sort();  

    //gets all divs with a UL immediately inside
    //and assigns a class name to  the divs
    $$('div > ul').getParent().addClass('has-list');

While you could put together long chains acting on all the elements you’ve selected, I’d advise against this. It certainly looks cool, and will work fine one or 2 methods out on the chain. But every method call will cause another loop through all the elements. If you’re doing a lot of things to every element, you might as well do it all in a single pass. I’ll show you what I mean.

    //this would loop through each time at addEvent, addClass, and fade
    $$('li  a').addEvent('click', function(e) {}).addClass('alertable').fade('in');  

    //whereas this will only cause 1 loop
    $$('li a').each(function(link)  {
            link.addEvent('click', function(e) {
                     alert(this.title);
            });
            link.addClass('alertable');
            link.fade('in');
    }); 

Still, when doing something simple, you can skip the each call, since Elements will handle that for you.

Concluding

MooTools provides a lot of expressive power when working with the DOM. It’s consistent API makes it a snap to add events, change styles, create elements and more. The object oriented nature of its implementation makes it so that you can extend Elements for your own purposes. Look forward to my next post where I’ll talk about extending Elements in various ways and cover best practices for when you decide to bend Elements to your own will.

Sean McArthur is a software developer at Blazonco.com who is madly in love with MooTools. Most of his contributions involve sharing tips and information about MooTools (and programming in general) at his blog and on Twitter.