Here’s the next instalment in our Intermoos series: we sit and talk with Ryan Florence, one of the most extraordinary and well respected coders, the man behind moo4q, SlideShow, mooDocs and the MooTools magazine. I thought he was Italian (or at least French) for a long time. I was wrong…
Nickname: rpflo
Country: USA
MooTools team: none / occasional contributor
Age: 29
Company / Occupation: Clock Four / Senior Technical Consultant
Blog: http://ryanflorence.com/
Website(s): http://moodocs.net
Twitter: @ryanflorence
GitHub: https://github.com/rpflorence
Famous for: The blog, the magazine, moo4q, SlideShow, MooDocs
After college I was in sales, and eventually ended up working as an implementation consultant for PolicyTech, renewing my interest in web development. Dissatisfied with quickbooks on my Mac I decided I’d learn how to write a web application in PHP and JavaScript to handle my invoicing and accounting. I found scriptaculous first, but couldn’t get some animations to quit bumping into each other; then I found MooTools and its genius Fx module. I was still clueless though, mind you.
Shortly after this, MooTools 1.2 came out. The new documentation flipped a switch in my brain or something. Suddenly the concepts of objects and classes made sense. I rewrote my invoicing application as a single page, desktop-esque, ajax heavy, ridiculously awesome tool that I still use today. As I dug deeper into MooTools I accidentally uncovered a pot of golden, vanilla JavaScript knowledge.
Being self-taught, I put a high value on documentation. I wrote MooDocs to document and release my scripts and provide a way for others to share theirs (no forge yet). That site earned me an invitation into the MooTools developers circle and I’ve held the “MooTools FTW” banner ever since.
I stick with MooTools for two reasons. First, I love JavaScript. The Type extensions allow me to write clean, natural JavaScript–no screwing around with namespaces and abstractions that hide the language:
arr.include(item)
versus ns.utils.array.include(arr, item)
. Second, I love classical inheritance, and object templates. My brain is naturally wired to think that way. The world around me is designed that way–dogs inherit from mammals. The end goal is to reuse code, which I can’t seem to do as well with differential inheritance–which is like, Siamese twins can share the same legs, right?As for using it in a serious application, I dunno. From a MooTool’s perspective you’re really just swapping out the Element, Fx and Request modules for jQuery–which doesn’t really offer you anything new or better than what MooTools already has. From a jQuery perspective, you have to learn so much about MooTools’ patterns, you might as well jump all the way in.
So you’re probably asking why it exists. I use it in two cases. 1) I’m stuck with jQuery and need to do something that I’ve already done in MooTools. I’ve found that usually 10% or less of my classes have to be adjusted to become moo4q classes. 2) I’m delivering templates to a client who only knows jQuery. I can still structure my stuff the way I like to, and they can do whatever they want with jQuery after delivery.
Speaking of which, I just released CSSAnimation, a vanilla JavaScript implementation of CSS transforms and transitions–complete with MooTools and jQuery API extensions. It powers the new transitions in SlideShow.
Two new scripts I’ve been giving a lot of attention to are Channels and Element.Behaviors. Channels is an extended pub-sub pattern that allows you to completely decouple your objects from each other. Element.Behaviors lets you separate your JavaScript from the DOM. The two together have been a lot of fun to work with.
On the SSJS front, CrypticSwarm and I just started porting packager to packager-node. I’ve also recently written an alternative MooTools documentation browser as my first node project that I hope to make a whole lot better now that I’m learning more.
UI – I’d love to have a UI library comparable to Dojo dijit.
Website – I think a node version of the forge will get a lot more interest and contributions from the community and packager support would be awesome. Also, I’ve been promising Darren my time to write a whole boat load demos to help the sorry demos page out.
Dimitar: Yes, I need to get SubtleGradient to say a few words here too…
However, people are writing more JavaScript than ever and need more than just a DOM library. Alex Sexton has an awesome talk called jQuery’s best friends. He’s a smart, influential guy. I think his approach to pull in other tools outside of the jQuery scope is totally appropriate. We are already seeing the advanced jQuery users adopt this strategy.
On the flip side, you’ve got bright developers like Rebecca Murphey turning away from jQuery for their bigger projects. When jQuery users start feeling that “holy crap, what have I done?” feeling with their JavaScript, Dojo is the natural place to go. Just search and replace
$
to dojo
and you’re more than half way there. Nearly every jQuery method has a Dojo cognate. Also, both hang everything from a namespace. This makes it an easier transition than jQuery to MooTools. Add to that its incredible UI library and support and I’m quite sure Dojo will become the top library for non-trivial websites, if it isn’t already.So what about MooTools? MooTools doesn’t seem to care a whole lot about adoption (look at our demos page), so I don’t see us making any sort of huge leap in market share. It’s a completely different paradigm. When all the books freak people out about extending the prototypes of Array and String, etc. or that “JavaScript doesn’t have classes” it adds a level of FUD that some just can’t get over. I do think, however, that our user base will continue to grow with really talented people.
- Who is going to maintain this code?
- I write a lot of front-end templates for clients to implement into their CMS (or whatever). Once delivered, I’ll probably never see it again. Most of the time the client’s developers have little JavaScript experience outside of jQuery, so I use jQuery in these situations. If there are some really sophisticated specs, however, I’ll push the client to use MooTools, or just slip moo4q in the back door.
- Do I need a UI library?
- One word: dijit. It’s a part of the Dojo toolkit, well documented, and therefore likely to be supported well into the future. Everybody ought to spend an afternoon playing with Dojo dijit.
jQuery UI has a miserable API, so I’d never choose it.
MooTools doesn’t have an official UI library so you’re on your own to write and document an API, or you have to rely on plugins that may or may not have good support and documentation now or in the future. If it’s a personal project, however, MooTools, regardless. - Which browsers are supported?
- Occasionally I get to work on something that only has to work in the newest browsers. In these cases I shed all the libraries and go commando with vanilla JavaScript.
- What does the client dictate?
- Sometimes I have to use jQuery, even if another choice would be better, because the client says so (ASP.NET, cough, shipswithit, cough). It’s not worth the fight and I like getting paid 😀
That aside, I think my single tip would be read the source to the plugins in Core, More and the Forge (Core has some crazy JavaScript, but Fx.Tween is easy to understand). When you’re writing something that feels similar to something else, go read the source, see how they did it.
- Your editor’s documentation
- People, mentors, mailing lists, IRC
- Modernizr
- Early morning hacking–your mind solves the problems in your sleep, dead serious
Is that your ostridge there? Thanks for your time!
hrm – I was hoping of a scoop on a new book here but I guess that’s not happening. Anyway, @rpflo FTW
[…] This post was mentioned on Twitter by slik, Dimitar Christoff. Dimitar Christoff said: The @ryanflorence Intermoo: few ostridges, fewer ninjas and more. http://bit.ly/dFfFzZ #mootools #moo4q #javascript […]