Maybe.
Should you be using a task automator? Probably.
Well, which one? It’s complicated.
There has been a sizable discussion around the advantages of one task automator (or task runner, or build tool, etc) over another, mostly the advantages of gulp.js, the new(er) kid on the block, versus Grunt, the one that started it all.
I could fill a whole series of articles on the differences between the two, and why gulp is better in some circumstances and why Grunt is better in others, but most of that discussion boils down to the fact that gulp is faster, but Grunt can do more stuff. But a question I want to ask here is: “Do we need any of them?”
Obviously there are numerous benefits to task automation. Tedious and inefficient processes are replaced with one or two terminal commands, and all sorts of awesome optimization happens to your project without too much effort on your part. That’s what’s advertised, anyway. The reality of the situation is a bit more nuanced, as is usually the case.
Task Automators: a quick rundown
Most of you are probably well versed in the basic idea behind task automation tools like Grunt and gulp, but for those who don’t, here’s a quick rundown:
Web development consists of lots of little processes that are necessary to the development work flow. These are usually things like checking your JavaScript for errors, minifying all of your code, putting all that minified code in one file, organizing your project file structure, etc. There are tons of great little applications that do some of these things individually, most of them in the form of command line programs. Task automators essentially allow developers to run all of these little programs at once, or at least with only one or two commands, instead of doing each one individually. This cuts down on the tedious and time consuming process that would otherwise be necessary to get an optimized project.
The Task Automator Wars
Grunt was the first of the popular task runners, and it let developers consolidate all of their favorite tools and automate their actions, with the rule for all of that automation held in a configuration file. Developers usually tailor their configuration file for each individual project, but may work off of a configuration file template. It created a very customizable and very convenient way to run all of your necessary tasks, and it became very popular in the web development community.
Not too soon after, gulp.js appeared, promising to fix all of Grunt’s shortcomings, notably its lack of asynchronous processes and “un-codelike” structure. Gulp also improved upon the speed that projects were built, which had been a noticeable side-effect of larger Grunt projects.
Advocates of both systems regularly go back and forth about which is the better of the two, with the “gulpers” citing fast and asynchronous builds, while the “grunters” defend Grunt’s wider plugin pool and larger development community.
Which to choose?
Ultimately, as with many things of this nature, the deciding factor is your preference. As it happens, I use gulp, not for any particular reason other than it’s what a friend was using and introduced me to. Many others I’ve talked to relate similar experiences, so my view is that you should just use whatever works for you.
Which brings up a possible third alternative. Some developers have voiced the idea that neither platform, nor the myriad alternatives is really necessary for most projects that require task automation. Keith Cirkel wrote on his blog about how he achieved perfectly serviceable build automation using only the tools baked into npm, the package manager that comes with node.js. Others have had similar results.
The unlikely alternative
What this indicates is that gulp and Grunt may be overkill for at least some projects, and possibly the majority of them. Using the “scripts” section of package.json, you can create some custom scripts that mirror the functionality most developers look for when using gulp or Grunt. Example:
// package.json
"scripts": {
”start”: “npm run build-js && npm run build-css && serve .”,
“watch”: “npm run watch-js & npm run watch-css & serve .”,
“build-css”: “rework-npm index.css | cleancss -o build/build.css”,
”build-js”: “browserify –extension=.jsx –extension=.js index.js | uglifyjs > build/build.js”,
“watch-js”: “watchify –extension=.jsx –extension=.js index.js -o build/build.js –debug –verbose”,
“watch-css”: “nodemon -e css –ignore build/build.css –exec ‘rework-npm index.css -o build/build.css'”
}
These lines of code in the package.json file run various tools using a simple script, which the developer can execute from the command line (just like they would using gulp or Grunt). This method also only requires a single line per utility, and then a few lines for the developer’s script. That means that this example, which is around 10 lines of code, is roughly equivalent to 50-100 lines of code if you were to have similar functionality using gulp or Grunt.
Final remarks
Regardless of whether npm is a better task runner than gulp or Grunt, the bottom line is that these types of utilities are here to stay. Both gulp and Grunt are extremely popular with web developers, and many of them use one for all of their projects, no matter the size. I know the first thing I do when starting a project is to make sure my basic gulpfile is ready to go with some simple scripts. However, the seemingly apparent simplicity of the npm method is enticing, and I am curious to see if it gains any traction.
Whatever your preferred build tool, using one seems to be a fairly obvious choice when compared with the alternative. Tedium is no developers friend, and I think that there can only be improvements with these task automation tools as time goes on.
I have not yet used this method of task building using npm for any of my own projects, but I think I’ll be trying it out to see how easily it works as an alternative to gulp. Have you tried this? What do you think? Post your experiences or comments down below.