2009, The Year of the Cow - What’s Coming with MooTools
Written By Aaron Newton, on Monday, February 2nd 2009, 8:51pmOk, it’s the year of the Ox, but you get the idea. Regardless, it’s shaping up to be a very interesting one for MooTools. There are many things going on with the framework and we thought we’d give you a heads up on what you should expect in the coming weeks and months.
MooTools 1.3
As discussed elsewhere MooTools 1.3 is on the horizon and features numerous changes that will interest you. The caveate here is that all of this is subject to change, as the work is still very much underway.
- Class is getting a rewrite that should make it both less likely to encounter browser issues but will also empower you to do some cool stuff like post- and pre-initilization mutators and inherit object properties from prototypes (the current Class breaks this inheritance link for things like options to prevent pollution across instances).
- There is a new Type constructor that has numerous methods that help you manage objects. For instance, the $type method is now Type.of and there are methods for each type (Type.isString(‘foo’) === true). In addition, most Native instances will have a .from method (Array.from(iterable)).
- Most of the $method functions are moving into better places in the framework. This means that $type is now Type.of, $empty is Function.empty, $lambda is Function.lambda, $random becomes Number.random, etc. Not all the $methods will get this treatment as there are at least a few of them that don’t really go anywhere. We’re still discussing what to do with them ($pick, $each, $defined, etc).
- Event Delegation will make it’s way officially into the framework (there are some implementations out there of this already).
- Hash, Cookie, and Swiff are all likely moving into mootools-more. The thinking here is that the Core doesn’t need these things to function and while they are useful features of MooTools, they aren’t needed by everyone.
- In a new policy change, the default pre-built version of the MooTools core will come with the compatibility layer for the previous version built in. This means that if you have a site running MooTools 1.2 you should be able to just drop in 1.3 and continue partying. You’ll want to start using the MooTools 1.3 syntax going forward, but in general, upgrading should be a lot easier.
- Various small bug fixes and the like.
As a side note, we’ll point out that while there are some organizational changes to the library with numerous methods being renamed and moved, by and large the changes are all search-and-replace friendly. Other changes, like those to Class, aren’t likely to affect existing code.
MooTools -more Has a Posse
For the past year or more the focus among the MooTools developer team has been to continue to refine the MooTools core. The changes made there are mostly refinement and enrichment, but to a great extent are not really about new features. With MooTools 1.2 the various interface oriented files were split into mootools-more and haven’t really been touched in a long time other than to fix bugs and whatnot.
Starting today this split is becoming even more pronounced in that the -more files are going to be considered their own project. To that end these plugins and new ones will have their own development team and their own mission, namely, to expose to the MooTools community the plugins authored by the MooTools -more development team. By default, this group is defined as the developers who have been contributing to MooTools for a while now, but the scope of the files will broaden greatly. The definition for a good plugin for mootools-more will be “Any well written plugin that serves a reasonable use case that is contributed by someone willing to continue contributing to mootools-more.” Simply put, expect to see lots and lots more plugins for your use.
To manage this new project and team I (Aaron) have been tapped to put together the development team. If you’ve ever visited my site (Clientcide) to download plugins you’ll know that I have a lot to share. In the coming weeks expect to see a lot of these plugins (not all of them) move into mootools-more and become official MooTools plugins. Expect to see more plugins from MooTools contributors as well as plugins written by others who are interested in joining the team. We mean you. Expect more on how you can help out in the coming weeks as well as an official roadmap.
2009 is going to be a great year to develop with MooTools. We’re very excited and hope you are too.
February 2nd, 2009 at 10:43 pm
Who was talking about the mootools’s death? :P
Now I’m very excited too! Thanks for Moo guys!
February 3rd, 2009 at 12:36 am
I’m excited for the changes. Mootools-more sounds a lot like the infamous forge. On a side note, I was wondering how far along 1.3 is?
February 3rd, 2009 at 1:18 am
1.3 is still in development. It’ll be done when it’s done. That said, a lot of the work has been completed in the code. There’s still testing, documentation, and other chores. It’s likely that the new MooTools -more will be available before 1.3.
February 3rd, 2009 at 2:24 am
sweet. i’m excited about this! thanks devs! <3
February 3rd, 2009 at 3:11 am
I’m very happy to start my morning in these way. I’m sure that this is the year for great work with MooTools. It give to me power not comparable with other. I love this formula: MooTools+AIR+APTANA+EJB3=Rock ‘n Roll..
Happy MOO Year to all of you Nunzio
February 3rd, 2009 at 3:54 am
Am so glad that some proper promotion and development of Mootools is happening… I always thought that it was the best framework but with the recent lack of development/news I was beginning to think that I’d picked the wrong library to develop with!!
February 3rd, 2009 at 4:21 am
Will 1.3 have native XML support? I think it was mentioned at one point.
February 3rd, 2009 at 5:40 am
That is really great news!
Will the Mootools-more build have support for the same browsers as the core build? I’ve seen that some examples at clientcide are buggy with Opera… :(
On a side note, one of the things I was really expecting from the Class class was beeing able to make my own build of the Core/Class scripts without beeing forced to add all those (great by the way) custom methods to built-in classes prototypes… do you think that would be possible in the future? It would be very cool since one could download a tiny core that works with other libraries and does not “”“”“”pollute”“”“”” built in objects prototypes.
February 3rd, 2009 at 7:04 am
Good news, delegate will also work with focus and blur?
February 3rd, 2009 at 7:59 am
This is great! And the defined can become Type.isUndefined()… maybe… And just one correction, lambda wont be Function.lambda() anymore it is now Function.from(). Have fun!
February 3rd, 2009 at 8:43 am
w00t! guess it’s time to get some stuff done so it can make it to -more or at least contribute to the always growing community.
February 3rd, 2009 at 9:34 am
You mention the compatibility layer will be built in by default. Will there be an option to remove it if we want to? I prefer to spend time modifying my code (which usually gets slimmer with each release) and having a smaller core.
Also well done and congrats, Aaron, for heading up the More codebase. Having an officail set of plugins is one of the things that drew me to Mootools in teh first place and i’m excited that these will be expanding.
February 3rd, 2009 at 10:03 am
Whoa, whoa, whoa! Don’t take Hash out of the Core! I use hash in pretty much every site. It’s extremely useful and does not feel like a plugin. For the love of God leave it where it belongs.
February 3rd, 2009 at 10:36 am
Great! I’m waiting for MooTools 1.3. Thanks.
February 3rd, 2009 at 11:23 am
I’m lookin forward to the new changes that Mootools will have to offer!
February 3rd, 2009 at 12:06 pm
Glad to hear some updates for 1.3! XML support should be added onto -more. The great thing with MooTools is that all the things said above are already possible in the current version. Although, the new separation between core/more will allow much easier and more active into the contribution of plug-ins. The year of the Moo it is :)
February 3rd, 2009 at 1:40 pm
Great work guys. There is already so much in Moo that I didn’t think a new version was possible :). All the best. -DZ
February 3rd, 2009 at 1:58 pm
Is it possible to host the Mootools More code on Google Code???
February 3rd, 2009 at 2:13 pm
@Bartek, I believe that 1.3 should have XML support, yes.
@Nicolas, the Opera issues in the clientcide libraries were due to a but in MooTools 1.2 core, I think that these have been overcome in the latest version of the library (the new Class.Binds in particular), but regardless, the portion of the clientcide libs making it’s way into the new -more at the beginning will not have this dependency or this problem (the affected scripts will likely wait until the problem is fixed). Our goal is support in all the A-level browsers, including Opera.
As to your question about a version of -core that does not alter prototypes, that is not planned (for 1.3 at least).
@Danillo the new version of delegation will hopefully support blur and focus, yes. This portion of the work has not been completed yet, so we’ll have to see.
February 3rd, 2009 at 9:36 pm
What is happening with 1.2.2?
February 4th, 2009 at 2:08 am
Great news guys! You’re hard work is much appreciated!
February 4th, 2009 at 6:13 am
Thats good news, but does “core” really need to pass $Hash over to “more”. I and many friends are developing web applications so every detail counts, I’m not sure how I’ll go ahead with MooTools if every time I need to use the $Hash it means including “more”.
February 4th, 2009 at 1:08 pm
Good job guys. I’m curious if you guys will be focusing on speeding up DOM manipulation. I don’t want to say it, but jQuery did a great job at that recently with 1.3. Also, I think that the Privates mutator should be included by default. I think it would make classes much cleaner by separating private and public variables (good OOP) as well as removing the relentless amount of this.* in class code. I’m also think that $pick, $each, etc. should be attached to the $ variable to become $.pick, $.each, etc. It gives them a nice place to live while reducing pollution. Cleaner separation of -more, I think, will be fantastic for the community. Keep it up!
February 4th, 2009 at 5:30 pm
This is all very exciting news. So, how do I partake in contributing to -more, aside from releasing my code on my own?
February 5th, 2009 at 10:15 am
Having the compatibility layer bundled in the core is probably the greatest news i’ve heard today :). Upgrading from 1.11 to 1.2 was almost impossible, even with the compatibility library…
February 5th, 2009 at 9:35 pm
Excellent. The drop-in aspect will be quite nice. We are just finishing up a 1.1 to 1.2 upgrade and its been very enlightening. You should move the “drop-in-and-code” bullet to the top of the list and circle it a few times so people really get that upgrading won’t be that laborious anymore. Anyway, we love using it and it was worth the time.
February 6th, 2009 at 6:06 am
I hope you guys also include Event delegation for Drag-n-Drop support too if possible.
February 7th, 2009 at 8:56 pm
Great to see that there’s movement and that intel gets out more frequently. Keeps users happy and confident in using the übermighty MooTools.
One particular feature I’d love to see in the future is namespacing Moo. And something like jQuerys noConflict alongside. I’d never put my hands on jQuery (I swear!), but this one is really tempting and makes integration with other frameworks/scripts convenient.
However, keep up the good work!
February 8th, 2009 at 2:40 pm
Great to hear about 1.3! I find 1.2 to be super stable but everything can be improved! I love the possiblity of moving the core functions into objects… very OO and just makes good sense…
The continued seperation of core and more is also a great idea and I think it will work out. I wish MT the best of luck and hope to be able to contribute to more!
February 9th, 2009 at 2:13 am
@Brandon, 1.3 will replace 1.2*
@doomedlung, Hash moving to -more isn’t a bad thing. You can still download it and use it of course, it just won’t be in the core distribution. You’ll probably find a lot of new things in -more soon that you’ll want anyway.
@Scott, DOM manipulation is very fast, as fast a jQuery (see the blog post here on Sizzle). The comment about removing this.* references doesn’t make sense, as this is a huge aspect of writing OO based JavaScript. Having a lot of this references is a good sign of good JavaScript.
@Garrick, if you want to contribute to -more you just need to write good code and reach out to us. There are a lot of ways you can contribute from testing, writing demos or docs, writing code, or giving feedback. If this sounds interesting to you, drop into IRC or post to the mootools google group with the ways you’d like to get involved and we’ll get you started. You can also ping me (Aaron) personally.
@J3D, MooTools already supports Drag-n-Drop. Event delegation will be available in MooTools 1.3, but you can get a beta version on Clientcide.
February 13th, 2009 at 5:16 am
This is the chinese year of OX(Mooooooo Mooo). Moo help me to be a happy man when dealing with Javascript. It make my javascript life easier. I love to Moooo…. Thanks for your hard working effort.. May wealth come to you all…my Moo developers…
February 13th, 2009 at 4:34 pm
It seems that we should be encouraging Mootools newcomers to be aware of and use the Hash goodies, since they were such a big deal in the Mootools 1.2 launch. By moving them to “more,” I fear that they won’t be seen or used. This is mostly due to the way Mootools is currently made available for download, which discourages people from get the “more” part.
Requiring the download of a second file to obtain “more” functionality is confusing, unintuitive, and tedious. Some developers will object to loading separate JS files for “core” and “more” from their HTML. Of course, they can merge the files into one, but that’s more work on their end.
To make the situation worse, the process for obtaining “more” functionality requires using the More Builder, which is cumbersome in itself. The More Builder does not have an easy “select all components” option and thus is much more tedious than it should be. (This applies to the Core Builder as well; building a “core” without one component should be “select all, then uncheck what’s not needed,” not “check each component except…”)
As a result, it is not easy for developers to jump in and play with everything that Mootools offers, and I believe that is impeding widespread adoption of the framework, compared to other frameworks that offer their power in a single ready-made package.
I think it’s a great idea for Mootools to offer customizable downloads; I just think it could be done much better. For one thing, I don’t see the point in having two separate files and two separate builders. It would be better to have a single builder including both “core” and “more” components, more like the 1.1, which some UI magic to make selecting groups easier, such as “Select All Core” and “Select All More” buttons.
Actually, it would be even better to follow the UI set by OS X custom installation boxes: a hierarchical set of checkboxes, where the user can click a triangle to drill down and select individual components, or just check the Core or More boxes to select all the respective contained components.
Either UI approach proposed above would enable the user to quickly select the big groups in a couple clicks and then add or remove individual components as desired. This builder would yield a single JS file, compressed as chosen by the user. It’s simpler, smarter, and less tedious than the current download tools, which is I think what Mootools aims to be. And it also encourages newcomers to try the “more” components and perhaps someday contribute their own.
I’d be happy to code this new builder, as I think it was make Mootools a lot easier to acquire and help grow the community.
February 14th, 2009 at 7:45 am
Excellent! MooTools without doubt offers the best JavaScript programming environment (MooTools+Aptana+EJB indeed). Happy that MooTool Core is staying slim and that MooTools is still alive — thanks for the update.
Re: -more; Perhaps there a plugin coding/nomenclature convention (in addition to that code style) should be considered before anything is added? Also it’d be great to have a drive for a community to manage the QA and cataloging of libraries…or would that be down to Clientcide?
February 14th, 2009 at 1:54 pm
@Ollie, I’m not sure what you’re asking there at the end. If you’re saying it would be nice to collect all the MooTools plugins into one place I agree, but that’s something that requires software (a plugin repository) that we are slowly working on.
February 16th, 2009 at 5:47 am
Hi Aaron; correct, the Clientcide plugin repos is great start with the builder and docs. My comment is really about how it all hangs together, for examples linking the plugin list to directly to their doc page, allowing users to post examples on the doc page, quality control assurance on a plugin (e.g. a “MooAssured” stamp). In my mind all these things help build quality and confidence into a framework. I understand these things take time (I wish I could impart some of mine to MooTool!).
With regard to the nomenclature, for me this is extremely important as an API where you don’t have to read any docs is an API that I want to use. For example a plugin called FixPNG rather than Browser.FixPng troubles me :)
February 21st, 2009 at 5:11 pm
MooTools is very good :) but how along till 1.3?
February 21st, 2009 at 6:00 pm
It’ll be done when it’s done. We can’t really commit to a specific timeline.
February 22nd, 2009 at 1:33 am
Hey Aaron. Very good news. I think this shift will be incredibly helpful for further development.
I saw this asked, but I didn’t see the answer. Do you have any thoughts about hosting -more on google’s AJAX Libraries API? I know that means no “building” and people would wind up including more than they need. But I think the benefits are still worth it.
February 22nd, 2009 at 2:32 am
No, I don’t think it belongs on Google’s CDNs. -More will be far to large if you included all of it. The builder is a must.
February 26th, 2009 at 4:49 am
Great news. Go MooTools team!
March 3rd, 2009 at 6:49 pm
I will and always love mootools despite everyone using jQuery. At work they are using jQuery. Booo. No clean class inheritance.
I think I am going to start putting some community hours to promote mootools and make a great Mootools Plugin Repository.
March 8th, 2009 at 9:52 pm
I can’t wait until this comes four! Keep up the great work!