Why Webpack?

From the blog:
isomorphic-webpack - Universal module consumption using webpack - Interview with Gajus Kuizinas

Why would you use webpack over tools like Gulp or Grunt? It's not an either-or proposition. Webpack deals with the difficult problem of bundling, but there's so much more. I picked up webpack because of its support for Hot Module Replacement (HMR).

You can use webpack with task runners and let it tackle the hardest part. The community has developed a large number of plugins to support it so it is fair to say that the line between webpack and task runners has become blurred, though. Often you set up npm scripts to invoke webpack in various ways and that's enough.

Webpack may be too complex for simple projects and I consider it as a power tool. Therefore, it is good to be aware of lighter alternatives and choose the right tool based on the need instead of hype.

Due to HMR you see webpack quite a bit especially in React based projects. There are certain niches where it's more popular than others and it has become almost the standard especially for React.

Webpack Supports Variety of Formats#

Webpack will traverse through the require and import statements of your project and will generate the bundles you have defined. It supports ES6, CommonJS, and AMD module formats out of the box.

The loader mechanism works for CSS as well and @import is supported. There are also plugins for specific tasks, such as minification, localization, hot loading, and so on.

To give you an example, require('style-loader!css-loader!./main.css') loads the contents of main.css and processes it through CSS and style loaders from right to left. The result will be inlined to your JavaScript code by default and given this isn't nice for production usage, there's a plugin to extract it as a separate file.

Webpack is Configuration Driven#

Given this kind of declarations tie the source code to webpack, it is preferable to set up the loaders at configuration. Here is a sample configuration adapted from the official webpack tutorial:

webpack.config.js

const webpack = require('webpack');

module.exports = {
  // Where to start bundling
  entry: {
    main: './entry.js'
  },
  // Where to output
  output: {
    // Output to the same directory
    path: __dirname,
    // Capture name from the entry using a pattern.
    filename: '[name].js'
  },
  // How to resolve encountered imports
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }
    ]
  },
  // What extra processing to perform
  plugins: [
    new webpack.optimize.UglifyJsPlugin()
  ],
  // How to adjust module resolution
  resolve: {
    // This would be a good place to monkeypatch packages
    alias: { ... }
  }
};

Given the configuration is written in JavaScript, it's quite malleable. The configuration model may make webpack feel a bit opaque at times as it can be difficult to understand what it's doing. This is particularly true for more complicated cases. Covering those is one of the main reasons why this book exists.

Hot Module Replacement#

You might be familiar with tools, such as LiveReload or BrowserSync, already. These tools refresh the browser automatically as you make changes. HMR takes things one step further. In the case of React, it allows the application to maintain its state without forcing a refresh. This sounds simple, but it makes a big difference in practice.

Note that HMR is available in Browserify via livereactload, so it's not a feature that's exclusive to webpack.

Code Splitting#

Aside from the HMR feature, webpack's bundling capabilities are extensive. It allows you to split code in various ways. You can even load them dynamically as your application gets executed. This sort of lazy loading comes in handy, especially for larger applications. You can load dependencies as you need them.

Even small applications can benefit from code splitting as it allows the users to get something useable in their hands faster. Performance is a feature after all. So, knowing the basic techniques is worthwhile.

Asset Hashing#

With webpack, you can easily inject a hash to each bundle name (e.g., app.d587bbd6e38337f5accd.js). This allows you to invalidate bundles on the client side as changes are made. Bundle splitting allows the client to reload only a small part of the data in the ideal case.

Unfortunately, this isn't as easy problem yet as I would like, but it's manageable assuming you understand the possible setups well enough.

Loaders and Plugins#

All these smaller features add up. Surprisingly, you can get many things done out of the box. And if you are missing something, there are loaders and plugins available that allow you to go further.

Webpack comes with a significant learning curve. Even still, it's a tool worth learning, given it saves so much time and effort over the long term. To get a better idea how it compares to some other tools, check out the official comparison.

Conclusion#

In the following chapters, we'll examine webpack in more detail as you will learn to develop a basic development and build configuration. The later chapters delve into more advanced topics. It is these building blocks you can use to develop your own setup.

You can use webpack with some other tools. It won't solve everything. It does solve the difficult problem of bundling, however. That's one less worry during development. Just using package.json, scripts, and webpack takes you far, as we will see soon.

Previous chapterWebpack Compared

This book is available through Leanpub. By purchasing the book you support the development of further content. A part of profit (~30%) goes to Tobias Koppers, the author of Webpack.

Need help?