CodeKit and Grunt and Gulp, Oh My!

[comment]Gather ’round children, and I’ll tell you how we did it back in my day. When I was a youngin’, not much older than you are now, we didn’t have any of that fancy CSS. JavaScript neither. PHP? Why, that was just a glimmer in Rasmus’ eye.

What we had was HTML, plain and simple. We had Mosaic, gray backgrounds, and animated construction guy GIFs. And we liked it that way!

Nowadays, we have CSS, Sass and LESS. We have CoffeeScript that compiles to JavaScript, and JavaScript that transforms back into CoffeeScript. We have minified, uglified, compartmentalized, and prioritized. And we have about a dozen different ways to do all of that.[/comment]

There is no denying that CSS was the first great revolution in the front end web world. Without it, think of what the web would look like; most likely, it would have remained limited to its academic origins, where style and design play a much less significant role than the multifaceted, visual web we have today.

In recent years, CSS has undergone a revolution of its very own, as preprocessors such as Sass, LESS, Stylus and others change our methodologies in creating our stylesheets. These tools allow for greater efficiency both in terms of creating the CSS and the final product that’s produced. I was slow to jump on the CSS-preprocessor bandwagon, but I am fully on board these days.

Last summer, I was part of a team that redesigned and relaunched the Norfolk Southern corporate website, a hugely ambitious project that was my first real test of using a CSS preprocessor (Sass and Compass, in this case) in a team environment. I had used LESS and Sass before, but never to this extent. Our tool of choice for the preprocessing was CodeKit, which not only compiled our Sass and Compass, but linted, concatenated and minified our JavaScript. It’s easy-to-use interface took a lot of the voodoo out of Sass, and it’s JavaScript tools were adequate, if not earth-shattering.

But during the course of the project, flaws began to emerge. If it was watching folders when you changed Git branches — especially branches with significant differences — it kind of went berserk. We also had to be extra careful that everybody knew which JavaScript files were being concatenated together, which required coordination between the team members since there was no setting we could just “commit” and have propagated through the team.

Once the NSCorp project was over, we knew we needed a new tool.

So we took up Grunt.js, and I have to say, it took me a little while to grok it. Fortunately, I have very smart friends such as Aaron Jorbin and Brian Watson who were kind enough to help me figure it all out. If you’re strictly a front-end developer, Grunt.js is a bit daunting, and if you’re not ingrained in the world of Node.js, it can be downright intimidating. If you’re just getting started with it, I cannot recommend enough Chris Coyier‘s excellent piece for 24ways, “Grunt for People Who Think Things Like Grunt are Weird and Hard“.

The biggest benefit of Grunt.js over CodeKit is the codification of rules. There is a master control file, Gruntfile.js, that lets you set out everything you want Grunt.js to manage, and even how to handle these tasks differently in different environments. (Think leaving your Sass with full comments and line numbers in development, but minifying the whole thing for production.) If you need to make a change, just edit the Gruntfile, commit it to your version control of choice, and it distributes itself out to your fellow team members.

Grunt is the tool we moved to after the NSCorp project, and I’m currently using it to build a responsive WordPress site for another client (more on that next month).

But wait, haven’t you heard? Grunt.js is dead, long live Gulp!.

I won’t lie and say I know anything about Gulp. From the article above, it’s supposed to be more straightforward and more intuitive to Node.js people. I’m not Node.js people, so I don’t know the implications of that.

But here’s my question for the room: should I abandon my brand-new workflow, after one project, for yet another new system? Is such a model of “use once then ditch for the next new shiny” a realistic way to do our jobs?

Hey, I know that tools change. I know that platforms change. When I started in this business, there was no CSS nor JavaScript. Websites were built to support one of the two competing web browsers, but not the other. No, that situation wasn’t sustainable either, but back then change came more slowly. We didn’t abandon one set of tools just because another one came out the next month. New tools — usually — built upon their predecessors, not replaced them.

Yeah, I’ll probably spend a little time to look into Gulp and see if it offers significantly more than Grunt.js, both in terms of capabilities and in terms of ease of use (because if tools aren’t easy to use, what point is there in using them?).

But I would certainly like it if a tool stuck around long enough for me to master it. Or at least use it for a second project.