We have gotten used to having Gulp around these days for building frontend code and assets. There is a reasonable chance that you even switched from Grunt to Gulp not even that long ago. But just as you got used to writing your build scripts in code, Webpack introduces a new look at the matter, by replacing code with configuration and general assumptions. You are probably wondering how that can be a good thing and what the advantages are.
This works fine as soon as you find out how to script this all together in Gulp. But the more tasks you add to it, like minifying, babelifying, the more complex and time consuming this becomes. You have to script everything into the bundle build process. And then you probably also want different build scripts for development, test, distribution, etc.
It also assumes that you use require for every type of file. You can require css/sass, images and even html files. Webpack will build and bundle your application from there based on module loaders. If it sees a scss file required for example, it will load the sass-loader and add the generated css to a css bundle, or as configured. These module loaders, combined with the plugin architecture, will still give you all the flexibility you need.
Because of this generalised approach, Webpack also has some added advantages. For example a code watcher and a webpack devserver with auto reloading are all default functionality. And because this all plays together so well, magical things can happen, as Dan Abramov showed in his talk about React hot reloading during React Europe.
We are using Webpack currently in our new development stack for editor tools. However we are still using Gulp for asset management in our website. It’s all about picking the right tool for the job.