Webpack and Rollup: Same but different

From: http://www.css88.com/archives/7703

Published in

Fools dock

In early April, Facebook incorporated a huge pull request into the React Master branch, replacing its existing build process with rollup-based, This move prompted some people to wonder “Why did you choose Rollup over WebPack?”

It’s a perfectly legitimate question. Webpack is one of the biggest success stories of the modern JavaScript community, with millions of downloads per month and supporting thousands of websites and applications. It has a large ecosystem, many contributors, and a meaningful financial backing as a community open source project.

Rollup is unremarkable by comparison. React isn’t alone — Vue, Ember, Preact, D3, three.js, Moment, and many other well-known libraries also use Rollup. What’s wrong with the world? Why can’t we just have a universally accepted JavaScript modular packaging tool?

The story of these two packing tools

Webpack was started in 2012 by Tobias Koppers to solve a problem that the existing tools had not solved at the time: building complex single-page applications (spAs). Two webPack features in particular have changed everything:

1. Code Splitting allows you to break your app down into manageable chunks of Code that can be loaded on demand, which means your users can quickly access an interactive website without having to wait until the entire app is downloaded and parsed. Of course you can do this manually, so good luck.

2. Static assets such as images and CSS can be imported into your application and can be used as another node in the dependency graph. No more worrying about whether your files are in the right folder, no more using hack scripts to hash file urls, because WebPack takes care of that for us.

Rollup was created for a different reason: to take advantage of ES2015’s clever module design to build modules as efficiently as possible that can be directly referenced by other JavaScript libraries. Other module packaging tools – including Webpack – do this by wrapping each module in a function, putting them in a package, implementing them one by one through the browser-friendly require implementation. If you need to load on demand, a packaging tool like WebPack is great. Otherwise it’s kind of wasteful, and if you have a lot of modules, it gets worse.

The ES2015 module enables a different approach, which is used by Real Rollup. All the code is placed in one place and then executed once, resulting in cleaner, simpler code that starts faster. You can see it yourself using the Rollup REPL.

But there is a trade-off: Code Splitting is a much trickier issue, and at the time of this writing, Rollup does not support it. Similarly, Rollup does not support hot update (HMR) of modules. Perhaps the biggest pain point for anyone using Rollup is that it handles most CommonJS files (via plug-ins), while some things don’t translate to ES2015 at all, and WebPack handles everything you throw at it.

So what should I use

By now, it’s clear why you want these two tools to co-exist and support each other — they serve different purposes. To sum up:

Use WebPack for applications and Rollup for class libraries

This is not an absolute rule – there are actually many websites and applications built using Rollup, as well as a number of libraries built using WebPack. However,

Is a good rule of thumb.

Webpack is a great option if you need Code Splitting, or if you have a lot of static resources to work with, or if you’re building a project that requires a lot of CommonJS module dependencies. If your code base is based on ES2015 modules and you want to write code that can be used directly by others, the packaging tool you might need is Rollup.

Advice to NPM package authors: use pkg.module!

For a long time, using JavaScript libraries was a bit of a trick because you and the library author might not be using the same module system, so you and the library author had to agree on which module system to use. For example, suppose you use the Browserify packaging tool, but the library author prefers the AMD module system, so before you build, you have to replace the library author’s module system with your own project’s module system. Although the common Module Definition (UMD) format type is fixed, because it is not enforced anywhere, you never know which module system you will use next.

ES2015 changes all that, because import and export are part of the JavaScript language. In the future, there will be no ambiguity and modular systems will connect more seamlessly. Unfortunately, since browsers (most) and Node don’t support import and export, we still need the UMD module system transition (if you’re building files for Node only, you might want to consider CommonJS).

You can serve both UMD and ES2015 by adding the “module”: “dist/my-library.es.js” entry option to your project’s package.json file (aka PKG.module). This is important because both Webpack and Rollup can use pkG. module to build as efficient code as possible – in some cases, both Webpack and Rollup can even take advantage of the tree-shake feature to weed out unused code in a project.

To learn more about pkg.module, check out the Rollup Wiki.

Hopefully, this article has made the relationship between the two packaging tools clearer. If you still have questions, you can find us on these Twitter accounts: Rich_Harris, rollupjs, thelarkinn. Let’s pack happily together!