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…
MooTools team: none / occasional contributor
Company / Occupation: Clock Four / Senior Technical Consultant
Famous for: The blog, the magazine, moo4q, SlideShow, MooDocs
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.
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.
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…
dojoand 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.
- Who is going to maintain this code?
- 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?
- 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 😀
- Your editor’s documentation
- People, mentors, mailing lists, IRC
- Early morning hacking–your mind solves the problems in your sleep, dead serious
Is that your ostridge there? Thanks for your time!