Journey from browserify to webpack

And why webpack is awesome.

It has been a long journey for me to find a front-end build tool in NodeJS. The ruby community benefits greatly from the awesome gem, sprockets. Now I can say webpack is to Nodejs as sprockets is to ruby.

Advantages of using assets build tools

You may wonder how could webpack dominate the front-end world? I would say, it makes JavaScript modules management works like a charm. No matter its a CommonJS/AMD/global module, webpack could easily bundle them together. This could help us

1. Create modularized, easy to organized code structure
2. Use existing JavaScript library from npm/NodeJS without ANY efforts
3. Provides best HTTP performance with bundled assets

Just those? All these features could be achieved by browserify as well. Why do I need to migrate from browserify to webpack?

The reason is simple. The same reason holds for choosing gulp over Grunt.

Writing codes instead of writing configs.

For a consumer of browserify, you use everything available from CLI interface. Definitely, it’s easier to learn browserify due to its simpler interface and usage. But you also lose the flexibility of using front-end assets build tools.

comparing webpack to browserify

For example, if I want to add jQuery as dependency, which is in AMD format, I have to use deamdify to make it happy with browserify. With that, you have two options:

1. use CLI: `browserify -t deamdify main.js -o bundle.js`
2. use browserify key in package.json:

{
  "browserify": {
    "transform": "deamdify"
  }
}

Both solutions have the same pitfalls, the api of browserify limits the usage of transform. It’s impossible to add more transform onto it.

As webpack? Just add one line in webpack.config.js:

amd: { jQuery: true },

That’s it! Simple, elegant and works like a charm. You could easily add more plugins such as UglifyJS to plugins. For more information on migration from browserify to webpack, take a look at the following link:

Other advantages of using webpack

Except those we mentioned above, these are also important features:

1. Built-in cache busting support (by adding hash to compiled assets)
2. Great dev tools support (CLI: webpack, webpack-dev-server)
3. Blazing fast (re)build time
4. Good bower integration
5. Extensible with Loader API (could even load styles/fonts/…everything)

Cache busting

You could easily add hash segments to your bundled assets name. I’ve successfully tried to make it works with generated JavaScript bundles and injected the hashed-filename to jade template. You could see:

https://github.com/tomchentw/react-editable/blob/e4b36d9e5bc05231c896cf5f3cf7c42659219c7f/package.json#L12

Great dev tools support

Webpack ships with builtin`webpack` command. It can watch/build assets for you. If you need webpack to start a static file server for you, use `webpack-dev-server` plugin and it plays well with webpack module. They’re simple to use and seamlessly work like a charm.

Blazing fast (re)build time

When you’re in watch mode, no matter using `webpack —watch` or `webpack-dev-server`, it will immediately recompile and just recompile the changed module. This saves our time during the changes.

Good bower integration

Although the official of webpack suggests that you should prefer modules shipped via npm instead of bower, it’s still doable for webpack to require bower components. See: http://webpack.github.io/docs/usage-with-bower.html

Extensible with Loader API

Take a look at the Loader section in doc

I also load my Sass powered stylesheets from index.js, which will embed the stylesheets as a pure String into bundled script file.