MooTools First Impression
I’ve been getting more Joomla work thrown at me these days (one of the nice things, from a professional’s POV, about the Joomla community is there are so many amateurs building Joomla sites there’s never a shortage of installations that need fixed) so I decided I needed to get more familiar with MooTools, the javascript library the dev team chose for Joomla.
This makes the third javascript framework I’ve been working with (prototype/scriptaculous for Rails, and jQuery for my non-Joomla PHP and .NET projects) so while I certainly don’t hold myself up as an expert in frameworks, I’m not fresh from the farm, either. I’d already written the usual “cute effects” in MooTools (such as rearranging layout boxes, hiding boxes and sliding them out, etc.) so for the first “serious” project in MooTools I chose to implement the FontUnstack jQuery plugin. (from an idea by Andy Clarke as implemented by Phil Oye at GitHub.
The journey was interesting, to say the least.
I couldn’t find a HOWTO to get me started. I tusked around for a while on the net and found several supposed tutorials on writing MooTools plugins, but none of them gave me what I needed to start with. They were all about adding classes to the framework, and that’s not what this was supposed to be doing.
So I dove into the codebase itself. After several wrong starts heading down blind alleys, I stumbled on a starting point — the element class. The information I found was divided between Element.implement and Element.extend, so I picked one and began (naturally, I picked .implement and I needed .extend). Then, as the project continued, I realized Element wasn’t the right choice, and it should have been Elements.
Anyway, after about 15 clock hours on the project (time spent mainly on wrong turns and finding out what *doesn’t* work, and trying to separate my own mistakes from what MooTools doesn’t allow) I finished the code. What did I learn?
Barrier to entry is definitely much higher with MooTools than with other libraries. While I would certainly be foolish to blame the MooTools library for my mistakes and wrong turns it does highlight a weakness in the supporting docs. There seems ample support for elementary work with it, what I call “Gentlemen, this is a football” tutorials. But if you ever plan on taking the next step, you’re standing in front of a cliff face with a couple of pitons and a rubber mallet. It’s climbable, but be prepared to work.
I had a few offers of help, but the biggest difficulty was I didn’t know enough about the internals of MooTools to know the right questions to ask. I couldn’t find any sort of guide for plugin writing, which left me standing around wondering where to begin. (Like any other climb, you can’t get up the learning curve until you find some secure footing at the start.) Maybe that was by intention, I don’t know what the attitude is among the MooTools people towards third-party extensions of the library (vs users of the library).
The bottom line from my excursion? MooTools is as capable as the other two libraries (proto/script and jQuery) but my experience failed to give me a reason to use it anywhere but Joomla. The barrier to entry is higher than with the other two libraries, and the performance is certainly no better in any meaningful way. (I’m interested in more than just raw speed. I prefer proto/script for UI stuff, especially things like sortable lists, because it’s easy to set up and extremely reliable, a specific area where jQuery fails miserably, for example.) I find jQuery much simpler to use for the small touches I might want to add here and there, and Prototype/Scriptaculous for the larger js-based systems I build. MooTools just doesn’t fit in that scheme.
Classes ARE MooTools plugins. Almost every MooTools plugin is a class. The only time you should implement things into native objects (like Element) are when you want to add a shortcut to those objects. It sounds to me like you were trying to write jQuery style code that works like so:
$$(‘div’).myPlugin().addClass(‘foo’).hide();
Where “myPlugin” applies itself to all the elements returned by divs. The right way to write such a plugin in MooTools is to… write a class. THEN, if you want a shortcut that applies that class to elements, you extend Element with a method that instantiates that class. Look at Fx.Tween in the MooTools core for an example of this. The Fx class family is where all the logic is, but myElement.tween(‘opacity’, 0, 1); is a shortcut implemented onto Element. This shortcut just creates an instance of Fx.Tween and activates it.
For what it’s worth, as the author of the MooTools book and the Mootorial (www.mootorial.com), I recognize that yes, MooTools has a steeper learning curve.
Did you see this page?
http://mootorial.com/wiki/mootorial/09-howtowriteamootoolsclass
Guess that’s where the disconnect was, then. It didn’t seem to me that a class was the right way to go with this, considering the purpose was to create a box filled with text, style it, read the result, dispose of it, and from that information add a class to a different series of containers on the page supplied as an argument to the process.
Maybe it’s in the definitions we use. To me, a class implies a batch of data and the set of methods that work on/with it, while this was simply a set of methods that worked on nodes of the DOM tree, therefore extending the existing class that worked on the DOM seemed the more natural way to go.
Yes, I saw the mootorials. I didn’t view that particular one because classes seemed to me the wrong way to go about it, but I did follow other links there, including the “30 days of mootorials” one. Nothing seemed like a good fit, so I started searching forums and looking around for a MooTools plugin that did something similar to what I was after so I could dissect it and learn from it.
While I failed in that quest, some discussions on the forums got me pointed towards Element, and I crawled the source code looking for how Element.Dimensions worked, as it seemed the most similar to what I was trying to do. That was my first mental model, and I went on building outward from there.
Your tweets helped, Aaron, but as I acknowledge above, often I didn’t know enough to know how to frame the question properly.
As one coming at it from the outside, I’d say MooTools has an S-shaped learning curve. It doesn’t take a lot of effort to do simple manipulations (I’d written a slideout site login tab in it, for example, with very little diffculty). But then the curve to go beyond that gets very steep (I’m expecting it to level off after that is climbed; most systems do, but since I haven’t climbed it yet, I can’t say for sure that it does).
Your “jQuery style code” example is one I would have termed a “javascript style code” example,as that sort of functionality is built into the language. I was writing javascript like that (where the results of one call are passed directly into a subsequent call and those results passed into another call, etc.) before I ever saw jQuery. (BTW, that highlights another piece of cognitive dissonance I ran into in the MooTools docs. That process is called “chaining” in every other OO language I know; what MooTools calls “chaining” I’d always known as “queueing”.)
Anyway, since my Joomla workload is increasing I’m sure MooTools isn’t leaving my toolbox any time soon. I’ll work through some of the tutorials and look around for your book.
It became clear to me during this process that MooTools is built from a viewpoint that is based on assumptions alien to me (such as creating a class to operate on data that is not contained in that class). Now, by itself different doesn’t imply either better or worse. But where that becomes a factor is the benefit needs to be proportionate to the effort expended, and what I hope I was clear about in this post is that is the only test that MooTools failed, and not any sort of a performance test. It just seems to me if I decided to switch I wouldn’t lose anything much, if at all, I just wouldn’t be gaining enough to justify the effort.
u guys are the best!
nice!