In front-end land, it doesn’t take long to feel the cumulative hangover of build lag. I make a change, I want to see it live as fast as possible. If I can make it to the browser and refresh it faster than my build automation can render the changes, it’s officially slow… I’ll double refresh. I’ll assume my changes are wrong. I’ll doubt my changes ever happened. I’ll save them out again, and likely repeat the process.
Reload speed is a familiar bottleneck, en masse it can eat away at your productivity and your patience. Round here, we’ve been running for some time with good ol’ CodeKit, which (aside from the occasional dummy-spit) pretty much does what it says on the tin. It hides itself away, listening for changes and rendering our output on the fly. That’s good, but it’s not great. For larger projects CodeKit becomes a significant bottleneck to productivity, as it huffs and puffs its way through our more involved source trees, adding solid seconds to every refresh.
Testing the water
So we up and decided it might be time to try our hand at Grunt and Gulp, two notable build automation tools that both claimed to outright replace everything we were running through CodeKit. Beyond just replacing the CodeKit toolset, both Gulp and Grunt offer a comparatively deeper set of features through their available plugins (which we’ll cover shortly). It’s also worth noting that Gulp and Grunt are both free to use and operate entirely from the command line… which promotes ease of continuity when you might, say, change workstations, or change people working with your repo.
After the briefest of flings with Grunt, we’re now happily wed to Gulp. Primarily, it all came down to speed: Gulp was significantly faster than Grunt, which itself was an order of magnitude faster than Codekit. Make no mistake, Grunt is still a great tool, but Gulp solved our most significant problem the best of the three – running consistently 8-10 times faster than we had grown used to.
An example setup for SCSS
Whoa there! What follows assumes a basic understanding of node/npm and working from the command line.
So let’s look at a working chunk of tasks in our new gulp setup, specifically for rendering css changes. At the ground floor, the main tasks we want to automate are:
- process my SCSS into CSS (and constantly listen for changes)
- run my CSS through an autoprefixer
- combine my media queries to reduce duplicate declarations
- generate CSS sourcemaps
- live-reload my site with this new CSS
Assuming we’re already using node and NPM, we’re going to head to the base of our project directory, then install Gulp globally with:
npm install --global gulp
…and place our vanilla gulpfile.js and package.json files into the root of our project directory. package.json is a metadata file that provides information on our project, as well as its dependencies – which is like a shopping list of services you tell NPM to run out and install when firing up the project locally for the first time. Alongside this, your gulpfile.js is the file in which you set up your Gulp tasks, including references to plugins shortlisted in package.json.
To get the project up and running once these files are in place, we just need to type npm install. Based on your package.json file, your various dependencies will then be installed. You’re up and running!
Looking at the files
Here’s what our package.json looks like:
…and here’s our basic Sass-ready gulpfile.js in full:
For now, we won’t delve into the nitty-gritty of adding or modifying our gulp processes, as the nuances tend to change from plugin to plugin. Generally speaking though, they’re all pretty well documented and accessible. Check the full list of plugins at gulpjs.com/plugins
So let’s dissect our Gulpfile:
This is where we’re including the various plug-ins we’re planning to use in our Gulp tasks. Think of it like getting your ingredients together before assembling a couple of burgers.
From top to bottom:
- gulp is the plugin for using Gulp itself
- gulp-ruby-sass is the sass processing plugin specific to gulp
- gulp-autoprefixer automatically adds required vendor prefixes to our css properties
- gulp-sourcemaps generates css sourcemaps from our SCSS files
- gulp-notify lets us add alerts and notifications into our gulp tasks
- gulp-cache caches temp files within tasks to improve completion rates
- gulp-combine-media-queries takes all styles under duplicate media query declarations and merges them into as few as possible
- browser-sync is a handy tool that allows live, automatic updating of multiple browsers on file change
Generating our CSS
Here, we’re setting up a task specifically to handle rendering CSS from SCSS. From top to bottom, we’re:
- Locating the master SCSS file style.scss, passing it through the Sass plug-in;
- Taking that output and running it through the autoprefixer; then
- Generating sourcemaps; then
- Passing it through the media query combining plug-in (to merge duplicate queries); then lastly
- Saving all of that out to style.css, at the destination directory
- Optionally reloading the browsers if they’re listening for an update
Input and output targets can be modified easily, and steps can be added or removed to the process chain as needed. Type gulp styles to use.
Listening for changes
This is our watch task, which kicks off when we type gulp watch. It allows us to set and forget a watching state for tasks we want to run over and over without manual intervention – in this case, our styles task above. The watch task will listen for changes to our SCSS files and run the styles task every time it sees something new.
Automatically reloading our browsers
This task is similar to our watch task, except it updates any number of browsers simultaneously once it knows all tasks are complete. Remember to add your staging url into the proxy value. Type gulp serve to start.
Setting a default task
This is where we set up the default action for gulp (as in, what happens when we just type gulp on the command line). In this case, we’re defaulting it to run our styles task as a once-off.
Get stuck in
Feel free to wander over and pinch the files used in this demo at bitbucket.org/humaanco/gulp-demo. While it’s very much a basic look at getting a few processes running with Gulp, it’s entirely workable as a starting point and easily updated to include further tasks for things like: