Module bundlers pick up and compile small pieces of code into a larger “package”—generally on behalf of a library or an application.

The two bundlers I want to discuss below are Webpack and Rollup, specifically in regard to the frontend development process. They’re among the most popular bundling tools on the market, and I’m currently using both in my day-to-day work at Sensible.

With the hope of clarifying the distinctions between Rollup and Webpack for your own use, I’ve shared my experience with each below!

Roll it or pack it?

First, when speaking about any technical topic, I think it’s best to make sure that everyone gets on the same page from the beginning. Perhaps the best place to start would be to demystify the term “bundler” in the context we are going to be using it.

In the past, websites and applications were built simply by using HTML, CSS, and JavaScript. The “bundling” process was managed manually by injecting scripts into HTML files in the correct order, and as a result the code was scoped and rigid.

An alternative was to combine all the scripts into one large file—but this presented the problem of managing the repetitive names of functions and variables, especially when multiple engineers were working on different pieces of code. Considering all the potential libraries and frameworks you might be using to support an application—as well as any third-party dependencies—the complexity starts to get unwieldy.

Consequently, the case for streamlining this process became clear in 2014 when Webpack published its initial release.

Webpack essentials

Webpack is a free, open-source module bundler. It’s the original tool for bundling.

While it was primarily designed for JavaScript, Webpack also has the power to transform other frontend assets such as HTML, CSS, fonts, and images into static assets. The content is then served to the browser.

Webpack builds the dependency graph from the specified entry point(s), and proceeds to compile each module (file) of your existing project into a bundle. Webpack supports ECMAScript, CommonJS, AMD, WebAssembly, and Assets.

Beyond establishing the niche for bundling tools, it seems that one of the prevailing opinions about Webpack is that it’s overloaded with a multitude of features, and can thus become cumbersome and unintuitive for users. This is up for debate, but one of the things I’ve found to be true in my own use of Webpack is that—because of all the defaults—it can be tricky to achieve customization. You’re required to override Webpack’s many defaults, which may in some cases lead to exposing your code to errors or incompatibility issues.

Webpack is supercharged with customization options which can be defined inside of the configuration file: webpack.config.js. However, since the product’s 4.0.0 release, Webpack no longer requires a config file to bundle modules. So even if you’re not planning on customizing anything in your project, I'd still suggest checking the default configuration settings.

If you’re working with a frontend library like React (and building from create-react-app), then you’re likely to have Webpack preconfigured by default. If you do need to change/customize any settings, you can find your webpack.config.js in a root directory of node_modules and determine what will work best.

Remember that these configurations come as part of React scripts. I wouldn’t recommend changing them before ejecting the entire Webpack from the scripts, and separating it from the framework. Before you take this approach, it’s worth considering that after ejecting you will be on your own and will have to manually maintain all the updates, settings, and required configurations.

Rollup Essentials

Rollup is another bundler for JavaScript which compiles small pieces of code into one larger file to be shipped for production. It’s a more lightweight, flexible module bundler overall. 

For years, Webpack was the undisputed bundling champion—thanks to its robustness, history, and reliability. Today, the differences between various bundlers are narrowing, and the usage of one over another is becoming more a matter of preference than necessity.

In my opinion, one of the most important advantages of Rollup is its use of the new standardized format for code modules, ES6, instead of previous idiosyncratic solutions such as CommonJS and AMD.

Rollup focuses on creating small builds by eliminating dead code (tree-shaking) which allows you to continue building on top of existing tools and modules without adding extra dependencies or exponentially increasing the size of your application. 

The differences between Rollup and Webpack stand out immediately when you take a look at the configuration file, and the use of loaders and plugins. While Webpack has a myriad of loaders to help translate CSS, sass, and other non-JS files into JavaScript, Rollup uses plugins. Each plugin is an object that is returned via a function call, and allows you to customize Rollup behavior prior to code bundling.

‍A list of various Rollup plugins can be found here. I found Rollup’s plugins for SCSS and postcss among the most useful for our components library and assets.

It’s important to note that there are two features that Rollup is not supporting readily out of the box, which require additional plugins and a bit of a workaround. These are the Development Server and Hot Module Replacement (the second of which isn't supported at all). 

Development Servers are designed to enable the development and testing of programs, websites, software, or applications for programmers. It provides a run-time environment, along with the hardware/software infrastructure to develop and debug on the fly.

To support this piece of functionality (which is natively supported in Webpack), Rollup requires at least two plugins (​​rollup-plugin-serve and rollup-plugin-livereload). Like with Webpack, many custom configurations are also possible. 

Futuristic bundling

With all that said, there’s yet another type of bundler that’s worth mentioning: Vite

It’s a relatively new (Feb. 2021) frontend tool that aims to provide a faster development experience for modern web projects.

To list a few exciting features of Vite: 

• The module pre-building process is performed in esbuild, which makes Vite's start time significantly faster than any JavaScript-based bundler—and guarantees extremely fast Hot Module Replacement.
• A build command that bundles your code with Rollup, and also extends Rollup's well-designed plugin interface with a few extra Vite-specific options. As a result, you can write a Vite plugin once and have it work for both dev and build.
• Preconfigured support for CSS @import inlining via postcss-import. Additionally, Vite provides built-in support for .scss and .sass files. There’s no need to install Vite-specific plugins, except for the corresponding pre-processor itself.
• .ts and .tsx support out-of-the-box, where transpilation is also handled via esbuild.
• Lastly, Vite is framework-agnostic, which means that in the future it won’t be a blocker if your tech stack changes or if you are worrying about present compatibility in order to implement this new transition.

Sensible’s use of bundlers

I bring up Vite purely as an exploration of future possibilities.

At Sensible, our app is pretty complex and is constantly growing in terms of infrastructure. We have found Webpack to be useful in bundling apps, but we also have standalone assets and a component library that technically live outside of the main application. That’s where Rollup is helpful for us, too.

I’d like to note that the tool choices of our developers aren’t rules to live by. Most of the time, it simply depends on the best solution to a current problem, and the skills of the team or individual developers. 

This is especially true when it comes to module bundlers!