Webpack — What is it and is it better than Gulp?
Webpack vs Gulp
OK, now that we know what Webpack is, how can we actually compare it to Gulp? First, we need to understand that Gulp’s purpose is completely different from Webpack. It’s not meant for bundling, it’s just meant to run tasks. You set up a basic JavaScript function that gets called and executed. It’s so simple that many people have extended it beyond its initial intend. Webpack, on the other hand, is all about bundling. That entails a more complex syntax, as I previously mentioned, as well a more complex approach for cases such as when you need your modules to be on their own files or if you need your CSS to be taken out of that bundle, as things like these are not core to Webpack — there are plugins to do all those things and more, but what you end up with is getting stuck in the spider web of this massive configuration file that you can’t easily break it or give it to the next person to understand it.
As we can see, Gulp is extremely simple, as Webpack is more complex and require plugins and rules to execute the tasks we need. However, on a regular project, there are many more tasks involved other than just converting SASS/LESS files into CSS files. That’s when developers starting using Gulp to do more things, such as bundling files, which is the main purpose of Webpack. That might be fine, because you start small and scale your code as you need, but because you need to be constantly scaling up your Gulp file, that can become a cumberstone task and you might end up pushing Gulp too far from it’s main purpose. Things like error catching and reloading or running tasks in a certain order can turn your Gulp file into a monster on its own — things like these are not supported in Gulp, so you actually need packages such as plumber and run-sequence to achieve those tasks. That’s why Webpack is so powerful. Even though it’s syntax might be complex, once you understand it, it can become a very amazing tool that allows you to do a lot of the things you would struggle with Gulp. Again, with Gulp, when you add complexity, you are basically pushing its boundaries, as Webpack is actually meant for that kind of environment.
If you just need some basic bundling, just stick with Gulp, you don’t need to bother with Webpack. However, if you need to mix in multiple JavaScript files and maybe have some of them split up in certain ways or if you need to have jQuery and Bootstrap split out but still want to share them between files, or if you need multiple HTML files, then stop using Gulp and look at Webpack. Webpack is an incredible, powerful tool that can do quite a lot for you when you are dealing with a massive application. For instance, one of the things it does very well it’s called tree shaking. Let’s say, for example, that you only need a couple of functions from a massive library like lodash. You can actually leverage Webpack tree shaking and only grab the functions you need, without needing to load the entire library. Again, if you are using Gulp and you get yourself needing more and more advanced features, that’s when you should switch to Webpack.
So, if you ask me, is Webpack worth it? Absolutely, it’s the best build system around even if you don’t want to call it a build tool or build system. It handles modern JavaScript applications in a way that you could not necessarily do before with all of the modern bells and whistles. But at the end of the day, you will have to decide which one is better for you based on your situation and on our project. Regardless of your choice, both Webpack and Gulp are amazing tools and have a great community behind them.
Let me know in the comments below which one you have been using, I would love to hear what people have to say about both systems. And remember, stay curious and keep coding!
Gulp + Webpack or JUST Webpack?
This answer might help. Task Runners (Gulp, Grunt, etc) and Bundlers (Webpack, Browserify). Why use together?
...and here's an example of using webpack from within a gulp task. This goes a step further and assumes that your webpack config is written in es6.
Task Runners (Gulp, Grunt, etc) and Bundlers (Webpack, Browserify). Why use together?
Grunt and Gulp are actually task runners, and they have differences like config driven tasks versus stream based transformations. Each has its own strengths and weaknesses, but at the end of the day, they pretty much help you create tasks that can be run to solve a larger build problem. Most of the time, they have nothing to do with the actual run-time of the app, but rather they transform or they put files, configs and other things in place so that the run time works as expected. Sometimes they even spawn servers or other processes that you need to run your app.
Webpack and Browserify are package bundlers. Basically, they are designed to run through all of a package's dependencies and concatenate their source into one file that (ideally) can be used in a browser. They are important to modern web development, because we use so many libraries that are designed to run with Node.js and the v8 compiler. Again, there are pros and cons and different reasons some developers prefer one or the other (or sometimes both!). Usually the output bundles of these solutions contain some sort of bootstrapping mechanisms to help you get to the right file or module in a potentially huge bundle.
The blurred line between runners and bundlers might be that bundlers can also do complex transformations or trans-pilations during their run-time, so they can do several things that task runners can do. In fact, between browserify and webpack there's probably around a hundred transformers that you can use to modify your source code. For comparison, there's at least 2000 gulp plugins listed on npm right now. So you can see that there are clear (hopefully... ;)) definitions of what works best for your application.
That being said, you might see a complex project actually using both task-runners and package bundlers at the same time or in tandem. For example at my office, we use gulp to start our project, and webpack is actually run from a specific gulp task that creates the source bundles that we need to run our app in the browser. And because our app is isomorphic, we also bundle some of the server code.
In my humble opinion, you might want to get familiar with all of these technologies because chances are you will see (use) all them in the course of your career.