Gulp vs Webpack Gulp vs Web-pack

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 dev.to 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!

Comments

[Jake Dohm]

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.

[Kim John]

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

Kim John

[Kaushal]

Watched talk, it's informative. Thanks.

[Michael Crenshaw]

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.

[Kim John]

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

[Michael Crenshaw]

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

[Kim John]

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

Kim John

[Michael Crenshaw]

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.

[Kim John]

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

Kim John

[Eugene Karataev]

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 😉

[Kim John]

Good one!

Kim John
*Json Grid *<=Developed with love!

[Olivier “Ölbaum” Scherler]

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

[Kim John]

Thanks, I will look into it.

[Anton Frattaroli]

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.

[Carl-Erik Kopseng]

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:
stackoverflow.com/a/24447293
stackoverflow.com/questions/244408...

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.

[Kim John]

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

[Jesse Skinner]

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..

[George C. Norris]

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!

[Damola Adekoya]

They are both doing a different job...

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