The MooTools 1.3 Upgrade Path
In the last week or so Valerio and others (myself included) have been working on the changes that are headed for MooTools 1.3. You can dig around in git-hub in various developer branches and see some of this stuff flying around, but frankly, it’s all in rough draft mode and is likely to change.
One of the points of discussion are all the $ methods. $type, $lambda, $try, etc. are all in the global name space and kind of just… there. They exist as stand alone methods because, by and large, they don’t really belong anywhere. In an effort to both clean this up a bit so that methods are where they “belong” as well as to clean up the global namespace a little, Valerio and others are discussing where to put these things.
Currently, the thinking includes:
- Where possible, put the methods on the constructors. So, for example, $lamda becomes Function.lambda and $date becomes Date.now. This works for many things but doesn’t for some items, which really don’t belong anywhere. For instance, $exec becomes Window.exec and $pick becomes Object.pick.
- Some items will remain in the global namespace. These include $, $$ and $type will become typeOf.
Remember that MooTools extends native elements as well as has all its classes in the global namespace, not to mention that $ and $$ aren’t going anywhere, so it’s not like these changes have a big impact on the footprint that MooTools has on the global namespace. The goal isn’t so much to get things out of the global namespace as much to put things in their place.
Other planned changes for 1.3 include numerous bug fixes and some additional features. Examples here include event delegation (which will probably use the same syntax as my version of this, though the inner-workings will be much more integrated into the framework, as it should be), a noCache option for Request (based on my version), a new version of Class that offers greater flexibility especially for mutators that currently require a lot of hacking to get to work and there will of course be numerous bug fixes and the like.
Finally, Hash is likely moving from mootools-core to mootools-more. I’m not thrilled about this one, as I use it a lot, but it’s not like I can’t build my own copy of the library.
Upgrading
The upgrade path from MooTools 1.11 to 1.2 was painful. I still have code around that I haven’t upgraded. It’s especially painful for me as whenever new features are added or the API changes I have to fix the mootorial, update my book, and all my plugins, not to mention my actual projects like Iminta.
But I recognize that the framework’s goal is to be as perfect as the developers can make it. Like any programmer, what is “right” or “best” is something that is constantly in flux, so it’s not unreasonable that after using MooTools 1.2 for several months that certain things might begin to nag at its authors, things that are out of place or should work better.
As far as upgrading is concerned, most of these changes would have little effect on the users of the framework, I think. All the $* name changes would necessitate a search-and-replace, but nothing more serious – the methods would still work exactly the same. As always, there would be a compatibility layer that would translate these things back to their original names, so the search and replace wouldn’t even be required.
The movement of Hash to mootools-more will only be painful if you’ve been using the hash methods on items in the core that used to be hashes (like Browser), but again, that’s easily fixed (Browser = $H(Browser); and you’re done).
The improvements to Class are likely to be things you won’t notice unless you’re in the habit of writing mutators or really low level extensions to Class. The new features and bug fixes should be welcome and won’t require any adaptation of existing code…
So what do you think? We’re looking for feedback here and the more we get the better.
Follow @clientcide on twitter to get notified of new posts.
To follow me personally on twitter, follow @anutron.
January 23rd, 2009 at 2:32 pm
What is the thinking behind moving Hash to MooTools-more? I would hate to see this but I’m sure there is a good reason for it.
January 23rd, 2009 at 2:35 pm
Sounds good to me. The move of methods to constructors seems “more moo”. I’m also encouraged to to read that you consider the 1.1 to 1.2 to have been painful and that you’ll work to make the 1.3 move less so.
I’m glad that MooTools will stay small and focused and you’re not looking at adding things that have no business being core.
January 23rd, 2009 at 2:37 pm
@Jonathan, the only real reason Hash would move into m-more is that the core doesn’t need it to function. It’s not like you couldn’t keep using it. I know I will.
January 23rd, 2009 at 2:43 pm
It doesn’t look like there are many changes so far, so there isn’t much to comment about yet. I too disagree with moving Hash out of core, but at the same time I can see why you’d do that.
Upgrade paths can be handled nicely by writing documentation. This involves someone sitting down and writing out exactly what backwards-incompatible changes have been introduced, and how to fix existing code to comply. Then instead of stabbing around in the dark trying to get your scripts to work, you have a handy document you can run through to upgrade your own scripts.
It IS also possible to write automated tools for this sort of thing, though it’s complicated because it involves using a JavaScript parser and analyzing then transforming the code. This is what the Python project have done for their recent major 3.0 release – http://docs.python.org/library/2to3.html, though I would argue that it’s significantly easier for them to pull this off since they develop the whole language.
January 23rd, 2009 at 2:46 pm
Please make Swiff work with XHTML served as application/xhtml+xml.
January 23rd, 2009 at 2:46 pm
Okay, your blog’s commenting system’s preview function is inconsistent with the final output. I had ended up using paragraph tags, but it looks like it went and stripped them out.
January 23rd, 2009 at 2:46 pm
I’ve been following the discussions on the IRC channel and I’m all for cleaning up most of the dollar utilities, but I think the naming conventions should really be worked out in a way that would not create too much confusion.
While it will be easy to do an F&R on existing scripts to correct them in light of these naming changes, confusion would more likely ensue from developing new scripts while still carrying the 1.2 mindset–especially if the names of the dollar utils in 1.3 no longer correspond to their old 1.2 counterparts (like the temporarily named Function.stab instead of $try).
$type()’s analog for 1.3 should also be given a better name than “typeOf,” which looks hauntingly like the native typeof function. It would be too easy to fall into debugging hell by forgetting to capitalize one letter.
Other than that, I’m pretty much excited about the changes for 1.3. I’ve been expecting the sending off good ‘ole Hash to Moo-More land for a long time, and the changes to Class look very promising, especially the new changes that’ll enable privates.
In any case, I’m looking forward to the next release.. :]
January 23rd, 2009 at 2:51 pm
I think coming up with a Utils object for the $* tools makes more sense. Object.pick is not really meaningful, for instance.
January 23rd, 2009 at 2:59 pm
@Ycros, paragraph tags are enabled again, I’ve edited your post for the line breaks.
January 23rd, 2009 at 3:00 pm
I agree with Keeto’s typeof vs typeOf concerns, I think $type is much more explicitly separate.
As for privates on classes, coming from a Python programming background I don’t think these are useful at all, and may impede extending some classes if people go crazy and start privatizing all the internals. I have seen this happen all too often in other languages, and then you have to go and hack up the original class when you mightn’t have needed to.
The counter-argument of course is that people should consider the extendability of their classes and carefully only expose the parts which should be extended. Unfortunately my experience shows that this is often not the case. I like Python’s philosophy that “we’re all consenting adults here” when it comes to privates.
January 23rd, 2009 at 3:00 pm
I kind of think a Utils object sounds nice, but it makes more sense for each of these functions to belong to their respective constructors.
I agree that typeOf vs typeof is scary also, though admittedly, they’re written different too: typeOf(value) vs typeof value. Still scarily similar.
Wouldn’t Function.pick or Array.pick make a bit more sense for $pick? And if $try is becoming Function.stab, I vote no! Function.try makes much more sense.
Curious to see the Class changes. I imagine it helps with specifying on a per-instance basis?
January 23rd, 2009 at 3:04 pm
@Sean, all the names are in flux. Function.stab is temporary. Function.try won’t work because try is a reserved word in JS. As for pick, the key is that pick works with anything, so $pick(x, y, z) doesn’t care what kind of things x, y, and z are, hence Object.pick. The class changes would give Class events for beforeInitialize and afterInitialize, so that mutators and extensions could easily alter a class before or after their initialization phase.
January 23rd, 2009 at 3:07 pm
I feel that the global functions need to remain available till around 1.5, but feel supportive of moving them to more appropriate places where it makes sense. Put up a notice that they’re deprecated in the docs. Please though, don’t make a repeat of last time’s compatibility layer. Just build the aliases right in to mootools for now.
I also use Hash a lot. I’d like to see it remain in Core. I use Hash a lot more than I use Request.HTML and Swiff, that’s for sure!
All the other stuff sounds great. :)
January 23rd, 2009 at 3:11 pm
Note that the compatibility layer for these changes would be very straight forward and more reliable than the compat layer for 1.11>1.2, which had to deal with some complex breaking changes. I seriously doubt that the compatibility for these methods would be left in core (that’s the whole point of the compat layer).
As for Hash, again, there’s nothing keeping you from using it. It just wouldn’t be a part of core.
January 23rd, 2009 at 5:07 pm
I like the nocache on request feature. I’ve been wanting that for a long time.
I’m looking forward to the forge, I only hope its as robust as jquery’s. I still feel strongly that the lack of plugin submission system for mootools has caused the rapid decline in mootools adopters.
I would also like to see the demos section expanded or at least bring back the online view of sourcecode. I’m sure a lot of people don’t feel they should have to download a zip file, extract it, and run the examples to try and pick apart the demos.
January 23rd, 2009 at 5:30 pm
I understand why Hash is moved to “more”, and like you say, nothing keeps you from using it. But that’s really not the first one I had in mind for that. What about Swiff, Request.HTML/Request.JSON or Cookie? Those inflates the size of the core while they don’t seem vital either and a lot less used than Hash. And these are the most obvious. Then we could argue if the whole Fx should go to more or not (I personnaly remove morph and transitions most of the time). But again, every one is free to build the mootools he likes, I just think Hash an odd choice and not the best candidate.
But I’m just bitching, I love mootools, and I trust you guys to make it a better library. It’s just weird to see such radical changes and compatibilty issues when increasing of only 0.1 in versions (talking about functions renaming here).
January 23rd, 2009 at 7:11 pm
It is great that MooTools follows a path that I can deeply understand. Breaking compatibility gives the best chance for innovations to be implemented. It makes it possible to remove old code and to rethink how things work other than having unnecessary bloat for legacy api calls available. It is not that the way we are going to use MooTools in the future will change or that the basics will break badly (like a completely new class system), currently it is ‘only’ renaming of functions and a (lot) better class system. Most changes will be under the hood and I guess the compatibility layer from 1.2>1.3 will work better than from 1.1>1.2 (not that I care about that stuff, but .. anyway).
January 23rd, 2009 at 7:25 pm
The documentation of a framework is the pillar of the project. Actually, the search in docs don’t works because isn’t well googled. And a lot of links are broken.
I suggest a wiki if the author have no time to update the docs. The demos of mootools 1.2 are worst than the 1.1, so pleace keep the useful structure of 1.1 demos but updated to version 1.3. Thanks a lot for your great work
January 23rd, 2009 at 9:57 pm
I’m in pretty much total agreement with Olivier about Hash being the only class targeted for movement.
I understand Fx remaining part of the core since it is actually where the library started but Swiff in particular and Cookie to a large degree seem a little out of place.
On the other hand, unlike Olivier, I remove Fx.Tween whenever possible because a Fx.Morph object can be used with just one property but tween can’t be used with two.
January 24th, 2009 at 12:00 am
“I remove Fx.Tween whenever possible because a Fx.Morph object can be used with just one property but tween can’t be used with two.” That makes sense, I just don’t use much effect, and when I do, it’s just for fading and simple things. For more complex animation I like Fx.Elements (especially with link:’chain’). I remember reading about simply removing it on lighthouse, I hope it won’t happen
January 24th, 2009 at 2:00 am
“Why do we need Fx.Tween and Fx.Morph, my opinion is that you could put these together and still have the same functionality as both, should be as simple as throw away the tween version and check if the parameter you pass Morph is a object or a string.
Buy maybe there’s more than the syntax that puts these classes apart?
January 24th, 2009 at 2:38 am
We want backward compatibility. Absolutely. I’m frustrated to change every single script to let it work with the last major release. The upgrade path from 1.11 to 1.2 is orrible.
Please, it’s absolutely necessary a backward compatibility.
January 24th, 2009 at 5:19 am
I’m also disagree with removing the Hash from core as I use it all the time and I think it is a core functionality of the mootools library. There are a lot of better candidates for moving from ‘core’ to ‘more’, like Swiff and Cookie, as mentioned above.
January 24th, 2009 at 8:28 am
A few thoughts:
* I’m in favor of what the Moo team believes will improve the framework and that not making changes to avoid community fury is the wrong way to go about things.
* The key to avoiding community revolt is education. If the Moo team explains why the changes were made and how they will improve the framework, users will appreciate the updates. Of course there will be some people that bitch, but you can’t avoid that.
* Compatibility scripts will go a long way.
* I think that a Utils class would be a good solution to the “$” function removals.
January 24th, 2009 at 8:29 am
IMHO, MooTools should keep a close look at what’s happening with EMCAScript Harmony and what the future will bring in the terms of class-oriented programming in EMCAScript.
I see the MooTools Core as an almost transitional framework until we get better standard implementations since it is so low level compared to other JS frameworks. That’s what makes MooTools stand out. Therefore MooTools needs to always be changing and adapting to future changes in the language and changes in the browser APIs. Even if it is breaking changes.
I’d suggest taking a look at what’s happening in HTML 5 and EMCAScript harmony to get MooTools more in-line with those features. We (Calyptus) have started some work on some lower level MooTools style Drag and Drop and ContentEditable HTML 5 features which are backward compatible over in our svn.
Perhaps MooTools also need to adapt the class-oriented architechture. What consequences will Object.freeze() in EMCAScript Harmony have on Class.implement()? Maybe all Class functions should implicitly bind the “this” reference to the object to simplify event driven programming (as it is on EMCAScript 4 draft based implementations such as ActionScript)? Perhaps there’s something in class reflection that could be improved?
That’s the kind of things I think should be the focus of the MooTools team. What makes MooTools great (better than JQuery) is the low-level stuff.
January 24th, 2009 at 8:58 am
I agree with oliver and some others… Hash should stay as a core component as it is really useful, and Cookie and Swiff could be removed, since they match the same argument You are using to remove Hash:
“the only real reason Hash would move into m-more is that the core doesn’t need it to function.”
There should be a formal document or post on the blog telling the differences between 1.2 and 1.3 and how to upgrade your code.
The docs really needs to get our of the versioning system, it needs to be updated at the time you do the change… sometime ago i sent a ticket about an error at the docs, JK fixed it but the fix is not there yet because we are waiting for the new version of mootools to be released… this should not be happening…
Not to mention the broken search… wish is broken for a long time (maybe waiting for the new mootools version? :S).
Harald’s plugin repository project will be a very good add.
Finally, congratulations for the great work you are doing, Aaron, on writing posts and stuff about mootools. It’s a job thats really needed and that a lot of people don’t like cause it takes a lot of time. Thanks for bringing mootools blog to life again.
January 24th, 2009 at 9:00 am
“The docs really needs to get our of the versioning system”
should be:
“The docs really needs to get *out* of the versioning system”
January 24th, 2009 at 1:04 pm
I have to say that I like the methods as they stand. From a purely nomenclature stance changing this in 1.3 after the 1.1 – 1.2 transition is going to further obfuscate the meanings of many of the methods and have what benefit? “In its place” – that seems like such a relativistic assessment.
3 things I would like to see 1.3 hit hard are:
- Event Delegation (Arron, been using yours since you worked it out with Jan)
- The Forge – RedRacer
- Documentation of hidden or advanced features and operational uses (example: “I want to close all accordion panels on load” – set the open panel option to -1 – things like that).
3 things to think about for 1.3 and beyond:
- IE8 is coming…it doesn’t play that nice with a lot of sites and frameworks I have been checking it with.
- ECMA 4, whenever that comes out I am sure it will have needs.
- Evangelism of Mootools – This framework is awesome, and for my part my application will be taking its shots with what it can do. There should be more spirit, this is a movement and a direction of development for many who make really interesting sites and apps, let’s start highlighting efforts and acting enthused! Do I mean that we act like J. (2nd Coming) Resig and go all rock star, “look at me”, on the web? No. What can we can do that gets the framework more adherents and attention?
Highlight sites that use Moo well,
Push out some of the community articles to known blogs Ajaxian, Webappers for example: http://msteigerwalt.com/articles/2008/07/18/SpecialFriends – This rocks! Why is it under a rock?!?
Further than the Forge (RedRacer), Mootools lib folks should “induct” into the offerings of the More builder the most excellent and reusable of plugins and class snippets. This creates a brinksmanship-like race to build plugins inside the community and really draws the attention of new users.
Those are my thoughts, and I’m sticking to them.
- Peace
January 24th, 2009 at 1:40 pm
Can you please arrange it so that Google Code will ALSO host the mootools-more library.
Also, some helpful functions like:
Element.hasEvents(‘type’);
Also, some very basic methods would be good too:
Element.hide(); //display=none
Element.show(); //display=(inline or block … depending on what it was before)
Can we also get the $E method back, or atleast make the $() method support selectors like JQuery does (I’m sick of using document.getElement).
More Plugins would be great as well! Thanks!
January 24th, 2009 at 1:43 pm
One more thing.
Can the Assets classes be apart of the mootools core?
January 25th, 2009 at 10:23 pm
Psssst! If you want CDN-like ability to host Mootools More or any of your other code that is not in the Goog lib selection, just open a Google Code Hosted project and upload your files then like to them there. Shabam! Instant awesome!
January 27th, 2009 at 2:17 am
Congratulations for your page and efford. The book is very good too.
I use mootools and the only sorrow is that the official page of Mootools is ugly and poor (the demos is a shame) – I can say this because I use and love Mootools – (others can’t!).
January 28th, 2009 at 10:03 am
Love the idea of putting these functions where they belong. But my biggest hope for 1.3, and perhaps even 1.4, is compatibility. We create Typo3 sites where I work, and one of our problems is that there’s still alot of extensions using 1.1. I myself write all my code in the newest version and that usually leads to headaches and bosses breathing down my neck :)
I know it isn’t easy for innovators when they can’t change something they over time found out was the wrong way of doing things, but please make the transition as smooth as possible :)
@Matias N
Would like $E back as well :)
January 28th, 2009 at 12:14 pm
Hi Tim,
First, note that you can download $E from my libs (download). But yes, the goal is to make the upgrade from 1.2 to 1.3 much easier than 1.11>1.2 was.
January 28th, 2009 at 3:13 pm
Hehe and Indeed I am.. But I just think it deserves a spot in core
January 29th, 2009 at 3:55 am
No issues for me with the renaming of the $functions, it’s a simple remap.
A good argument for leaving Hash in core is the disruption to pulling the base library from the google code service. Folks already using core from the service plus Hash in their code would potentially have to add another request, though I guess they could also patch the Hash module into their own script. As others have pointed out, Hash is more generally useful than Swiff or others staying put in the core… would a mt developer provide more detail about why it makes sense to move Hash but not others?
Nutshell: Ain’t broke. Don’t fix it.
January 29th, 2009 at 8:30 am
I think the general thinking behind moving Hash and Swiff (and Cookie) to m-more is that these things are not required in order for the Core to work. The same could be said about Request and Fx, but these are really at the heart of what MooTools is for – enabling dynamic interfaces. Hash on the other hand is useful, but frankly so is the native object in JavaScript.
I like Hash, but it’s not like I don’t build my own version of the library every time I use it…
February 19th, 2009 at 10:29 am
I’ve said it before, and i’ll say it again. If you break backwards compatibility, don’t just increment the minor version, but the main version. In other words: call it 2.0 (you should have done that with 1.2 already).
Just my 2 cents….
March 31st, 2009 at 1:07 am
where is MooTools roadmap?
March 31st, 2009 at 7:34 am
There is not a public roadmap for MooTools currently.