Thursday, April 29th, 2010

MooTools 1.3b1: A “Slick” release

Category: JavaScript, MooTools

>The first beta of MooTools 1.3 has become available. The biggest feature is their new CSS selector engine. They aren’t using Sizzle like some of the other boys, but instead have become 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!

This bleeds into some new APIs too.

For example, what you may have done like this:

javascript
< view plain text >
  1. new Element("input", {"id": "someID", "class": "someClass1 someClass2", "disabled": true});

you can now do using selectors:

javascript
< view plain text >
  1. new Element("input#someID.someClass1.someClass2[disabled=true]");

There are other features too:

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.

Posted by Dion Almaer at 5:20 am
6 Comments

++---
2.3 rating from 4 votes

6 Comments »

Comments feed TrackBack URI

Despite the fact that I’ve been using jQuery in the latest projects I still have a soft spot for MooTools. I think that the ability to only “compile” those parts of the total framework that you need is a great help in optimizing code, and it seems that with 1.3 they’re going to be streamlining the code as well. I definitely like the detached parser. It’ll probably be a bit cumbersome for complex objects. e.g.
new Element(“input#someID.someClass1.someClass2[disabled=true][type='text'][value='something'][placeholder='something']“)
but for a quick, simple object creation this seems like a great shortcut.

Comment by iliad — April 29, 2010

Nice, i’m interessted in the first sizzle VS slick speed-results ;)

If Fabio? or the creator of Packager is reading, is the Packager available to other projects? Can I use it for my own lib?

Comment by gossi — April 29, 2010

@gossi: Yep, you can find Packager on Github here.

Comment by fakedarren — April 29, 2010

@gossi,
You can use package anywhere, see documentation here: http://github.com/kamicane/packager

Kamicane made it as you can see, not me.
About comparisons, we’ve been having some nice results.

Comment by fabiomcosta — April 29, 2010

Both Packager and Depender can compile JS or anything else. Depender provides a client side client that’s authored using MooTools that allows you to do lazy loading, but you don’t have to use it.
.
http://github.com/kamicane/packager
.
http://github.com/anutron/mootools-depender

Comment by anewton — April 29, 2010

Great job MooTooligans! Slick is fast and incredibly extensible, MooTools FTW.

Comment by csuwldcat — April 29, 2010

Leave a comment

You must be logged in to post a comment.