Gulp vs Webpack Gulp vs Web-pack

Hey Kim!

I gave a talk on frontend build tools last year, that has a lot of information about Gulp and Webpack, what they do, and how they differ! If you're interested, here it is: vimeo.com/294976509

The short answer to Gulp vs Webpack is: it depends on your project needs. If the project is a JavaScript based application, then you probably should use Webpack. If not, Gulp might work just fine for your project.

To me, they serve different purposes. Gulp manages a set of tasks, but is pretty ignorant of what those tasks actually entail. Webpack provides the "guts" of one type of task, specifically preparing source code for use on the web.

Crutchfield uses Gulp to manage build tasks, because it integrates well with Visual Studio. But we launch Webpack in a Gulp task to actually build our JS assets.

I would recommend checking out Webpack Encore:

Webpack Encore is a simpler way to integrate Webpack into your application. It wraps Webpack, giving you a clean & powerful API for bundling JavaScript modules, pre-processing CSS & JS and compiling and minifying assets. Encore gives you a professional asset system that's a delight to use.

It generates Webpack configuration for a lot of common use cases via some method calls on its main object. I think it’s a good way to get started with Webpack without being directly exposed to the potential complexity of the full configuration.

For example, in a personal project, I have this, which compiles a custom Bootstrap (with my overriden variables) in my_bootstrap.css and my_bootstrap.js, and the rest in app.css and app.js. So compilation is super fast because Bootstrap is not recompiled unless I touch its files.

// webpack.config.js
var Encore = require('@symfony/webpack-encore');

Encore
    // directory where compiled assets will be stored
    .setOutputPath('site/build/')
    // public path used by the web server to access the output path
    .setPublicPath('/build')

    // Bootstrap CSS and JS, shared with each entry.
    .createSharedEntry( 'my_bootstrap', './assets/js/my_bootstrap.js' )

    // Add 1 entry for each "page" of your app (including one that's 
    // included on every page - e.g. "app"). Each entry will result in
    // one JavaScript file (e.g. app.js) and one CSS file (e.g. app.css)
    // if you JavaScript imports CSS.
    .addEntry( 'app', './assets/js/app.js' )

    .enableSingleRuntimeChunk()
    .cleanupOutputBeforeBuild()
    .enableSourceMaps( ! Encore.isProduction() )
    // enables hashed filenames (e.g. app.abc123.css)
    .enableVersioning( Encore.isProduction() )

    // uncomment if you use TypeScript
    //.enableTypeScriptLoader()

    // uncomment if you use Sass/SCSS files
    .enableSassLoader()
    // needed to compile Bootstrap, it relies on autoprefixer
    .enablePostCssLoader()

    // uncomment if you're having problems with a jQuery plugin
    //.autoProvidejQuery()
;

module.exports = Encore.getWebpackConfig();

I don't really like configuring a project's build step, deployment e.t.c with webpack or gulp or any other build tool. If your colleague will set it up with webpack, then go with it. Your colleague will be happy with using webpack and you'll spend your time on the actual development instead of configuring 😉

I'm not a fan of Gulp. I don't see a good place for it. If you want to run tasks on files, there's Grunt. And then if you want to use modular javascript there's webpack. And then if you think webpack is too hard/bloated there's parcel.

Gulp seems to be somewhere in between Grunt and Webpack - like it can't decide whether it wants to be a task runner or focus on modular javascript.

You can use Webpack with Gulp by using the gulp-webpack plugin :) But more generally, I'd recommend following your gut. Webpack is amazing and very powerful, but you'll be more productive focusing on the new project itself and not possibly wasting hours or days struggling with webpack configuration like I have..

In 99% of the projects using Gulp I've seen, Gulp is doing the job Webpack would do. Maybe Gulp wasn't designed to this (I kind of disagree with that though), but that's been my experience.

Webpack does bundle JS out of the box, but ultimately you'll need loaders and plugins if you want to customize. Similarly, you'll need plugins for Gulp.

In the end, these tools with become host environments for plugins. Which one seems the most logical and well designed is the question I ask myself.

Gulp architecture is like a single conduit, though which data flows through — passing through plugins which transform it. SCSS flows into the Gulp pipeline and out comes CSS.

Webpack's data flow is a little different. There is an entry and bundle file, but plugins are needed too for side effects. For example to output a CSS file, you import the CSS into JS via , then a plugin pulls it out as a string and writes it to a file.

Another thing to consider is the docs — which is most informative and well written, giving examples and use cases.

This is highly subjective, but to my eyes Gulp has a logical design that is almost beautiful whereas Webpacks design seems more confused. That said, Webpack is very popular!

They are both doing a different job...

Gulp is a task runner...
Webpack is a source code bundler..