Gulp vs Web-pack

・1 min read

I'm starting new JavaScript/html based project. I'm very much comfortable with Gulp, since I worked on this a lot, so my gut says to go with this. But my colleagues are insisting on checking web-pack.

I'm looking for an opinion from community.

So, should I go with Gulp, or check on Web-pack, If I choose one on another, why? Let me know your thoughts.

Kim John
Json Grid <=Developed with love!


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.


Got it, so Gulp seems like more of generic tool to deal with any kind of task whereas Webpack is specific to web-project.

Kim John


Pretty much. I'll add the caveat that Webpack can compile to targets besides the web. But it's still basically a compiler.

Ohh! Could please elaborate this little: "Webpack can compile to targets besides the web". Thanks for your response. :)

Kim John

Sure! The target is specified in Webpack's config (just a JSON object full of settings). There are a number of target options, but the two I'm familiar with are web and node. web builds JS to be served to web browsers. node builds JS to run on a server with the nodejs runtime.

This is good information. I'll definitely look into this. Thanks for this. :)

Kim John


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:

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.


Good one, will watch. I guess I get my answer.

Kim John


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.


Wow, Grunt! To me, Grunt is all about configuring the tool. I prefer writing code over configuration. I don't have much experience in Grunt though. I guess it's more about what you are comfortable with. Once you are out comfort, you learn something new.

Kim John


Gulp and Grunt is in the same place to me. Both task runners and highly configurable, and I used both for years to success, but if given the choice between ONLY those two, I'd go with with Gulp any day. To use gulp, you have a minimal API surface, and then you are good. It's all just JS from there, so you can code your way out of any problem.

Grunt ... so much implicit knowledge that needs to be in place to get a lot of stuff done because the interpolation in the Grunt templates get in the way. Here are some ancient posts that required me to read the entire source code of Grunt (long night) to solve my issues:

These days I don't use either. I just use NPM as the task runner and if the task can't fit in a short line, I delegate to a plain Node script.


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');

    // directory where compiled assets will be stored
    // public path used by the web server to access the output path

    // 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' )

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

    // uncomment if you use TypeScript

    // uncomment if you use Sass/SCSS files
    // needed to compile Bootstrap, it relies on autoprefixer

    // uncomment if you're having problems with a jQuery plugin

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 πŸ˜‰


They are both doing a different job...

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

Classic DEV Post from Jul 8 '18

Why I hate Infinite Scrolling

I am sure you have seen old Pre-Material Design YouTube homepage layout where t...

Made complex JSON inspecting super easy. Created revolutionary free online tool( to visualize JSON as table and Connected every table cell to JSON element, awesome right!