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
Good one, will watch. I guess I get my answer.
Watched talk, it's informative. Thanks.
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.
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. :)
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. :)
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.
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:
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.
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
.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();
Thanks, I will look into it.
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 😉
*Json Grid *<=Developed with love!
*Json Grid *<=Developed with love!
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!
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..
They are both doing a different job...
Gulp is a task runner...
Webpack is a source code bundler..
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.