Browserify vs Webpack
If you need a cabin, why start
with a mere pile of logs?
In the land of JavaScript, no one is king for long.
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.
Sure, Browserify has a rich ecosystem of transforms to help get things done. But to wire all this up, you’re on your own. So you’re going to reach for a JavaScript build automation tool like Grunt or Gulp. These tools work great, but configuring them properly is a time-consuming process. After you’ve worked with Grunt or Gulp for long, you start to realize a long list of things you do for every project. Wouldn’t it be nice to start with a more powerful and opinionated tool that made more assumptions about your build process?
If you think of your build process like a unique log cabin, then Browserify with Gulp/Grunt is like starting off here:
Webpack
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.
I find Webpack does just that. Webpack assumes you need to move files from a source directory to a destination directory. It assumes you want to work with JavaScript libraries in various module formats like CommonJS, and AMD. It assumes you’ll want to compile various formats using a long list of loaders. Sure, you can do all this via Browserify and Gulp, but you have to do more wiring yourself. And you’re manually wiring together two totally separate technologies.
The integrated nature of Webpack really shines when you consider the stories for working with other assets like images and CSS. Webpack is smart enough to dynamically inline your CSS and images when it makes sense. You can simply include these assets like you do with JavaScript today. Want to use CSS? Easy:
require("./stylesheet.css");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!
Since Webpack is totally aware of your build process, it can intelligently split your resources into bundles. This comes in handy on larger SPAs. Your users will be served only the files they need for a given page instead of a single monolithic JavaScript file.
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?
The updated Webpack docs are great, but I suggest reading Pete Hunt’s excellent intro instead. Then, check out “Creating a JavaScript Development Environment” on Pluralsight (free trial) to see a full development environment built from the ground up using Webpack.
Using React? Check out “Building Applications with React and Redux in ES6”.
Chime in on Hacker News or Reddit
Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect at VinSolutions, a Microsoft MVP, and trains software developers internationally on software practices like front-end development and clean coding. Cory tweets about JavaScript and front-end development on Twitter as @housecor.
