Browserify vs Webpack
If you need a cabin, why start
with a mere pile of logs?
Just last year Grunt was effectively dethroned by Gulp. And now, just as Gulp and Browserify are finally reaching critical mass, Webpack threatens to unseat them both. Is there truly a compelling reason to change your front-end build process yet again?
Let’s consider the merits of each approach.
Browserify (and friends…)
Browserify is conceptually simple. Hey, see all these cool packages on npm? Let me wrap those up for ya so you can use those in the browser. Handy. Thanks Browserify! Yet this simplicity is also its Achilles heel. Chances are you have a long list of other things you need to get done like minifying, bundling, linting, running tests, etc.
If you think of your build process like a unique log cabin, then Browserify with Gulp/Grunt is like starting off here:
Webpack attacks the build problem in a fundamentally more integrated and opinionated manner. In Browserify you use Gulp/Grunt and a long list of transforms and plugins to get the job done. Webpack offers enough power out of the box that you typically don’t need Grunt or Gulp at all. Yep, sorry, that shiny new skill you just mastered is already nearly useless. Uh…yay? Sigh. Welcome to life on the front-end.
But hey, that’s the price of progress. With Webpack you can declare a simple config file to define your build process. Woah, a config file? Yes, if you migrated from Grunt to Gulp because you prefer code over configuration, that may sound like a step backward. But configuration isn’t necessarily a bad thing.
Configuration-based systems are preferable to imperative systems if they make the right assumptions about your goals up front.
Huh? Why not simply reference CSS the old way? Well, Webpack will consider the size of this file. If it’s small, it’ll inline the stylesheet! If it’s long, it’ll minify the file and give it a unique name for cache busting. This same story works for images as well using the url loader plugin.
img.src = require(‘./glyph.png’);
Webpack will base64 encode this image if it’s small enough that it makes sense. Slick!
Finally, if you want to enjoy rapid application development without browser refreshes, Webpack offers hot module replacement. If you happen to work in React, you can utilize React Hot Loader. Yes, Browserify has an equivalent, but in my experience, Webpack’s implementation by @dan_abromov is superior. Trust me, once you’ve experienced rapid feedback application development like this, you’ll never go back:
Webpack assumes you want to build a log cabin. So you start with a real cabin, and then it gives you the tools need to tweak it to your needs.
The Bottom Line
If you prefer explicitly configuring small single-purpose tools from the ground up, then Browserify with Gulp/Grunt is going to be more your style. Browserify is easier to understand initially since the conceptual surface area is so much smaller — assuming you already know Gulp or Grunt. When using Gulp with Browserify, the resulting build process can be easier to understand than the equivalent Webpack build. It’s often more explicit about intentions. Browserify’s rich plugin ecosystem means you can get just about anything done with enough wiring. Ah, the wiring. That’s the big downside. Being this explicit takes a lot of time and debugging to get right. I recently created a starter kit for my upcoming Pluralsight course on React and Flux. It pulls in some React specific tech, but removing those dependencies is trivial if you’re just looking for a quick way to get rolling with Browserify and Gulp.
But if you’re comfy with a little “magic” via a single more opinionated tool, then Webpack can reduce the time it takes to stand up a robust build process. I’ve found my Webpack configs are usually about half the size of the equivalent Gulp file. The win isn’t merely less typing — This also translates to less time spent debugging your config.
Massive Grunt files turned many off to the idea of configuration. But Grunt’s failure wasn’t configuration. It was a lack of opinion. Configuration isn’t evil. It’s a powerful time-saver when the assumptions are right.
Build tooling shouldn’t require a custom build from the ground up. It should provide customization points that allow you to handle the few things that make you truly unique.
Ready to dig deeper?
Using React? Check out “Building Applications with React and Redux in ES6”.