This week, Facebook merged a monster pull request into React that replaced its existing build process with one based on Rollup, prompting several people to ask ‘why did you choose Rollup over webpack’?
A tale of two bundlers
webpack was started in 2012 by Tobias Koppers to solve a hard problem that existing tools didn’t address: building complex single-page applications (SPAs). Two features in particular changed everything:
- Code-splitting makes it possible to break your app apart into manageable chunks that can be loaded on-demand, meaning your users get an interactive site much faster than if they had to wait for the whole application to download and parse. You can do this manually, but, well… good luck.
- Static assets such as images and CSS can be imported into your app and treated as just another node in the dependency graph. No more carefully placing your files in the right folders and hacked-together scripts for adding hashes to file URLs — webpack can take care of it for you.
require, and evaluating them one-by-one. That’s great if you need things like on-demand loading, but otherwise it’s a bit of a waste, and it gets worse if you have lots of modules.
ES2015 modules enable a different approach, which Rollup uses. All your code is put in the same place and evaluates in one go, resulting in leaner, simpler code that starts up faster. You can see it for yourself with the Rollup REPL.
But there’s a trade-off: code-splitting is a much hairier problem, and at the time of writing Rollup doesn’t support it. Similarly, Rollup doesn’t do hot module replacement (HMR). And perhaps the biggest pain point for people coming to Rollup — while it handles most CommonJS files (via a plugin), some things just don’t translate to ES2015, whereas webpack handles everything you throw at it with aplomb.
So which should I use?
By now, hopefully it’s clear why both tools coexist and support each other — they serve different purposes. The tl;dr is this:
Use webpack for apps, and Rollup for libraries
That’s not a hard and fast rule — lots of sites and apps are built with Rollup, and lots of libraries are built with webpack. But it’s a good rule of thumb.
If you need code-splitting, or you have lots of static assets, or you’re building something with lots of CommonJS dependencies, Webpack is a better choice. If your codebase is ES2015 modules and you’re making something to be used by other people, you probably want Rollup.
Package authors: use
ES2015 changes all that, because
export are part of the language. In the future, there’ll be no ambiguity, and things will work a lot more seamlessly. Unfortunately, because browsers (mostly) and Node don’t yet support
export, we still need to ship UMD files (or CommonJS, if you’re building something Node-only).
By adding a
"module": "dist/my-library.es.js" entry to your library’s package.json file (aka
pkg.module), it’s possible to serve UMD and ES2015 at the same time, right now. That’s important because Webpack and Rollup can both use
pkg.module to generate the most efficient code possible — in some cases, they can even both tree-shake unused parts of your library away.
Learn more about
pkg.module on the Rollup wiki.
Our thanks to Rich Harris for writing this article. We believe that collaboration in open source is incredibly vital to ensure we push technology and the web forward together.
No time to help contribute? Want to give back in other ways? Become a Backer or Sponsor to webpack by donating to our open collective. Open Collective not only helps support the Core Team, but also supports contributors who have spent significant time improving our organization on their free time! ❤