US & Canada: 877 849 1850
International: +1 678 648 3113

Accelebrate Blog

ACCELERATED LEARNING, CELEBRATED RESULTS

A Tale of Two Task Runners – Grunt and Gulp

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…

That’s pretty much all I remember from A Tale of Two Cities, but this intro does apply incredibly well to the times Front-end Web Developers are working in today. After years of trying to hide, wrap, abstract, and just generally avoid dealing with HTML, CSS, and JavaScript, we have finally moved into an era of not only acceptance, but also actual enthusiastic embrace of those wonderfully nuanced technologies.

Web Developer Role

 

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.

Web Designers vs Web Developers

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.

QUOTE

 

“We were building something in GWT and was getting really frustrated just how unproductive I was being.”
Miško Hevery – Creator of AngularJS [1]

 

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.

HTML5 Test

 

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 [2], have allowed us to move away from plugin-based technologies like Flash and QuickTime and develop directly for the web browser.

Toolkits like jQuery and MooTools have taken the drudgery out of writing JavaScript. CSS has evolved in the form of preprocessors (LESS and Sass for example), which are quasi-programming languages that allow for variables, conditions, loops, and reusable code blocks to minimize the sheer bulk and redundancy that CSS is infamous for.   There are even pre-compilers for JavaScript, like CoffeeScript and TypeScript, which simplify or provide additional language features but compile to plain ol’ JavaScript.

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 [3] 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.

 

Web Developer Ninja

 

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.

 

face_palm

 

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 [4]. 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 [5] [6]. 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 [7] 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!

HTML markup needs to be validated, preprocessor files need to be compiled, JavaScript needs to be linted (a JavaScript code checker that finds common mistakes in scripts), unit tests need to be run, browser pages need to be reloaded, changes need to be committed, and eventually everything needs to be minified and possibly obfuscated prior to deployment. This is where task runners like Grunt and Gulp come in. A task runner does just that, it runs tasks. Tasks like validating, compiling, linting, copying files, dealing with source control, and notifying us of the outcome. They can even refresh the browser for us! Any task that we tediously do over and over is a candidate for task runner automation. Once they are installed and configured, they tend to do their jobs without much intervention. They will dutifully monitor folders watching for changes and automatically run tasks on the modified files. This allows them to integrate easily with any code editors and development tools you are currently using.

QUOTE

 

“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 [8]

 

How to start using a Task Runner

The first step of using any task runner is of course installing it. Both tools are built on node.js [9], which is a platform using Chrome’s JavaScript runtime that hosts applications written in JS. It can be used on developer machines for tools like Less, CoffeeScript, and TypeScript or on a server to host applications using frameworks such as express [10]. So in order to install and use Grunt or Gulp, we must first setup node.js.

Node.js comes with a package manager that allows applications to be installed and updated called npm [11] [12]. 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.

gruntfile.js and gulpfile.js

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.

 

Grunt plugins

 

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.

 


 

Footnotes

[1] JavaScript Jabber – Dependency Injection in JavaScript with Vojta Jína & Misko Hevery.

[2] 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.

[3] Model-View-Whatever, you call it Controller, they call it Presenter, and I call it ModelView, so whatever…

[4] Adobe Edge Code is Now Brackets.

[5] InfoWorld – 10 JavaScript editors and IDEs put to the test.

[6] If you use Visual Studio for any kind of web based development, check out Mads Kristensen’s (@mkristensen) VS Extension Web Essentials.

[7] Links for these tools: JetBrain’s WebStorm, ActiveState’s Komodo, CodePen, JSFiddle, LiveWeave, GitHub, and BitBucket.

[8] Bocoup – Introducing Grunt

[9] node.js – is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications.

[10] express – fast, unopinionated, minimalist, web framework.

[11] Node Package Manager – npm is the package manager for JavaScript.

[12] bower is another popular package manager to help developers keep up with all of the libraries they use.


Written by Jeff McBride <jeff@geeklearn.com>, coder / trainer by day, designer wanna be by night…

Accelebrate can offer courses for all the stuff mentioned in this article, just ask!

 

 

Categories: JavaScript Articles
Tags: , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

Your email address will not be published. Required fields are marked *

*



You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Please contact us for GSA pricing.
Contract #GS-35F-0307T

Please see our complete list of
Microsoft Official Courses