I live in Salt Lake City, UT with my wife and two kids (a 3 year-old iPad addict daughter, and a chubby 3 month old boy). I work from home for the bay area creative agency, Clock Four doing mostly front-end development.

My first real job was back in the 90’s cranking out websites as a teenager for a local ISP. I tried to learn C++ in 21 days but couldn’t get past the second chapter. About the time Java applets started popping up on websites the ISP went broke. I had no interest in programming and started selling decals I made at school online (people actually mailed me hand-written checks!)

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.

Oddly enough, MooTools was my first programming “language”. It was my programming university–it taught me to focus on the API, test my code, and program patterns rather than implementations. Now I view everything else with that bias, whether it’s jQuery, Ruby, or Objective-C.

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?

Moo4q definitely elevated my reputation in the JavaScript community and was a lot of fun to figure out. It’s certainly stable, I’ve used it several times in production (it’s just a custom build of MooTools plus a small Class mutator). The site gets about 100 visits a day, mostly to the tutorial page, so I think there are a few folks actually using it.

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.

Haha, yeah. Originally I had hopes of it being a gateway drug for jQuery users to eventually fully convert. But in the end, moo4q is mostly appealing as moo4-devs-stuck-with-q. I don’t think it hurts MooTools adoption, probably helps by showing outsiders quite plainly what it can do. It also serves as a solid demonstration of the scope difference between the two.

Man, I think I have development ADD. Outside of outlining more articles for my site, I’ve been working on a lot of stuff. SlideShow 2.0 is a few commits away, which brings with it a handful of (awesome) improvements and performance gains, including CSS transitions.


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.

My website is built with nanoc, a static site generator built with Ruby. It’s surprisingly powerful, and has sped up my development process at work for building micro-sites and similar projects. Haven’t had the time to give back to the project, but I have some stuff I’d like to contribute.

Core – MooTools Core has had the same API for 2 years (!), it was done right. But I’d love an ES5 shim with no dependencies and more modularity with the Type extensions. There’s a lot of those extensions in Core that are rarely used (string.hyphenate?). At least $chk is gone, which was useful for allowing 0.

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.

I’d still be flying around the country consulting people on how to manage their policies and procedures, making a whole lot less money. I owe just about everything about my current employment to the MooTools community. David Walsh is responsible for 50% of my twitter followers and website visitors, and is always a great sounding board for APIs I’m trying to develop for my plugins. I’ve learned almost everything I know about web development from everybody who hangs out in IRC (and Aaron Newton, who doesn’t). I owe a special thanks to Thomas Aylott, who got me my current job and has helped me understand JavaScript and web development more than he probably realizes. So yeah, without MooTools, I probably wouldn’t be a developer at all.

Dimitar: Yes, I need to get SubtleGradient to say a few words here too…

jQuery will remain #1. Like I said on twitter a while ago, most everything about jQuery is an implementation, making it ridiculously easy to learn. Even with the recent rebirth of JavaScript, most people making websites still don’t know, or care to know, the language. For them, jQuery is the obvious choice, and rightly so.

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.

Good question. Developers switch projects, contracts, and companies so often my motivation is mostly for the person stuck with my code a year from now, which boils down to support and documentation. MooTools is of course my default choice so I tend to ask myself these questions to justify not using it.

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 😀

Actually, I wouldn’t say “learn JavaScript.” When you learn MooTools, one day you’ll wake up and realize you’ve learned JavaScript.

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.

Website – jsFiddle. Plugin – SlideShow. I know it’s my own, but it is so useful for content that shares the same space (not just slideshows) I often forget that I wrote it.

We just launched a new site for Capital One, advertising their student credit card, Journey. I had some extra time so I screwed around with 3D transforms and CSS transitions on the credit-101 page (safari only). It’s this project that led to Element.Behaviors and CSSAnimation.

No, not me, although I did create this. All of my code is pretty much beginner’s luck, which is not the way of the ninja.