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:

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:

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

26 Responses to “MooTools 1.3 βeta 1”

  1. Juan Benavies says:

    Slick sounds pretty darn cool! :O … first of all CakePHP 1.3, now Mootools 1.3 beta. Awesome!

  2. Timothy says:

    I’ll be downloading a clone of this soon and checking it out. Interested to read through Slick and see how the insides look.

  3. Justin says:

    Awesome! Can’t wait to give it a try.

  4. barryvan says:

    Awesome! Any idea of how many beta releases there’ll be before 1.3 is considered stable? I’d love to get some of the enhancements and speed improvements (especially Slick) into our production software, but that’s not going to happen until that ß is stripped off. :)

  5. kamicane says:

    Really depends on the amount of reports we get. I’d say another beta and we’re good to go.

  6. Kevin Chapelier says:

    Thanks for your hard work, I’ll be sure to check it tomorrow.

  7. Aaron Newton says:

    Also note that MooTools More will be updated for all the API changes in 1.3. The next beta of 1.3 will hopefully be coupled with a 1.3 beta for -more as well.

  8. gonchuki says:

    yay! you guys always get the next greatest version when I’m in the middle of a nice project and I’m still in time for implementing it =) it’s like you have spider senses or something. gonna give this beta a try and see if everything works like it should in my project.

  9. Merrick Christensen says:

    Thank you guys so much for your hard work on this. So beautiful. Hilarious blog post too:

    “There will probably be a dedicated Slick post in the following days (or months, given our relaxed release cycles)”

    “A tutorial post on how to use Packager for development is coming soon (few years tops).”

    “If you want a full changelog, go read the git history, you lazy bastard. Changelogs are so 2001.”

    Had a good laugh. So stoked. Thanks guys!

  10. Chris the Developer says:

    Good work, fellows. Now I need to run through my forge plugins and update for 1.3! Can’t wait for 2.0

  11. Htbaa says:

    A sseta? :-)

    Great work though. Have been using MooTools from the beginning and it has made using Javascript on the web fun again. Easy as well ;-).

  12. kentaromiura says:

    This is an awesome news, I’m going to dig the code now, but I seriously don’t have any idea of what reversed combinators is. I tried to search on google for “reversed combinators” and for “srotanibmoc” without a clue, but since they have a cool name they must be something smashing awesome.

    I’m looking forward for the pattern-based mutators that keeto said should be introduced in 2.0, so I suppose that I will not found anything in here.

    …Anyway thanks ;)

  13. Arian says:

    Great work guys! Was waiting for this and will definitely use 1.3 in my current project and Forge Plugins to test it.

  14. Spi says:

    Yes !!! Mootools is definitively the best way to write JS. Great work guys.

  15. SunboX says:

    *woohoo Sounds great! Can´t wait to get the final! Mootools code is true art. ;o)

  16. daminetreg says:

    It’s Christmas! The Slick and the new from methods are so cool. It’s the best framework I know. :) Using it actively!

  17. cpojer says:

    As for your forge plugins I think it is best to leave them on 1.2 until the final 1.3 release. What you can and probably should do is make a branch for the updated 1.3 code that you merge and put on the forge once we release the final.

    Please also add a comment whether your plugin can run without compatibility too.

  18. Seidr says:

    Very damn cool - can’t wait to check out Slick!

  19. Brade says:

    Thanks for the continued radness — using along with Cake 1.3 for a budget app I’m developing!

  20. Rasmus Fløe says:

    Yipee!

    Anyone got a Slickspeed/Taskspeed up and running yet with this beta in it?

  21. Fabian Beiner says:

    Rasmus, I’ve put a SlickSpeed online: http://fabian-beiner.de/slickspeed-selectors-test/

  22. Nypher says:

    Very cool! Haven’t seen it yet but i’m going to have some fun. By the way is there any change with each(), i’m a bit worried since i’ve read a post by aaron that talket about “changes”?

  23. Webstandard-Blog says:

    Thx for publishing the next mootools-version Valerio!

  24. Pjb says:

    Can i just ask why $chk was not a good idea? I use it frequently where i want to allow for 0 and don’t want to write a shorter comparison statement. Seems to me it’s very useful, but I can’t understand why it would not be a good idea?!

  25. 131 says:

    http://fabian-beiner.de/slickspeed-selectors-test/ Well, Slick (in mt 1.3b1.1) seems to be 500% slower (IE8/XP) than the old selector engine (233ms for 1.2/ 1170ms for Slick - all good until nth-path pseudo selectors)… Great job in new Element(“input#someID.someClass1.someClass2[disabled=true]”) anyway !

  26. Fábio Miranda Costa says:

    @131 The mentioned problem has been fixed and will be on the next release of mootools. Thanks for pointing that out.