Grunt Brings Automation to the Front-end Side
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:
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!
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.
Here comes grunt
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.
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.
: 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. ;)