Slick Selector Engine

The biggest update is the inclusion of the new Slick standalone selector engine. The engine was developed by Thomas Aylott, Fabio Costa and Valerio Proietti with accuracy and portability in mind, allowing the engine to not only provide MooTools developers with excellent selector support but also the ability for it to be included in other projects as well. The MooTools team created over 3,000 tests to ensure that even the most obscure scenarios were considered. The inclusion of Slick also allowed the team to extend the Element method to allow creation of DOM elements using complex CSS selector expressions. Very cool!

Core Updates

The MooTools team also focused on enhancing the core API in preparation for MooTools 2.0 by deprecated every $- prefixed function and nd moving those to the relevant natives namespaces:

We have revised the whole base of our library to speed up MooTools, to provide an even more beautiful API and to make our library future-proof. In order to reduce the amount of global variables we have moved all $-prefixed functions into their according namespace ($splat » Array.from, …). In short we think that with 1.3 you are getting the best MooTools experience ever.

New Build Manager

Building a new version of MooTools has always been easy using the builder and now it’s been improved via the new Packager preprocessor which allows you to create custom MooTools builds from Github repositories. It handles code dependencies and already provides support for several MooTools plugins. The new Packager is a PHP 5.2+ library but can also be found as a Python app thanks to Aaron Newton’s work.

MooTools Runner

To make sure that MooTools continues to adhere to the projects’s specifications, Christoph Pojer & Arian Stolwijk spent some time over the summer building a new spec testing engine called MooTools Runner which has been adopted by all major MooTools projects – Core, More and Slick. The engine is based on Jasmine and runs all specs within just 2 seconds. In addition, code coverage was increased to about 95%, ensuring excellent test coverage for Core.

Download it!

Once you’re ready, you can grab the latest version of MooTools or roll your own via the following links:

too much bugs! i feel disappoint! I only write less than ten line codes,happened that the method contains can’t work well,and what important is i can’t find the place to submit the bugs in mootools’s website

Mootools Class is still “reseting” whole instance during every instantiation, which has significant performance hit. In the other words, Mootools class system is fine for humble ui widgets, but I definitely would not recommend it for building regular ajax app.
It’s pity, that simple widgets created with mootools, are not suitable for distribution, due to Mootools scope mess.

Have you ever tried to build a ‘regular ajax app’ with Mootools? There are plenty of real-world examples of successful apps using Mootools that do very well for themselves. Also keen to see some hard data on the subject – got a link for us?

Sixtyseconds: several years ago, gmaps clone with api http://goo.gl/uI1z, two years ago, wysiwyg web creator http://goo.gl/l8HZ I also made over hundred moo ticket tickets.. So there is a chance I know what I am talking about ;)

Steida: Do you have any specs to backup that claim? Or should we all assume this is a case of a celestial teapot?

Perhaps it is better if we tell everyone first what “class reseting” is. Contrary to popular belief, it is not a full cloning of the class definition, so anyone carrying those picket signs that say “MooTools doesn’t use prototypes!”, as well as those with the banners that bear “MooTools copies all objects!”, can put them away now.

Class is actually a “fix” for an issue regarding prototypes and object references. When you declare a prototype property that references an object, the reference is never removed for instances because JavaScript uses prototype-chain traversal instead of prototype-cloning to implement inheritance. The problem is that this reference becomes entangled with all instances, and changes in one instance are propagated to other instances.

The MooTools class system is actually a thin layer on top of the native prototype system. All members of the definition object you pass to the Class constructor are therefore augmented into the prototype of your class. And because MooTools allows for object properties in Class declaration, the problem I just showed above could also rear its head for MooTools classes.

But this is where “resetting” comes in. The MooTools common constructor uses a `reset` function to ensure that each instance will have a clean copy of the property so that no two instances will share the same reference to the object property. The function does this by looping through the new instance using a basic for/in loop, and then unlinking each “object” or “array” type property in the instance.

The “significant performance hit” you are claiming is observable, but only under very specific circumstances that has more to do with improper class design than anything else. A basic case of this is when you’re directly linking to hundreds of other objects that reference other objects in your class declaration, or arrays with lots of reference type members.

And even then it’s not a big problem: move these references to your `initialize` method and see the “significant performance hit” disappear. It’s like bovine magic!

So to summarize: Class resetting is essential in order to fix a reference problem, and it is not as significant as anyone would like think.

Are you saying that if you re-instantiate a Class it runs through and creates a fresh instance? Your claim is extremely vague and I can tell you that when you create an Fx instance for example (or any other Class instance), it is the same instance each and every time, no resetting occurs.

And quite contrary to your statement about the scalability of the framework, MooTools is much better suited to handle “regular ajax apps” because it is extensible and Class-driven (DRY, OO, the masses will understand eventually, baby steps…) I suspect you are a bit confused as it is, being that an “ajax app” would be one that uses async requests to fetch data…and I know you didn’t just grace us with a negative comment that invokes the term this very site’s name is based in an inaccurate and buzzwordish way…did you?

@sixttseconds I do have experience building “regular ajax app” using Mootools and they works, but the thing is not about what it can do but how it can do it. Mootools is not the best choice because of the simple reason that internally it’s a mess and I don’t wanna rely on that mess. Also I’ve run a couple of test and I saw best performance in other frameworks like jQuery. I was quite fond of Prototype and Mootools but after many projects I’ve scrapped them. They just don’t meet my needs and in my opinion they are not good frameworks

@auspex – well you are more than welcome to your opinion. :) I have found Moo to fit most of the projects I do, and I certainly prefer the sugar it provides. In all honesty, I haven’t found any practical performance loss using it.

Are you kidding me!: “Mootools is not the best choice because of the simple reason that internally it’s a mess and I don’t wanna rely on that mess.”

This statement is the opposite of the truth, and quite frankly offensive. You obviously haven’t done as you’ve said and reviewed the MooTools source. Your comment is an ad hoc, irrelevant conclusion backed up with literally ZERO evidence. I’d like to see some line number references for the areas of “mess” to which you are referring – until then, shut your mouth.

@starkraving – It really is worth it, and the conversion touch-points are mostly just string replacements (save getter options setting, Hash, and a few others). I think the benefit you would see from switching is noticeable.