Part 1: Why Do We Need Task Runners?
In Part 1 of this 2-part series, I’ll overview the evolution of front-end web development and discuss how Task Runners like Grunt and Gulp can help streamline your web development workflow. In Part 2 of the series, I will walk through installation, discuss configuration files, compare Grunt & Gulp, and point out the pros and cons of each tool. I will also do some real world performance testing to see if either outpaces the other.
It was the best of times it was the worst of times…
This is especially true in enterprise environments, where desktop developers are tasked with creating web apps as if they were the same thing. Server-side frameworks like ASP.NET, JSF, and Google Web Toolkit all try to minimize the coder’s need to understand client-side development. So while many of these programmers were saying how easy it is to write HTML, they were still clinging to their safe object-oriented programming worlds by letting Java and .NET render the client-side code for them.
This mindset has become problematic over time as the backend code has become more unwieldy than the corresponding client code it was insulating us from and developers are spending more and more time tweaking the rendered code and thus forced to learn the front-end stuff anyway.
|“We were building something in GWT and was getting really frustrated just how unproductive I was being.”
Miško Hevery – Creator of AngularJS 
So what else happened that has allowed front-end development to become a first class citizen in the world of application development? Well of course browsers have gotten much less idiosyncratic, aka Internet Explorer is starting to play nice with others and following the specifications.
HTML has moved past the stagnant years of waiting for XHTML to replace it and has again started to evolve and improve with the WHATWG’s (Web Hypertext Application Technology Working Group) guidance and eventual W3C approval. These improvements, which we all tend to refer as HMTL5 , have allowed us to move away from plugin-based technologies like Flash and QuickTime and develop directly for the web browser.
Frameworks such as Bootstrap, Foundation, and Django help with mobile first, responsive design plus they provide easy to implement UI widgets. Template systems based on Mustache and Handlebars make reuse of HTML markup easy without the need for server processing.
And finally we have full blown application frameworks like Angular, Ember, and Backbone that allow MVW  development directly in the browser. Plus there are literally thousands of other patterns, libraries, toolkits and frameworks that have fueled the exodus from the server to the client. The best of times…
So with all of this innovation on the front-end, where are the current pain points for the client-side developer? The learning curve, of course, is a huge obstacle to becoming the web development ninja that you aspire to be.
Keeping up with what all of these shiny new toys do, let alone being skilled enough to design and develop polished applications using them, is a huge barrier to entry. Even if we have the luxury of being able to focus on a few specific technologies for a project, there is always that nagging feeling there might be a better way of doing it just around the corner.
But once the deer in the headlights feeling passes and we get more comfortable with what’s important to our project environment, there is the need to optimize our workflow and the constant tedious tasks that go along with web application development. For backend and desktop developers there are amazing IDEs that allow the code to be entered with intellisense and autocomplete ease, compiling and executing at the click of a button, debugging with the help of breakpoints and watches, and simple push deployments.
But their front-end brethren are still using a mishmash of text editors like Sublime Text and Vim, command line compiling, browser-based debugging tools, and manual deployment methods. Venerable web development environments such as Dreamweaver have not kept up well with the trends in the industry, which Adobe’s support for the open source Brackets development tool seems to indicate . Even the powerful Eclipse and Visual Studio IDEs struggle to keep up with these constant changes and tend to suffer from trying to do too much  . The worst of times…
Task Runners to the Rescue!
That’s not to say there is no light at the end of this tunnel. There are some very promising IDEs for web developers out there, JetBrain’s WebStorm and ActiveState’s Komodo come to mind; awesome code playgrounds for playing and testing such as CodePen, JSFiddle and LiveWeave; GitHub and BitBucket  offer version control software that can be social too, and even cloud based code editors that are gaining in power and popularity. With web development, hope springs eternal. So with no further ado, let’s introduce the stars of this series: Grunt and Gulp!
|“Instead of being a chore, creating a new project and performing repetitive but necessary tasks such as linting, unit testing, concatenating and minifying files become trivially easy.”
Ben Alman – Creator of Grunt 
How to start using a Task Runner
Node.js comes with a package manager that allows applications to be installed and updated called npm  . We use npm to install Grunt and Gulp. We will cover the exact syntax for installing our task runners in Part 2 of the article.
Once they have been installed, we then need to configure them. Both Grunt and Gulp rely heavily on configuration files to know what they are going to do and when to do it. These configuration files are the main interaction point for the developer and the task runner. We write these files early on in the project lifecycle, and then we let the task runner do the “grunt” work. Getting comfortable writing these config files accounts for most of the learning curve for task runners.
Another important concept that Grunt and Gulp share is their ability to handle change. Both task runners use plugins to deal with different tasks. This is an important concept because the web development world is still evolving at warp speed. Plugins allow tools to easily deal with this change, the next new library or framework that needs workflow automation can have a plugin written for either task runner. The use of plugins of course is not limited to Grunt and Gulp; most of our front-end development tools use them to keep up with the industry.
That’s it. Install them, write the config files, download the plugins you need, and start enjoying the benefits of your new best friend the task runner!
Next up, Part 2 of the series: Grunt vs Gulp in the Ultimate Task Runner Cage Match…
In Part 2, we will go through the commands and syntax to install and configure each task runner. We will also dive into the differences between them and compare the merits of each tool. Finally we will do some quick and dirty performance checks to see how they stack up against each other.
 The WHATWG considers HTML to be a Living Standard, and so should not have version numbers. They feel it’s up to the browser makers to decide what features they implement not the specification writers.
 Model-View-Whatever, you call it Controller, they call it Presenter, and I call it ModelView, so whatever…
 Bocoup – Introducing Grunt
 express – fast, unopinionated, minimalist, web framework.
 bower is another popular package manager to help developers keep up with all of the libraries they use.
Written by Jeff McBride <email@example.com>, coder / trainer by day, designer wanna be by night…
Accelebrate can offer courses for all the stuff mentioned in this article, just ask!