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.
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.
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:
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:
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):
new Element("input", {"id": "someID", "class": "someClass1 someClass2", "disabled": true});new Element("input#someID.someClass1.someClass2[disabled=true]");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
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.
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.
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.
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.