Over the past few weeks, I realized that I added grunt in every little side project I worked on.
Thinking about it, I’m not sure if I can even imagine to start a project without this tool.
You probably already heard about grunt, don’t you? In case you don’t (seriously?), it’s been created by Ben Alman (aka. cowboy).
I guess the best description is the one from the official home page:
Grunt is a task-based command line build tool for JavaScript projects.
OK, looks nice.
But what’s new?
I already have tools to lint or minify my Javascript.
I already use qunit to unit test my code.
And so on… Why should I use grunt instead of all these tools?
Here is why:
- Because you probably don’t really use all these tools.
I mean, for sure you know about them, and you already give them a try; but most people I worked with (including me) just don’t use them on real projects, in their day to day work, because bringing the pieces together is not that easy. - Grunt also uses the exact same tools you already know, or in the worst case, it can learn to use them.
It doesn’t reinvent anything but allows you to organize your workflow in an uniform, yet flexible, way.
Do we need such a tool?
As a front-end developer, automation wasn’t really part of my workflow.
My first job was in some king of web agency were every desktop machine ran on Windows XP, and our main development tools were Dreamweaver MX (I guess I’m getting old…) and Filezilla.
At the time we would never have considered automation, unit testing or continuous integration.
Then I left that company and found a real engineer job.
But still, like many other developers, I relied on some kind of heavy IDE where every low level interaction with the OS tend to be hidden.
And I never really felt a need to dig into this.
Until recently, I was convinced automation was only a concern for back-end or system engineers.
Everything you need is a terminal!
On the other hand, a lot of front-end tools came up recently, especially since Node.js brought Javascript to the Terminal but not only.
Uglify-js, JSLint, Qunit, Jasmine, CoffeeScript, SASS, LESS are only the most famous but there are many others.
These tools are changing our approach to front-end technologies, they make us more productive, adding value to our jobs.
But those tools remains command line tools.
Even if each one of them is pretty simple to setup and use, combining all of these to make something adapted to a particular project can quickly become a nightmare for someone who’s not familiar with his Terminal.
From my experience, a lot of front-end developers, especially younger ones, are not familiar with Bash scripting (and sometimes are afraid of it). For sure, that’s probably a bad approach, but that’s how I felt not that long ago and I’m pretty sure I’m not the only one in that case.
Grails developers write their scripts in Groovy.
Rails developers have Rake files.
We know how to write Javascript! That’s where we are comfortable and productive.
We don’t want to get a headache by writing some messy bash script [1].
Here comes grunt
That’s what grunt does. It allows you to define a bunch of tasks, in a consistent way, by writing Javascript.
Consistent is an important word here because you could probably achieve the same goal directly with Node.js but grunt gives you a simple way to write and organize your tasks.
The most common ones (lint, concat, minify, test, etc.) are already included in the package so you don’t have to think about how to deal with them.
It also came with a really simple plugin system based on npm.
If you find yourself needing to do something not included as a build-in task, try to search npm to see if somebody else has not already released a plugin that fits your needs.
Otherwise, you can still write your own plugin and publish it to npm.
The grunt API allows you to do pretty much everything you could need.
And thanks to the built-in project scaffolding, it only takes a few minutes to change your spaghetti code into a well written plugin. Once here, publishing to npm is just a command line away so do not hesitate.
What’s next?
I hope you will give a try to grunt. Even more because something called Yeoman is getting close to the public release. I asked for a beta invite on twitter but for now, I didn’t have a chance to try it yet.
It seems that it can do many more and as it’s based on grunt, among many others, it’s probably a good idea to get familiar with that one as soon as possible.
[1]: I actually did a lot of bash scripting recently and, believe it or not, I liked it. I wouldn’t have said that a few years ago. It’s a powerful programming tool and every developer should be comfortable with it. You’re not? Learn some basics. ;)