Webpack vs Gulp

With the raising popularity of Webpack more and more people start comparing it with Gulp.

Fierce discussions populate comment sections of web development websites about which one is better. In this article we'll show you what Webpack is, how it differs from Gulp, and – most importantly – which one you should use.

Introduction

In the past couple of years a lot has changed in the web development industry, with new tools continually displacing old resolutions. This happened, for example, to CodeKIT, a GUI-based tool for compiling and minifying tools and assets, which was replaced by Grunt. Then Gulp appeared, and immediately won the hearts of web developers with its intuitiveness and power.

Now, Webpack is on the tide. Will it completely replace Gulp? Opinions are divided, but the trend is very strong (Grunt: red, Gulp: blue, Webpack: yellow)

What is this Webpack anyway?

Following the offical Webpack website

Webpack takes modules with dependencies and generates static assets representing those modules.

The whole idea is very well represented by the infographic below:

Here are some resources that will help you kick off:

• Getting started with Webpack: https://webpack.js.org/guides/get-started/
• Official Webpack documentation: https://webpack.js.org/

Gulp vs Webpack

#1: Gulp is a task runner

In short, a task runner is an application that lets you automate repeatable activities. The tasks are defined in a JS file and executed with a command containing the name of the task. You can, for example:

• run tests and merge files
• compile Sass
• minify CSS/HTML
• bundle/uglify JS

First, you define the tasks. The process is very easy:

gulp.task('test:unit', () => { /* Run unit tests */});
gulp.task('test:e2e', () => { /* Run Selenium tests */});
gulp.task('test', ['test:unit', 'test:e2e']);
gulp.task('build:sass', () => { /* Compile Sass */ });

Then you can run all tasks with a single command:

$ gulp test

or individually:

$ gulp build:sass

#2: Webpack is NOT a task runner

Contrary to Gulp, Webpack is a module bundler. It's main purpose is to generate static assets from the application modules and dependencies.

Let's assume we have an application that consists of 2 JS files and one CSS file:

first.js

require("!style-loader!css-loader!./style.css");
document.write(require("./second.js"));

second.js

module.exports = "Hello world!";

style.css

body {
    background: yellow;
}

Let's use Webpack to merge them into one file. First, install the bundler and CSS loaders:

$ npm install webpack -g
$ npm install css-loader style-loader

Now, run the command:

$ webpack ./first.js target.js

The result will be target.js, a bundled .js file with our application.

Using Webpack with package.json scripts

Okay, so we know that Webpack is not a task runner. Does that mean you have to use Gulp/Grunt to handle your tasks? Not at all.

All you need to do is define your tasks in the scripts section of your package.json file:

{
 "scripts": {
   "build": "node build.js"
 }
} 

You can use NPM or Yarn as a task runner:

$ yarn run build

And the winner is...

With both tools you can handle practically every type of workflow. In terms of usability, Gulp is the winner here: it's much easier to define and execute your tasks. On the other hand, Webpack's configuration options are much more flexible + it's developing very fast and has a community growing in size with every day.

It's hard to indicate a clear winner here: it all depends on the profile of your work and the preferences of your team. The truth, as always, is prozaic.

Summary: Using Webpack with Gulp

This article was inspired by one of the articles on CSS Tricks, specifically the discussion in the comments section.

Some people fell in love with Webpack, claiming they don't need Gulp anymore. Some people praised the simplicity of Gulp and complained Webpack is overengineered. As one person put it: "Things need to be practical, seat-of-your-pants, and forgiving".

In Buddy.Works we think there's no correct answer to that argument: we do recommend Webpack as a bundling tool, but that doesn't mean you have to give up Gulp entirely if you start using it. After all, the ultimate aim of both applications is to help you deliver better, faster websites.

As you can see, our delivery workflow contains both actions: what you're going to use in the end is entirely up to you.

Keep calm and <code> on!