photo credit: IMG_4502.JPG via photopin (license)

Watching and building your project with Gulp

A while ago, I wrote an article about a basic Grunt setup for building. But as some of you might already know for some time now, the streamed task runner Gulp is winning more and more popularity in the fields of web development. I’ve also tasted a bit of Gulp myself (not as much as Grunt since I prefer proven technology) but nevertheless I’ve got a basic Gulp setup for building a website. And it nicely integrates with Continuous Integration processes like Jenkins for example. So let’s just have a look at it shall we?

The Gulp modules

The Gulp modules I use are:

Or as you will:

The gulpfile.js

And without any further adieu, here’s the content of my gulpfile.js :

As you might notice, I’ve created 2 ‘sections’: One for the development (dev) tasks, which I use when I’m working locally, and one for the build task that is ran by our Continuous Integration server.

Development tasks

These tasks are here to render my SCSS and concatenate my JavaScript files (more on that further on in this article). The watcher and live reload plugin makes sure everything gets updated automatically while I’m working on them. It also provides source maps that help me track down code in the separate SCSS/JS files when I’m tracing my code or stylesheets. When I’m going to work on the project, a simple gulp watch  in the terminal will do.

Build tasks

The build tasks are almost identical to the development tasks but with 2 small differences:

  • They don’t create source maps. We don’t need those on a live site.
  • They minify and uglify the heck out of my CSS and JS. But it saves bandwidth and that’s cool.

Our Continuous Integration server is set to execute a gulp build  to do all this magic for us.

guy with unicorn shirt saying magic

Concatenating JavaScript

When I’m writing JavaScript, I like to keep my code as clean and separated as possible. I set up my JavaScript as prototype-classes for each functionality and treat them like such. That’s why I create separated files for each JavaScript class and let Gulp concatenate (and minify/uglify) these files for me while I’m at it. In my website, I only need to create one <script> -tag with one JavaScript file which is the sum of all my separate JavaScript files.

In conclusion

Gulp is a great tool with great benefits. It’s community is very active but since it’s newer than Grunt some plugins might not work as well as you might expect. For example, the source maps of gulp-ruby-sass  don’t work out of the box at the moment of writing, that’s why I use the non-ruby version called gulp-sass . It’s yet to determine which of these will be one eventually most used by the developers worldwide. And that’s just one example.
Grunt on the other hand has already a pretty proven track-record, that’s why I didn’t work much with Gulp earlier (that, and I’ve been doing huge backend-jobs for the last couple of months).
Will there be a place for two task runners? Will one become bigger and in time destroy the competition? I don’t know. One major benefit of Gulp is it’s simplicity and it’s speed since it works with streams instead of files. But how long will it take until Grunt will also get a stream-like processing system? In the end I think it comes down to a question of developers taste and proven technology.

Visitors give this article an average rating of 4.4 out of 5.

How would you rate this article?

Leave a Reply