Last week I wrote a rather lengthy post lamenting the fact that finding talented front end developers is rather challenging. This led to some nice comments and emails about the topic and more than one suggestion that I not just whine about the state of things without suggesting a remedy; specifically, that I post instructions on HOW to become a JavaScript badass.

I don’t know that I can tell you how to become a JavaScript ninja, but I can give you some pointers. I’ll start out by saying that I learned what I know via a rather circuitous route that I doubt even I could reproduce if I tried…

My Story, In Brief

My road to being a JS developer is not that interesting, if you ask me, but, shrug if you want to know, here are the highlights:

1. I studied music, photography, and graphic arts in high school and some in college, though it wasn’t my major (which was Jazz Guitar – seriously).
2. I learned HTML back when Mosaic was still in use and grew my web skills as they arrived in each new browser update.
3. I joined a startup (knowing HTML in 1997 was a hot commodity) where I learned a bit of programming (Java). I wasn’t really very good at it. I built a really simple CMS with it.
4. In 1999, I somewhat accidentally started a music startup (http://www.epitonic.com) which I designed and built. I built a much more robust CMS w/ a very small dev team. LOTS of vanilla JavaScript.
5. In 2003 I joined CNET as a product manager. I didn’t write much code, but whenever we needed some JavaScript, I rolled up my sleeves and pitched in. I inadvertently became “the JavaScript guy” there and started blogging about my research on clientside.cnet.com.
6. At first focused my work around Prototype.js and Moo.fx.
7. When MooTools first arrived, I was hooked from the start (here’s posts one and two from 2006 of my first thoughts on the framework).
8. I got involved with the project to help drive adoption at CNET. I became a committer and then put together classes to teach developers there (at CNET). This further cemented my role there as “the JavaScript guy” though I still thought of myself (and still do) as a product manager.
9. I left CNET in late 2007 to start Iminta.com, which I’m still proud of. Then the economy died at the end of 2008 and I started contemplating finding a job and found Cloudera (or, really, they found me).

I know, that’s not terribly interesting or informative, but it gives you an idea of what a bizarre roller coaster my professional career has been. For me JavaScript and web development in general has always been a means to an end. I like building interesting products. Writing some JavaScript or some server-side code has always been about making a good web experience but I don’t really care if I write the code or not. I like to write code, but it’s not my objective. My job at Cloudera is the first job where I have principally been an engineer, though you could argue at my two startups that was my job, I’d retort that my job was to design the product and it just so happens that I helped build it, too.

Enough About Me, Let’s Talk About Becoming a JavaScript Ninja

All this about me is really just to put into context the fact that I can’t tell you the right way to become a front end developer. You will have some doors open in front of you as you pursue your goals and they won’t be like the doors opened infront of me. CNET basically paid me to spend roughly a year studying JavaScript and JavaScript frameworks in detail, and that’s a hard job to find. That said, I do think you can reproduce a lot of it on your own and, in some ways, I learned a lot of this stuff the hard way. Without any further equivocating, let me tell you the kinds of things I think you can do to get these skills.

1. Study design and designers. I’m not saying you have to have the talent to be an awesome graphic designer, but you should pay attention to people who are. When you are surfing the web, pay attention to what works. What looks good? What communicates to you that you can do something on a page? A great example here is this video of Bill Scott’s work on UI patterns. He gives great examples of what the “interesting moments” are in UI design. But in general, you should pay attention to the sites you visit and notice when they get things right and wrong. I often ask interview candidates what sites they admire and why.
2. Study JavaScript. I mean really dig into it. Watch all those awesome Crockford videos – ALL OF THEM! – on the YUI theater. For that matter, watch all the OTHER videos there. Seriously awesome stuff. I don’t agree with 100% of what they all say, but they are educational for sure. Read Crockford’s JavaScript: The Good Parts. Again, I don’t agree with it 100%, but it’s a seriously solid overview of the language.
3. Study JavaScript Frameworks. Note that this is plural. The single most important thing I’ve done in my education with the language was to write the original documentation for MooTools. To do this, I had to read the entire library’s undocumented source and figure out what it was doing and why. I’ve learned a lot since then, but nothing I’ve done has ever resulted in as big a jump in my knowledge. When I wrote jqueryvsmootools.com I did it again, this time with jQuery. I read the entire source so that I could understand it. I did it again with Dojo when I put together a talk about programming to patterns that I first gave in tandem with Dylan Schiemann of the Dojo team (the talk wasn’t about frameworks so much as it is about the value of abstraction, and I wanted to make sure it wasn’t just a MooTools focused talk). I’ve done the same thing with other frameworks to learn the lessons that I can from other people’s development styles. Don’t just use jQuery or YUI or MooTools. You need to study all of them to understand what makes them the same, different, and interesting. Don’t stop until you understand everything that these frameworks are doing and, more importantly, why. Don’t hesitate to ask their authors for explanations; most are happy to talk about their work.
4. Get involved with a framework. The second most important thing I’ve done with JavaScript was getting involved with the MooTools project itself. Working with open source projects is a HUGE boost to your resume and, here’s the thing, you don’t need to really know that much to get started. You just have to be willing to spend the time. Right now, there are dozens of bugs open on every framework out there. Go fix some! Go write test cases! Go write a blog post about how you use it! Do these things and get committer status and I promise you you’ll start getting a ton of interesting job offers.
5. Release some of your own code. I can’t stress this enough. If you don’t have code on github (or google code or your own site or whatever) you’re wasting a big opportunity. Releasing your own code allows me, a potential employer, to know your capabilities before I hire you. This stuff gets people interested in you. If you release a lot of your code, you may even get others to help you maintain and grow it. This is how open source projects get going. I almost consider it a red flag to see a resume without a url to github or something similar.
6. Blog about it. Write down everything you learn as you learn it on your blog. Next thing you know, 3 years have gone by and you have this huge body of work. Stuff on your site draws the attention of other developers who are struggling with similar problems. You become an expert without really meaning to. If you blog constantly about what you are doing, what you are studying, you’ll find that people come to you with work to be done expecting that you are awesome because, well, you’re explaining all this stuff to them. I can’t stress the value of this enough, though it is very time consuming. This is especially valuable if you’re a freelancer.
7. Build something interesting. I once spent a month or two writing a photo gallery in PHP just to have an excuse to learn PHP better. I learned Smarty with that little project, too. I’ve built a lot of things for the excuse to learn it. I built Iminta.com with a friend and we chose Ruby on Rails mostly because neither of us had built anything with it and wanted to learn it. Forcing yourself to do things with new languages and environments will grow your skills faster than anything. Don’t rely on the skills you have; always look for chances, excuses really, to do things in new ways. Working with emerging technologies will make you debug that technology itself and maybe contribute fixes back to it. It can be painful, but it also makes you really learn how that technology works.
8. Join a startup. I know, this one can be tricky, especially if you don’t live in the SF Bay area. But joining a startup will make you tackle problems that aren’t in your domain because, well, there’s no one else to do it. If you’re not experienced enough to be the 2nd or 3rd person at a startup, aim for being the 10th or 20th. You’ll be asking for long hours and low pay, but you’ll get a mountain of experience. Think of it as an extended college education that pays you a little cash and (if the stock takes off) might buy you a house.
9. Take the time to learn why solutions work. When you’re working on something and you get an error and find the solution on Google, take the time to really understand what the problem was. When you are starting up an app server – ruby on rails, django, lamp, whatever – and you get a stack trace, take the time to dig into it and understand the problem and what the logs are telling you. Debugging stuff on the command line will teach you a ton. It’s slow, thankless work, but it’ll greatly improve your value when you take on more challenging tasks at new jobs.
10. Be curious, and fight off laziness. This is a bit of a weird one, I know. What I mean by it is that you should look at tasks that require you to do new things as opportunities. Recognize when these moments come along and cherish them. There is nothing more awesome than having a job that pays you to learn. If you have coworkers that know things that you don’t, and vice versa, trade them. When I was in college I told the guy who was building the web site for my school that I’d help him design it and show him how to use Photoshop if he would teach me HTML. I joined Cloudera 18 months ago and knew zero Python and now I’m pretty decent at it. If you have a job that uses technologies you don’t know, don’t just stay in your little JavaScript world; find ways to expand your knowledge however you can.

I could probably go on about this stuff for a while longer, but I’ll stop. What it really boils down to is that you have to want to be a front end developer and pursue it the way a concert violinist pursues the first chair. There are hours and hours of practice for which no one will pay you. But eventually you’ll find yourself in a position where someone will pay you to do what you love and you’ll find it hard to believe how you got there. Next thing you know, you’re the person designing the user experience at some hot startup and trying to hire new people to join you.

My last suggestion to you, if you’re a budding JavaScript badass, is to force yourself to find a job that will help you learn these skills. Don’t just take a job making some company’s corporate website. There are tons of jobs out there that need front end talent that are building interesting things.

Did I mention Cloudera is hiring?

So, I’ve been trying to hire another JavaScript developer at Cloudera for a while now and the effort has proved to be rather daunting. Finding really good JavaScript developers who know their stuff is hard! If anything, it’s driven a very simple point home to me: it is a good time to be a JavaScript badass. In the past few months, when I’ve found talented JS developers and tried to recruit them, it’s clear that they have as many doors open in front of them as they want. If anything, they’re bombarded with requests from recruiters and companies trying to recruit them. As a person trying to hire these people, I find myself competing in a way that reminds me of the first dot-com boom. I offered one candidate a 1967 Cadillac Eldorado and still didn’t close the deal (I wasn’t serious of course, but I did offer them a lot, including the car, but the candidate new I wasn’t serious about that one. He countered by demanding something a little more high-profile). In the end he took a job at another startup.

The thing is, being a JavaScript badass isn’t only about knowing JavaScript. If you want to be a solid front end developer, you need to be able to do a lot of things really well, most of which aren’t really in the job description or, at least, don’t appear to be as important as just knowing JavaScript. Some of them just require competency, while others really require mastery (JavaScript does, obviously, if you want to qualify as a certified badass). In general, I’m a relatively humble person. I have my own blog, which I guess says something about the size of my ego, but I’m not that full of myself, I swear. But consider the fact that when I was recently talking to a recruiter about the position, I described what we were looking for, the skills and the kind of person, and the recruiter told me flat out, “Those people don’t exist; you’re describing a unicorn.” I told the guy I was describing the job that I do every day. He was unyielding, “Well then consider yourself mythical in nature.”

So what does it take to be a JavaScript badass, and what do you get for it? Well, to be a really top-notch front end developer means you’re going to have to spend a lot of time doing stuff that’s tedious and boring, some stuff that’s really hard and beyond your talents, and some stuff that’s just plain fun. For what it’s worth, here’s my list:

1. You need to know HTML. You need to know everything about it. Everything. You need to know what effect document types are going to have on your markup’s display. You need to know that browsers will shove a TBODY tag into your tables even if you don’t code one. You need to watch what the browser vendors are adding into their nightly builds and their upcoming specs. Learning this stuff, at least for me, just takes loads of time discovering it as you work.
2. You need to know CSS so well you’ll regret it. These days most of the cross-browser problems I encounter are with their CSS implementations. Getting around them usually means describing the exact same style in a different way. You just added a negative margin-top to a link and guess what, the users of certain browsers can no longer click them, despite the fact that you gave it a z-index of a million and you can clearly see the damn thing. Or you just made the most amazing collection of positioning statements to make an auto-resizing masterpiece of CSS awesomeness but god help you if your boss looks at it in Internet Explorer. The thing is, having this skill – being good at CSS – isn’t really all that interesting or valuable any more. Everyone who works on the front end is just expected to have it. There are some seriously talented CSS developers out there who go far above and beyond this kind of knowledge and truly make CSS into an artform. You don’t have to be one of them, but if you can’t make the page look like the mockup, it doesn’t matter that you can do just about anything else.
3. You need to know the browsers. You need to know that IE won’t let you convert this string: “<meta></meta>” into DOM elements by setting the innerHTML of a DIV. And forget about injecting it in the HEAD to turn it into a DOM element, because that thing is read only. You need to know that IE will always barf at trailing commas in your array and object literals. You need to know that IE has offset positioning issues for elements inside of iframes. And IE isn’t the only pain in the ass; Firefox has those clearfix issues with floated elements and webkit’s no saint. And you need to know that the latest versions of webkit have whatever awesome new features it has, as well as what ways mobile safari differs from the desktop version.
4. Did I mention JavaScript? You need to know how ALL of JavaScript works. You need to know that the arguments object in a function has a length property and is iterable, but it isn’t an array and has no methods. Further, you need to know how to turn it into one. You need to know how the prototype property works, how to use it on your own without the help of a framework, and what the implications of using it are. You need to know how to garbage collect things and, for that matter, how to tell when you aren’t. You need to be really good at abstraction. Seriously brilliant at it. You need to be good at designing APIs for yourself as well as others. You need to know how to test your code and how to manage it.
5. You need to be decent at design – information flow, graphic design, user experience design, code design. You need to be able to interview a user, a client, a stranger, an expert, whatever, and ask them the right questions to be able to devise an experience that solves their problems. Not just the ones you can imagine, but the ones they don’t know how to describe. You need to be able to open Illustrator and put together wireframes quickly to devise a plan, then switch to Photoshop – god you need to be good (that is, efficient) at Photoshop – and put together the visual style. You don’t have to be the worlds best designer; I’m certainly not. But you need to be able to tell the difference between good design, bad design, and amazing design. If you can manage good on your own, you’re set.
6. You need to be comfortable on the server side. There aren’t that many positions out there where all you write is JavaScript all day long. Most front end jobs will see you writing as much as half of your code in JavaScript, but you need to be able to pick up other languages relatively quickly (in, say, a month or less). Python, Ruby, Java, PHP… If you only know one programming language, it doesn’t count. If you only know JavaScript and PHP, and you balk at any task that requires you to use something other than those two (rather than, say, looking at it as an opportunity to learn something new), then you need to ask yourself what you’re doing here. Knowing how to use a framework, but not how to accomplish something without one – with vanilla JavaScript – doesn’t count as knowing JavaScript.
7. And then there’s about a million other things that you need. You need to understand Git. Git is amazing. I know you’ve heard people tell you this, and if it still seems like an alien monster that refuses to explain itself, then you need to hunker down and figure it out. You need to understand how to get things done with just a shell. You should be able to open up vi or emacs and edit a conf file without launching notepad or TextMate or whatever. You should be able to run make and compile things. You should be able to tail a log file, unzip a tarball, secure copy things, run servers and configure them. You need to be able to kill processes and read a stack trace.

I’m not even counting stuff like being familiar with Agile development processes, working with open source communities, or releasing code. But if you feel like out of the seven things I listed above that you nail 5 of them and would get passing grades at all 7, then congrats. You’re a unicorn.

And what do you get for being one? How can all these things possibly be worth the years of tedium, of debugging crap in IE6 and worse (yes, there is worse), possibly be worth it? Well, you’ll get recruiter emails and calls every week (this isn’t so awesome, actually; they’re like sales people who pretend they know you). When you want to look for a new job you won’t even need to do much – just tell a few people or post it on twitter – and you’ll have half a dozen doors open to you. You’ll have friends that are starting new ventures calling you, begging you to join up. You’ll get in on that ground floor you’ve been hearing about. You’ll get good stock options and you’ll get to design products from the ground up. You’ll get a 1967 Cadillac Eldorado as a signing bonus (not really). That guy I offered that car to (not really) took a job at a startup and he’s the guy. He’s THE front end developer for their product which doesn’t exist yet. He gets to point to that thing, a year or two from now when it’s worth a bazillion dollars (I do wish him luck, after all) and say, “I did that.” There are people out there, right now, who get to point at Twitter, Facebook, Gmail and Google Maps, at the Iphone’s UI, at Github, at the YouTube player – stuff used by millions upon millions of people – and say, “I did that.”

That could be you.

Did I mention Cloudera is hiring?

A few years ago I wrote a post after visiting the Ajax Experience about Programming to Patterns. The JSConf team was nice enough to bring me out to DC to give a talk, which you can watch below, and you can get the slides in PDF or Keynote format here.

I know, it’s been too long. What can I say? I’ve been busy. Really, really busy.

A few weeks ago Cloudera announced our latest release of our Hadoop Distribution and the open sourcing of numerous projects that are part of that distribution. If you’re reading my blog because you care about JavaScript and stuff, this won’t be terribly interesting to you (if you’re into distributed computing though, that’s another story). What will interest you is that one of the things we open sourced is Cloudera Desktop, which is now the Hadoop User Experience (aka “HUE”).

Why is this interesting to you? Well, HUE is the thing I’ve been working on for over a year now at Cloudera and I can tell you that the JavaScript foo inside it is some of the most interesting stuff I’ve ever written. Here’s a little preview:

• JFrame: Essentially a JavaScript implementation of an IFrame. You assign a url to a DIV and now all links, forms, etc. load in that DIV. Click a link, the div updates. It powers the Ajax windows on the Desktop UI and allows us to build plain old vanilla web applications and load them into windows in the browser and they all act like their own little browsers. Because they aren’t really IFrames, you don’t have all that history session clutter, you don’t need to load all your JS and CSS for every one of them, and they can easily communicate with each other, allowing applications to spawn other apps and continue talking to them.
• Behavior: Anyone remember Behavor.js from 2005? Well, this script is a bit of a nod in the direction of that early JavaScript tool. What it does is turn vanilla HTML with some declarative mark-up into interactive, slick looking UI goodies. For example, there’s a Behavior Filter for forms that make them submit via Ajax – the filter just finds any form tag with an HTML5 data attribute that looks like <form … data-filters=”Form.Request”>… and configures an instance of Form.Request for it. Same thing for sortable tables, input hint text, and other UI widgets.
• MooTools ART: HUE makes a liberal use of MooTools ART for windowing, nice looking buttons and inputs, icons and more. There’s still a lot of CSS stuff going on of course, but HUE looks as good as it does in large part due to ART. The code is pretty stable. You can download and play with the ART Widgets to see how it works. Before we can release all this stuff though we need to document it all and so it’ll likely be a while longer before there’s an official download on MooTools.net.

There are some more detailed posts about HUE on Cloudera’s blog, one that gives a nice overview of what it does and one that I posted today that gives an overview of how to develop your own applications on it.

It’s worth noting that HUE, as it is right now, is focused on supporting application development for the Hadoop ecosystem, but there’s nothing stopping it from being used for something else. The Desktop system itself doesn’t depend on Hadoop. If I had the time to make it stand alone I’d call it the MooTools Desktop. If you find yourself wishing you had such a thing, don’t hesitate to fork the code and work on it or to hop on the HUE Developer Google Group to ask questions or make suggestions.

Now that most of my work is open source I hope that in the coming weeks and months I’ll be able to post more often. When ART is released I’ll probably write about how to use it more. Right now the Behavior framework is part of the ART-Widgets repository but maybe I’ll release that sooner if enough of you are interested in it…

I know, it’s been a while. A long while. What have I been up to? Oh, a little bit of this and a little bit of that and maybe a pinch of this.

And speaking of what I’ve been up to, I’ve mostly been focused on my job at Cloudera, which is teh awesomes. How awesome? Well, I work in an awesome space with awesome people on awesome projects.

…and we want you. Were looking for someone to help us build a lot of cool things, and the job involves a lot of JavaScript. We push code into various MooTools projects daily. It’s all built on MooTools ART, ART Widgets, MooTools More, and of course Clientcide’s JS, as well as other such goodies. You’ll be hacking with the cutting edge of MooTools and pushing your work back into the community.

Here’s our sales pitch:

There’s more to UI development than writing a bunch of HTML, CSS, and JavaScript. You know what we mean; it takes design sensibilities to do it well. It’s the kind of thing you know when you see it – when things work smoothly and intuitively. Cloudera (recently voted as the #1 startup by VC Journal – http://cl.ly/fb5cc4338f0d07fc5539 ) is looking for someone with those kinds of sensibilities to help us build Cloudera Desktop – a virtual web-OS style application suite for managing large Hadoop data clusters. We want to make working with a virtual cloud of computers as slick as OSX or Ubuntu and to do it we’re writing some cutting edge JavaScript, but the people writing it need to have some design sense, too. If you enjoy spending time in Photoshop and Illustrator as much as you enjoy writing closures and recursive functions, then you’ve found the right job.

Required Skills:

• 3+ years of experience in developing web UI applications.
• Solid grasp of cross-browser, object-oriented JavaScript (closures, inheritance, etc)
• Significant experience in developing AJAX-enabled web applications
• Experience in coding standards-compliant semantic markup in XHTML/CSS
• Knowledge of and a preference for JavaScript frameworks such as MooTools, jQuery, YUI, Prototype, Dojo, etc.
• A passion for writing super optimized and clean code
• Some experience designing user experiences; a working knowledge of Photoshop and Illustrator

Strong Plus:

• Experience with data and information visualization is a strong plus
• Experience building web applications in Django/Python
• Experience developing desktop applications UI (e.g. with Adobe Air)

Involvement in an open source project (examples: committing code, writing plugins, involvement in user forums) preferably one focused on JavaScript

If you’re interested, ping me and send me your resume.

I’ve written a lot about MooTools over the last several years, the mootorial, my own book, not to mention all the posts here and loads of documentation. So you might think that I’d look at another MooTools book on the market as competition but you’d be wrong. I love that there are other people out there who want to help others learn MooTools. Writing tutorials and books is just as valuable to the framework’s growth as writing code. In the last year there have been a lot of new materials on that front now that I think about it. Ryan Florence has dedicated his blog to the topic. Mark Obcena has written a whole series called “Up the Moo Herd” that covers a lot of tips and tricks and best practices. Not to mention all the great work David Walsh continues to do (for instance, his recent post on NetTuts – “Make your MooTools Code Shorter, Faster, and Stronger” - was terrific).

So yeah, another MooTools Book? AWESOME. Read the rest of this entry »

At the beginning of 2009, MooTools was a single thing – one library maintained by maybe 5 or 6 people who actively pushed code into it. It’s hard to reconcile this with where it is now. Let’s see, first, MooTools was split into two in February – MooTools Core and MooTools More. The principal developer, Valerio Proietti (the creator of MooTools) focused most of his energy on MooTools Core with the help of several other developers, and I’ve focused most of my efforts on MooTools More, the official plugins for the library. While Valerio and others continue to refine the core, the -more team has brought the number of plugins for MooTools from around a dozen to nearly sixty.

Part of what changed was our active recruitment for people to be involved in our development community. Our developer mailing list went from about a dozen people on the mailing list with 4-6 people actively pushing code into MooTools to around 50 developers on our mailing list with somewhere around 15-20 people actively pushing code. These numbers tell part of the story; of tremendous growth – as much as 400-500%.

At the same time, there have been a lot of new things happening that may be slightly off your radar. For instance, a MooTools user named Piotr Zalewa showed up one day out of nowhere with a paste-bin app for MooTools that lets you create stand alone working code examples with HTML, CSS, and JavaScript which he launched at http://mooshell.net. Immediately upon joining the developer list he started adding features and working with others on the list to make it better and better and the result has been phenomenal. The usefulness of our user mailing list has gone up dramatically as users show up asking questions with working examples (or, more often, broken ones that they need help with). Other users can edit the shell and save a new version, responding with a link that shows exactly how to solve the problem. Daily we see how MooShell has affected our ability to help our users and we’re happy that MooShell is now an official MooTools project. Expect to see these working demos in our documentation early this year (to a demo of this in action just scroll down to the “Demo” section here).

There are a number of other new additions to the library that are still somewhere between pre-alpha up to beta states. There’s the Depender application that lets you build libraries on the fly. MooTools ART, a canvas adapter for MooTools, continues to come along. Slick, MooTools’ new selector engine is in testing phase and we hope to see it released early in 2010. We just released the MooTools 1.1 to 1.2 Upgrade Helper which should help those still using 1.1 to adopt the current release. MooTools 2.0 is still under heavy development, but we’ll be releasing MooTools 1.3 early this year with some new features. Even stuff that we don’t release, like a new search engine for mootools.net.

And then there’s the MooTools Forge, our new user-created plugin catalog. The Forge alone would be enough for me to call 2009 a big year for MooTools. It is absolutely what MooTools was really missing. Developer Guillermo Rauch cranked out a slick bit of technology that closely integrates with Github and makes it easy for developers to update and maintain their plugins. In only a month or so there already 100 plugins in there with more added daily.

All of these things, this proliferation of output and creativity, stem from one small change that happened early in the year. Something that in many ways no one outside our developer community would know about or even have noticed: MooTools went from being the work and property of one person to being a project owned by its community. For the roughly two years previous to 2009 that MooTools was around, it was developed almost entirely by Valerio. It’s true that other people, such as myself, contributed to the work with Valerio as the gatekeeper. The MooTools code has always been elegant and easy on the eyes to actually look at, and this grooming was a product of that single guardian who cared deeply that the code always be as clean and elegant as possible. It was uncommon for anyone to make a commit to the project without Valerio coming through and tidying it up, always making it just a little better and in the process teaching us how to be better developers.

In February of 2009, the first little step happened with the split of MooTools Core and MooTools More. The code in -more is still methodically groomed and maintained, but not by Valerio. The -more team does this service for each other, each checking over the others’ work and making it a little better, a little leaner. As we actively recruited people into the developer list, we had more and more people working on different things. Selector engines, paste-bin applications, plugin libraries, canvas adapters, a search engine for mootools.net, test frameworks, and more; it all became far too much for one individual, even two or three, to be the gatekeepers.

At my job at Cloudera, I have the privilege of working with Doug Cutting, who brought Lucene, Nutch, and Hadoop out through the Apache Foundation. Doug spent a bit of time with us talking about how Apache develops open source software and after a few weeks of work we produced a founding document for how MooTools projects will be developed and governed. This document, our “charter” is influenced heavily on Apache’s processes, though not as rigid as we don’t have their scale issues (yet!), but it’s had a remarkable influence on our development team. All the things I’ve listed in this lengthy post have sprung up as a result of this change. What started as a split (-core, to –more and -core) has now grown into a federation of projects that we govern as a group. And that federation of projects, that freedom to just make things happen, is now filtering out into our community with the Forge.

So when I look back on 2009 and ask myself what MooTools accomplished, I look at all the things we released, all the code we wrote, and all the new people contributing and think of those things as side effects. The thing that really happened in 2009, and it took all year to do it, was MooTools became a project owned by all of us. Valerio is still guiding it, but we’re no longer rate limited by his ability to pay attention to all we can create. And so projects move forward with their own teams, and plugins get released by enterprising individuals on the Forge, and users send us bug reports using MooShell to demonstrate the problem. All these things are spectacular. But what really happened was that (tiny at first) shift to belonging to everyone who contributes.

When I consider 2010, my mind is awash. In one year our team grew by several hundred percent and the number of projects being actively worked on did the same. Our community has better tools to share their work. 2010 is going to be less about MooTools itself and far more about what we, as a community, make with it. If 2009 was all about the MooTools developer community coming together and taking things to the next level, 2010 is going to be about our community of users, and the possibilities there are endless as far as I can tell.

So consider this a challenge, an open invitation. Surprise me.

Several weeks ago I had the pleasure of addressing a large crowd of Joomla developers at their conference in New York. The Joomla community is a fantastic bunch and the time I spent there talking about MooTools was perhaps some of the best I’ve had. The people present were very interested in MooTools and as well they should be. Joomla ships with MooTools built in and there is a large community of Joomla plugin developers who end up using MooTools because of it. Unfortunately, it still ships with 1.1.

A few months ago we, the MooTools team, decided to start focusing more on helping the Joomla community with their upgrade woes and began to re-address the compatibility code for 1.1 to 1.2 in earnest. When I spoke in New York to the Joomla team there and said that our goal was to have something to help them upgrade available by the end of the year, there was, dare I say, rawkus applause.

Well, here it is, Dec 31, and I’ve kept my promise. With the help of many of the MooTools Dev team (Chris Pojer, Darren Waddell, Nathan White, and others) we’ve finally got a compatibility layer that actually works and, more importantly, helpes you upgrade.

First, it logs warnings to the console (such as Firebug) and helps you find the places in your code that need updating. The script is not a compatibility layer as much as it is an upgrade helper. Hopefully this will help us retire 1.1 for good.

Secondly, easily half of the work, if not more, was spent creating a test environment for it. When MooTools 1.1 came out, we didn’t have a test framework to run against the code. When we released MooTools 1.2, we did, and it shipped with tests for most of the functionality included. So to make this compatibility layer, we had to go write tests for all of 1.1 (about 400 individual tests), then write the upgrade helper, compatibility code, and then run the tests from 1.1 against the 1.2 code base with the upgrade helper loaded. Creating the tests for a deprecated code base is no fun but I’m glad we did, otherwise the compatibility code would be in far worse shape.

But as a result of all that work by the MooTools Dev team, I can say that the helper script we released today is likely to cover about 95% of all the changes between 1.1 and 1.2; the other 5% being essentially un-hackable. Still, for most developers, it should cover all their work.

Seeing 2010 roll in with people dropping 1.1 is a great way to start it. If you’re still running 1.1, now is the time to move on.

You can find out more about the upgrade helper on the MooTools Blog.

For those of you who didn’t notice, MooTools released it’s long vaunted user generated plugin system today – The MooTools Forge [accompanying blog post].

First, this is just awesome news, and a big tip-o-the-hat to Guillermo Rauch, who wrote the app. For those of you who have been around our community for the last three years, the forge was always something we were “working on”. There have been many versions created over the last few years, and many other community created initiatives, that didn’t quite do what we wanted. Guillermo jumped in and built a great system, closely integrated with git, that, well, it kicks ass.

The Clientcide Libs

I’ve uploaded four plugins to the forge as part of the launch (Tabswapper, MenuSlider, HoverGroup, and dbug). I chose these because they were just the simplest plugins that I could release; they just don’t depend on much and they do one thing. Releasing Stickywin, for example, represents a much greater challenge.

One of the things the forge requires is individual git repositories for each plugin. This means that I have to split up my one big repo into lots of little ones, rewriting my download builder, docs engine, and other tools to make these things easy to manage. Consequently, moving things into the forge is likely to be a long and laborious task. For the moment, the four plugins I’ve released are just duplicate files of what’s in the single Clientcide repo, but eventually, once I’ve split them all up, I’ll remove all the files from the Clientcide repo and then include them all as submodules. For the time being, they will be duplicates, and releasing them will happen as I have time (which is not very much these days).

Good Times

I’m really excited about MooTools here at the end of 2009. I hope to make a longer post here looking back at all we’ve done this year, but certainly the Forge release will be a big highlight. 2010 has a lot of interesting things coming, I’m sure, but perhaps the thing I’m excited most to see is all the good things that the MooTools community creates and uploads to the Forge.

2009 has been a very busy year for MooTools and I’ve spent much of my time working on things other than Clientcide (like MooTools and Cloudera Desktop). MooTools More continues to grow – the latest releases (1.2.4.1 and 1.2.4.2) are full of all sorts of new features (over 50 plugins if you exclude all the date localization files), but you’ll probably recognize some old friends. Mask looks a lot like Modalizer, Spinner like Waiter, Form.Request like Fupdate, etc. That’s because in an effort to make MooTools more feature rich I and the other MooTools developers have been moving our work into the official project.

As such, Clientcide 2.2.0 is really a bug fix and compatibility release. There are very few new features but that’s because, in a way, all the new features are in MooTools More.

Here’s what’s new in 2.2.0:

• Modalizer is deprecated in favor of Mask
  • compat file is just the deprecated library; does not convert to Mask instances but rather just returns Modalizer as it always did
• StickyWin.Modal has new options for Mask; this is a breaking change
• Removed Element.Delegation (now in MooTools More; unchanged)
• Deprecated DollarE
• Deprecated DollarG
• Fupdate is now Form.Request in MooTools More; see compat files
  • Fupdate.Prompt is now Form.Request.Prompt
  • Fupdate.Append.Prompt is now Form.Request.Append.Prompt
  • Fupdate.AjaxPrompt is now Form.Request.AjaxPrompt
  • Fupdate.Append.AjaxPrompt are now Form.Request.Append.AjaxPrompt
• FormValidator got renamed in MooTools More to Form.Validator (the old name is preserved); updated FormValidator.Tips to Form.Validator.Tips (again, the old name still works).
• Collapsable is now Collapsible (that’s correct, I cannot spell). The old name is preserved (though the file name itself changed; update your build scripts).
• HtmlTable moved to MooTools More. No breaking changes, but the -more version has new features.
• Added Italian, Spanish translations for Simple Editor
• New StickyWin features
  • Z-index Ordering!
  • changing default value for allowMultipleByClass in StickyWin to true
  • Added setCaption method to StickyWin.UI
  • onUpdate event for StickyWin.Ajax
• added detach method to MooScroller
• dbug should now work in IE8
• offset options are now additive for pointy tip
• numerous bug fixes

For the most part compatibility is preserved. There’s that one breaking change in StickyWin.Modal where the options for the modal layer are different. I can only test this so much, so if you find areas where the compat files don’t provide coverages, please file a ticket.

I’ve also updated the download builder on Clientcide to use the now open source builder called MooTools Depender. Check out the blog post on MooTools.net if you want to know more about it. One cool thing about that you might find useful it is the ability to re-download a script you created with a given url. Now, when you download a script, the header includes a url to re-download the library with the same selections. This should make upgrading libraries a little easier.