Our next mootools interview is a a bit long. Let it not be said that I did not warn you – but it’s worth the read. So, without further adieu…
One of the biggest “names” you are likely to hear whilst talking about MooTools (or even javascript in general) is that of Aaron Newton. Through his time working for CNET, Aaron adopted the use of MooTools and started contributing a lot of practical plugins that ended up as the base of the official MooTools plugins repository, also known as mootools-more. He has also written a book, given talks and worked very hard at promoting MooTools to the rest of the world. Author of the highly acclaimed and mootorial (hello world guide for mootools) as well as the ever-so-slightly controversial website jqueryvsmootools.com, you cannot hope to meet a nicer and more patient MooTool-er online. We catch up with him and ask him a few questions…
Nickname: nutron, sometimes anutron
Country: USA
MooTools role: Lead developer for -more
Age: 35
Company / Occupation: Cloudera / Senior UI Developer
Blog: http://www.clientcide.com
Website(s): http://www.clientcide.com
Twitter: @anutron
GitHub: https://github.com/anutron
Famous for: Client(SC)ide, MooTools-more, MooTools Essentials book,
Programming to patterns talks, jqueryvsmootools.com,
The Mootorial
I started my own company in 1999, a music site called Epitonic. It kinda died when the rest of the web did. I joined CNET as a product manager and built more music oriented sites there but slowly moved into technical product management focused on internal projects. At some point I hacked together some prototypes for the network and was annoyed at the lack of JavaScript infrastructure.
I took it on myself to research all the budding frameworks, pick one, and standardize the whole company around it. I started w/ Prototype and Moo.fx but when MooTools came out I quickly latched onto it. I started blogging all this, originally as an internal blog for CNET developers but later as a public blog where we started releasing all the things I was putting together. If you feel like it, you can read my initial impressions of MooTools in this post and a followup that I posted shortly after that.
Since then I’ve been active in the MooTools developer community non-stop. I left CNET and did another startup on my own (www.iminta.com) and then in 2009 I joined Cloudera as employee number 10. Cloudera now has six front-end developers (including Thomas Aylott ed: “SubtleGradient” of mootools-core and Slick teams), all cranking out MooTools code.
But, that said, in general over the years I’ve made it a priority to make the framework easier to learn, adopt, and use out of self-interest. I genuinely enjoy teaching and helping others, but I do these things for MooTools because I want to see the framework succeed. Where others on the team focus on code quality and features, I’ve focused on stability, documentation, tutorials, message boards, etc. because I want to write MooTools code where I work and if no one is adopting it then there’s no market for it. Already you can see that jQuery, which is a fine library for it’s scope, is the defacto standard in much of the market. This makes it harder for people who see the value of MooTools to find work using the framework. Much of my time is dedicated towards adoption to ensure that the project is healthy and can not only survive, say, Valerio getting hit by a bus, but also allow me and you and others to continue working on MooTools in our day jobs.
Initially I chose Prototype. I researched a bunch of frameworks and I liked Prototype’s model a lot. But the library was really verbose (it was like, 70K in those days) and it didn’t have element enhancements nor effects; for those you needed Scriptaculous – another 70K or so. Moo.fx came out and it was 3K (!). I started building on top of that and then MooTools itself followed. I loved the framework from the start, but it was not even a 1.0 release yet (r87); there weren’t even docs for it. I knew I couldn’t get the CNET engineers to even consider it without those things, so my first contribution was the documentation. I authored these by reading through the entire source and documenting each method. That single week’s worth taught me more about JavaScript than anything before or since.
something wanting, I’d push it up into Core when I could. As I released more and more stuff on Clientcide it became harder to maintain that code and still contribute to Core in any meaningful way.
About two years ago the MooTools development community decided, at my urging, to focus on growth. Specifically to work to increase the number of people contributing to the framework. The dev mailing list went from something like 12 to maybe around 70 today. About that time we decided to pull over a lot of the Clientcide plugins and make them an official MooTools release. If you look at the MooTools More library today there are about 65 plugins (if you exclude all the localization files). About 40 of those came from Clientcide. Nearly all of them have been rewritten by the team (and are much better for it); they certainly aren’t my contributions any more. Clientcide still has about 50 plugins in it (the next version deprecates about 20 of them). All that code is already too much to maintain, so any notion that I might have about contributing to Core goes right out the window. My todo list is already too long.
As for what I would do if I could do anything; if I could just take a week of vacation and work… well, I always have a long laundry list of things that I’m trying to accomplish. I want to improve the test coverage in MooTools More (which is already in pretty good shape thanks to the rest of the More team). I want to implement some automated UI testing with Windmill or Dohbot or something. I have several repos on github that I want to release; the Behavior library in particular. I need to update the Mootorial. Blah blah blah. It’s a long list.
What I’ve learned since then is less about being a better coder and more about working with people. I’ve pushed on the MooTools community pretty hard to adopt a lot of the process and principals that I find in my day jobs. Many of the MooTools developers don’t have jobs as full time developers in a community of developers. They are freelancers or are in school. Valerio spends nearly all his time working on MooTools itself. I’ve had a very different experience working in organizations with dozens or even hundreds of developers. There’s a different priority at work there. At Cloudera I’m surrounded by hardcore developers – some of the smartest guys I’ve ever met. We contribute to a lot of other open source projects (mostly Apache projects) and I see the merit in the structure that those projects have. Doug Cutting, creator of Hadoop, Lucene, Nutch and others, works at Cloudera. He’s the chairman of Apache! I’ve picked his brain a lot about what makes Apache projects succeed or fail. I try and bring a lot of that knowledge to the MooTools developer community. I’m not always successful at it, but there are numerous things that we do now that came from my talks with Doug and others.
I’m a pragmatist. I make things that work and that are extensible, reusable, etc. I often find myself redoing what I’ve done before or extending something I’ve done before usually because I had a lack of foresight in my initial API design. It’s what makes me look so productive. I produce a lot of things that work but they certainly aren’t perfect. I don’t even strive for perfection; I strive for flexibility and functional completeness. I’m not afraid to rewrite something a few times.
That programming to patterns talk that I give is based entirely on my own revelations as a developer. I spent many years doing things the hard way. The stuff I do now is taking that pattern thinking even further (for example, the Behavior stuff I’ve mentioned already). But I can point to several things I’ve authored here at Cloudera that are on their 3rd rewrite.
As for MooTools, I can’t imagine being able to author JavaScript this way without it or something very similar. If I didn’t have MooTools, I’d probably write it myself (only worse) just to keep from going back to the way I used to author code.
As for release, there are two things here; ART, and the widget framework that happens to use it. ART continues to slowly march towards release, but that’s something you’ll have to ask Valerio about. It’s unofficially a MooTools project; as soon as it’s ready for 1.0 you’ll probably see it on MooTools.net, but certainly not Clientcide.
As for the widget framework, that falls directly into the “on my long list of things to do” category. Will I release it? It’s on github now with demos and stuff. The real question is will I find the time. The more code I release, the more stuff I have to maintain. The value of open source software is that if it’s useful you find others to help you maintain and grow it, but even that takes a time investment. I’d like to think that as Cloudera matures a bit we’ll be able to focus a little more on packaging this stuff up and pushing for others to adopt it…
These days I focus on the current release. When Core goes into testing and its API is locked down, that’s when the work on MooTools More gets safe to start. I’ll point out that the rest of the MooTools More team, in particular
Tim Wienk, Arian Stolwijk, and Christoph Pojer, were instrumental in updating More for 1.3. I contributed very little to that effort I’m sad to say. Cloudera has yet to upgrade to 1.3, though I hope to do that soon.
As for the web site, I’d like to see it more focused on adoption. The new Demo environment is a good start in that direction. I’d like to see more tutorials and more community engagement. The guys working on the site are awesome, but like me they have other responsibilities to their jobs and families. We can only go as fast as we can donate time.
- jsFiddle obviously; no surprise
- JSLint – I use TextMate and have this integrated to show me errors and warnings when I save a file. It’s a life-saver.
- Git and gitub have both changed my life.
- I love ReCSS (http://david.dojotoolkit.org/recss.html); WTFramework (http://nouincolor.com/wtframework/2.0/) is also pretty cool
- j for command line work is another huge time saver (https://github.com/rupa/j)
- I love visor for the mac (http://visor.binaryage.com/) – my command line is never more than a single keystroke a way
- I regularly visit the Mozilla Developer Center for docs on JS, HTML, CSS (https://developer.mozilla.org/en-US/)
Thanks once again!
[…] This post was mentioned on Twitter by Arian Stolwijk, Dimitar Christoff. Dimitar Christoff said: A brand new #mootools interview (intermoo, that is): A "small" chat with Aaron @anutron Newton – http://bit.ly/dXyc8p #javascript […]