Grunt – a build system for front-end professionals

Alastair Aitken 28 July 2014 0

In most programming language eco-systems, a comprehensive build system is taken for granted. Some are more convoluted than others: Java developers have long had to wrestle with the visual spaghetti of XML in order to create build files for use by Ant or Maven. XML certainly wasn’t designed to be a programming language; trying to shoehorn flow logic into it is as impressive as it is daft. Hopefully Gradle is the answer to save Java build teams from XML hell.

Perhaps because of its humble beginnings – embedded in HTML pages with little practical functionality – or maybe because it’s The World’s Most Misunderstood Programming Language, JavaScript didn’t really start to require a build system until the advent of single-page applications in the browser. Where once the insertion of a few functions into a page would suffice, there was now a need for serious, nay professional, development tools.


The arrival and widespread adoption of Node.js has allowed for the creation of a native option for building JavaScript. Node-based Grunt has risen to become the de facto choice for building JavaScript projects even though it has yet to reach version 1.0. Grunt isn’t the only player on the park though, Gulp addresses similar requirements.

In building a JavaScript project there’s a stack of things that Grunt will take care of automatically such as:

* validating files with lint utilities, such as JSHint and CSS Lint,

* concatenating files together to reduce pipelining,

* minifying files to save on bandwidth,

* compiling files written in another language such as CoffeeScript and Sass,

* running tests using frameworks such as QUnit or Jasmine, and

* watching for changes in files (I use my iPad as a separate monitor using the DisplayPad iPad app to display changes near-instantaneously without having to hit cmd (or alt) plus tab).

Grunt has a built in development server which does away with having to fiddle around with virtual hosts and hosts files on a full-blown web server before getting started on the meat of a project.

Building is controlled by a Grunt file which allows for fine-grained control over the various components that Grunt can call.


If Grunt doesn’t satisfy out-of-the-box, there’s a robust  plugin system with over 3000 plugins to handle pretty much any development, test or deployment task. All the features listed above can be swapped in and out by installing and calling different plugins.

Barriers to acceptance

Given that Grunt is so handy, what are the barriers that any development shop is likely to face? Well, without wishing to tarnish some people with the same brush, I’ve found that front-end developers and designers have a harder time getting used to the idea of automated build systems. Particularly if it involves using the command-line, as Grunt does. There’s also a requirement for installing Node.js and, as it’s not yet at version 1.0, keeping it up-to-date using Node Version Manager (nvm).

Another hurdle to acceptance is finding decent documentation. With a system that is in a state of flux, available documentation is oftentimes out-of-date. Pragmatic Programmers has recently released Automate with Grunt which gives great step-by-step instructions ranging from installation through to developing a custom plugin.

If these reasons don’t convince you to use Grunt then the rather awesome Grunt logo really should swing it for you.

Alastair Aitken (124 Posts)

As a contract developer and manager I’ve worked in a wide range of enterprises in a variety of countries where I’ve encountered everything from great work, awful work, bizarre work, all the way down to quasi-legal work. If you think that you recognise your own organisation within my articles then you’re undoubtedly wrong, where you work isn’t that unique.

Leave A Response »