repo from [toptal.com](https://www.toptal.com/front-end/webpack-browserify-gulp-which-is-better) | author@ERIC GROSSE As web applications grow increasingly complex, making your web app scalable becomes of the utmost importance. Whereas in the past writing ad-hoc JavaScript and jQuery would suffice, nowadays building a web app requires a much greater degree of discipline and formal software development practices, such as: - Unit tests to ensure modifications to your code don’t break existing functionality - Linting to ensure consistent coding style free of errors - Production builds that differ from development builds The web also provides some of its own unique development challenges. For example, since webpages make a lot of asynchronous requests, your web app’s performance can be significantly degraded from having to request hundreds of JS and CSS files, each with their own tiny overhead (headers, handshakes, and so on). This particular issue can often be addressed by bundling the files together, so you’re only requesting a single bundled JS and CSS file rather than hundreds of individual ones.  > Which bundling tool should you use: Webpack or Browserify + Gulp? Here is the guide to choosing. ## A Quick Introduction to Gulp Gulp’s API consists of four functions: - gulp.src - gulp.dest - gulp.task - gulp.watch  ## Where Does Webpack Fit In?  When using the CommonJS pattern, bundling JavaScript files isn’t as simple as concatenating them. Rather, you have an entry point (usually called index.js or app.js) with a series of require or import statements at the top of the file: ### ES5 ``` var Component1 = require('./components/Component1'); var Component2 = require('./components/Component2'); ``` ### ES6 ``` import Component1 from './components/Component1'; import Component2 from './components/Component2'; ``` ### Why Are Developers Using Webpack Instead of Gulp? Webpack is a bundler whereas Gulp is a task runner, so you’d expect to see these two tools commonly used together. Instead, there’s a growing trend, especially among the React community, to use Webpack instead of Gulp. Why is this? Simply put, Webpack is such a powerful tool that it can already perform the vast majority of the tasks you’d otherwise do through a task runner. For instance, Webpack already provides options for minification and sourcemaps for your bundle. In addition, Webpack can be run as middleware through a custom server called webpack-dev-server, which supports both live reloading and hot reloading (we’ll talk about these features later). By using loaders, you can also add ES6 to ES5 transpilation, and CSS pre- and post-processors. That really just leaves unit tests and linting as major tasks that Webpack can’t handle independently. Given that we’ve cut down at least half a dozen potential gulp tasks down to two, many devs opt to instead use NPM scripts directly, as this avoids the overhead of adding Gulp to the project (which we’ll also talk about later). The major drawback to using Webpack is that it is rather difficult to configure, which is unattractive if you’re trying to quickly get a project up and running.