Hello, everybody! 🚀
For the last few days, I've been doing some research on the currently available JavaScript bundlers to try to draw my own conclusions about them and figure out which one would be more appropriate for my projects. And, of course, to find out if it's all about popularity and we developers are overrating some of them and underrating the others 😇
Since the only bundler I've been working with for the last few years is Webpack, I decided to take a look at npm trends to find out which the most popular JS bundlers are in 2021 and give them a try.
And this is what I got:
So today, we'll be making a comparison between the 5 most popular bundlers according to npm trends: Webpack, Rollup, Browserify, ESbuild and Parcel.
In this comparative, we will create a really basic scenario for each of them with a couple of the most used resources/tools these days, and we'll be talking about their pros and cons and comparing them all based on a few parameters.
First things first. What is a bundler? 🤔
A bundler is a tool that puts together all your JavaScript code and its dependencies and throws a new JavaScript output file with everything merged, ready for the web, commonly known as the bundle file.
These bundlers can work with other types of files as well apart from JavaScript, but they need a little help to perform their bundles. We'll talk about this more in depth in each of the examples below.
None of them require a config file, what perfectly works for the most basic bundle. This means you have a .js file converted into another .js file with minimal setup. But, once you start having more and more kinds of files that need to be transpiled and, consequently, configured, it's time to add a config file because, otherwise, you'll find yourself immersed in chaos 😰
The scenario 🖥
To try out these bundlers, we don't need a specific complex structure for our project, so let's propose a really basic scenario: an HTML file, with some styles (we'll slightly complicate it by using a preprocessor like SASS) and ready to use ES6, which means we will include Babel even though we're not using React, Vue or any library/framework that rely on it in this comparative. But let's get it setup anyway.
/dist
bundle.js
[styles.css]
/src
index.js
/styles
styles.scss
index.html
package.json
[*.config.js]
/dist will be the folder created after the bundle process and will contain all the bundled files. The bundled file for the styles is optional because we can choose either to inject the styles directly in the HTML or generate a new transpiled file containing the styles.
/src is the folder containing the entry point from which the bundler will start the bundle process.
/styles is the folder containing the original styles file, before the bundle.
index.html is the file containing what we'll see in the browser.
package.json is the file where all the dependencies, scripts and some configurations are stored.
*.config.js is the file where all the config for the bundler is defined. This file is optional for every bundler in this list, but highly recommended. * will be replaced accordingly by the name of the bundler.
Having said all this, let's see what each of these 5 bundlers can offer us.
1. Webpack
Loved by many, hated by some, known to all. And still the most popular bundler in 2021. With more than 15 million weekly downloads (at the time of writing this post), there's no doubt that Webpack is still the bundler par excellence in 2021. But, is it the easiest to use, configure and understand how it works?
Let's have a look at how we should configure it to have it ready to work.
Approach used by Webpack
- A build script
- A config file
- Loaders used to transform files
- Plugins for more complex stuff
package.json
...
"scripts": {
"build": "rm -rf dist && webpack --mode development"
}
...
Really really easy. There's no need to do anything else for a basic configuration. Actually, if you don't want to use a different name for your configuration file, you don't even need to specify a configuration in the build script. If you want to use a different one, you should add --config your_config_file.js to the command.
Note that we'll be adding the command rm -rf dist to every build of every bundler. What this does is removing the dist folder every time a new build script is executed.
webpack.config.js
module.exports = {
entry: "./src/index.js",
output: {
filename: "bundle.js",
path: path.resolve("dist")
},
module: {
rules: [
{
test: /\.(js|jsx)$/,
exclude: "/node-modules/",
use: "babel-loader"
},
{
test: /\.html$/,
use: "html-loader"
},
{
test: /\.(scss|sass)$/,
use: ["style-loader", "css-loader", "sass-loader"]
}
]
}
}
Maybe a little bit more tricky and difficult to understand at first than the other bundlers, but really easy once you get the sense of how everything works together.
What is happening in this config file? 🙃
Well, first, we need an entry point for our bundler to start merging everything. That is specified in the entry attribute and the file will be our file index.js in the folder src.
Same for the output file, we'll tell Webpack our file will be called bundle.js and it should be stored in the folder dist.
And now, what's only left is to handle the files that are not JavaScript (ES5). Webpack takes care of these files using loaders. To transform these files, we just need to indicate the file format and which loader(s) will deal with them.
So that's what we need: a few loaders to take care of our styles, our HTML and our JS (ES6 - remember that we're getting it ready for formats like .jsx): style-loader, css-loader and sass-loader for the styles, html-loader for the HTML files and babel-loader for ES6.
Notice that we're also transforming the HTML file (this loader will be useful if we want to add resources that are loaded directly in the HTML file, such as images). This loader is really useful in bigger projects, but not necessary in this case (due to its simple structure), we'll skip this step for the rest of the bundlers.
And this is it. Everything will be bundled once we run the build command.
About the bundle
Since we're using style-loader to bundle the styles, instead of a plugin to minify CSS and generate a new file (MiniCSSExtractPlugin), the styles are injected into the HTML file inside a <script> tag, so the only output file is bundle.js, which needs to be added to index.html.
What do I think about Webpack? 👇
I have to admit that first time I had to face Webpack I thought the configuration would be impossible. It was my first time using a bundler and I was barely able to understand the overall concept. Let alone all the loaders and more complex related stuff because it was a bigger project.
But after a few from-scratch configurations on my part, I have to say that now I find it more intuitive and easier to set up if I compare it to what it felt like to get to know the rest of them.
Let's take a look at the others and you'll understand why!
2. Rollup
Let's now turn our attention to Rollup. As well as the rest of the loaders, this has been my first time trying it out, so I'll also provide my first impressions about it 🤓
Approach used by Rollup
- A build command.
- An optional config file.
- Plugins used to transform files
package.json
Basic bundle with no config file:
...
"scripts": {
"build": "rm -rf dist && rollup src/index.js --file dist/bundle.js"
}
...
Using a config file:
...
"scripts": {
"build": "rm -rf dist && rollup -c"
}
...
A really easy command for building, as well, so nothing else to point out here.
Let's now check the config file, that is optional but recommended.
rollup.config.js
import babel from "@rollup/plugin-babel";
import scss from "rollup-plugin-scss";
export default {
input: "./src/index.js",
output: {
file: "./dist/bundle.js",
format: "cjs",
},
plugins: [
babel({ exclude: "node_modules/**" }),
scss({ output: "styles.css" }),
]
}
What Webpack defines as loaders, here in Rollup are called just plugins. This time we just need a couple of them: the one for transpiling ES6 into ES5 (Babel) and the one for SCSS: @rollup/plugin-babel and rollup-plugin-scss.
These plugins have also their own optional configuration. In this case, for Babel, we're excluding the folder node_modules and for SCSS we're giving the output file a different name. Otherwise, it will remain output.css.
For configurations with plain CSS, there's a plugin called rollup-plugin-css-only that works in the exact same way as the plugin we're using for SCSS.
Note that we need to specify the entry and the output points exactly as we did before with Webpack.
And that would be it.
About the bundle
The Rollup bundle comprises two files: bundle.js and styles.css. It's necessary to import the original styles files in the entry point index.js for the bundler to be able to find the file (there's no other place where we can reference it).
Also both bundles need to be added to the HTML index file.
My first impressions about Rollup 👇
To be honest, I wasn't expecting much of these other easier slash light-weight bundlers since Webpack has always worked for me, and I have to say that Rollup has surprised me in a good way.
I find it pretty similar with Webpack (config file with almost the same structure, plugins work in the same way as loaders to translate no-js files, the easy build command...), which means familiarity, usage recall and, consequently, ease of use.
The only drawback I've been able to find so far is the large number of dependencies it relies on, and consequently, the huge size of the project (3x a project bundled with Webpack). We'll be focusing on this more in depth at the end of the post 🔜
3. Browserify
Let's now talk about Browserify.
Approach used by Browserify
- No config file
- Transforms used to transform files
- Everything you need to configure ->
package.json
The method used by Browserify has nothing to do with the traditional approach of a build command and a config file. With this bundler, every possible configuration is allocated in package.json and the build command can get a little bit tedious if we don't have the concepts clear.
It also needs plugins (or transforms, as they are also called) to transform everything into something readable by the browser.
Let's have a glance at how we can configure it:
package.json
...
"scripts": {
"build": "rm -rf dist && browserify -o dist/bundle.js src/index.js"
}
...
A very basic use of this bundler could be something like the code snippet above. We only have defined the input and output files (no configuration for styles or anything more complex).
Note the length of the build command having only declared the input source and the output.
Let me show you how it would look like if we add the suitable plugin for handling plain CSS.
...
"scripts": {
"build": "rm -rf dist && browserify -t [browserify-css --output dist/styles.css] -o dist/bundle.js src/index.js"
}
...
Then, if we wanted to add some configuration to the plugin, we would do something like the following down below in the same file:
...
"browserify": {
"browserify-css": {
"autoInject": true,
"minify": true,
"rootDir": "."
}
}
...
It starts getting not that maintainable.
And now, let's complicate it a little bit more by adding plugins for SCSS and Babel. We need a couple of plugins called Babelify and scssify.
Something to take into account
I've been trying out this bundler with the last released version of Node (v16.4.2) and the command line throws multiple errors when trying to install any dependencies that rely on
node-sass(scssifyandsassify, more specifically). A very negative point.
We could do this in two different ways:
- By saturating the build script with more content 😅
- By adding a transform property
Via the build script
For specifying several transforms in the build script using Browserify, we should add as many as -t [ transform options ] as needed, like this:
...
"scripts": {
"build": "rm -rf dist && browserify -t [ scssify --output dist/styles.css ] -t [ babelify --presets [ @babel/preset-env ] ] -o dist/bundle.js src/index.js"
}
...
If you're using this method, pay close attention to the white spaces inside the arrays. They matter ✌️
I find this method tedious and difficult to understand, and above all, difficult to maintain. And we're only using two plugins. All said.
Via the transform property
...
"browserify": {
"transform": [
[ "babelify", {
"presets": [
"@babel/preset-env"
]
}
],
[ "scssify", { "autoInject": true } ]
]
}
...
By using this method, the build script will look like it was originally, when it just performed the simple bundle of the input js file:
...
"scripts": {
"build": "rm -rf dist && browserify -o dist/bundle.js src/index.js"
}
...
Much better 😊
About the bundle
The Browserify bundle consists of the bundle.js file and, only if we set an output file for the styles in the plugin that takes care of them, we'll get a styles.css file. Otherwise, the styles will be injected at the bottom of the <head> element in the HTML file inside a <script> element.
Take a look at this two different config examples for browserify-css:
...
[ "browserify-css", {
"autoInject": false,
"minify": true,
"rootDir": ".",
"output": "dist/styles.css"
}
]
...
This config above will create a separate .css file.
...
[ "browserify-css", {
"autoInject": true,
"minify": true,
"rootDir": "."
}
]
...
And this other config will inject the code into a <script> tag in the head of index.html.
My first impressions about Browserify 👇
My less favorite so far. I don't find it as intuitive as the other two, and the approach it uses is totally different from what we are regularly used to. Also, I think the configuration is more tedious if at first you don't know how and where to handle the required plugins.
Also, blank spaces matter, and if you don't know that beforehand, you can perfectly spend 2 hours trying to figure out what's wrong with your code 👎
4. ESBuild
Time to talk about ESBuild.
Approach used by ESBuild
- A build command (encourages the use of the terminal)
- An optional config file
- Plugins used to transform files
With ESBuild you can use either the command line or a config file as well as the others, even for more complex configurations. It's totally up to you, but specifying a config file is always recommended for maintainability, scalability, readability and productivity reasons.
We're going to create a config file called esbuild.config.js and we'll execute it from the build script by running the command node.
But first, let's have a look at the simplest way to start bundling our files with ESBuild (no config file is required this time):
package.json
...
"scripts": {
"build": "rm -rf dist && esbuild --bundle src/index.js --outfile=dist/bundle.js"
}
...
As usual, we declare the entry point and the output file. And that's it. But what happens when we need to keep bundling more different kind of files?
Let's then take a look at the following example:
...
"scripts": {
"build": "rm -rf dist && esbuild --bundle src/index.js --outfile=dist/bundle.js && esbuild --bundle styles/styles.css --outfile=dist/bundle.css"
}
...
We are now bundling the styles as well, and adding a little more information to the build script (mess alert again!) by defining two different bundlers. We could (and definitely will) have more filetypes that would need to get bundled and this could become a total mess.
So, let's put aside this approach and let's create a config file.
esbuild.config.js
import esbuild from 'esbuild';
import { sassPlugin } from "esbuild-sass-plugin";
import babel from 'esbuild-plugin-babel';
esbuild.build({
entryPoints: ['src/index.js'],
bundle: true,
outfile: 'dist/bundle.js',
plugins: [sassPlugin(), babel()],
}).catch(() => process.exit(1));
And here comes what I found (let me say) weird and what took me some time to figure out.
Maybe because I was expecting to run this config file in the same way as Webpack and Rollup do (they run their config file by default if it exists and has the default name), I had some trouble trying to tell ESBuild to take it as an input for configuration.
Finally, I realized that it should be called via the node command to just run the script 😬
"scripts": {
"build": "rm -rf dist && node esbuild.config.js"
}
And that was all.
Something I want to mention here is that, the fact that there aren't so many plugins from where to pick and also most of them are way outdated, doesn't make me particularly happy. And, if you allow me some advice, try to pick plugins which use either CommonJS (which inserts modules through require) or ES Modules (which does the same using import), because if you mix them up... the only things you'll get will be errors and mess everywhere! 😖
Just make sure you change the type attribute in package.json if you're using ES Modules (import) to load your plugins into the config file:
...
"type": "module"
...
Practically all plugins have been created by the community (if not all). For this example, I've chosen esbuild-sass-plugin for SASS/SCSS and esbuild-plugin-babel for Babel. Both of them work with import, so no extra problems.
A great point to mention: ESBuild is really fast compared with the others. At least in this scenario.
My first impressions about ESBuild 👇
Mixed emotions. At first, I thought it would be very easy to configure (it is if you only intend to perform a regular bundle) but then I started to struggle a bit with the config file, not because of the syntax but because of the multiple errors thrown on the terminal regarding Node.
5. Parcel
Let's now have a look at the last bundler in this list: the famous Parcel. Hi to the huge community of Parcel fans out there 👋
Approach used by Parcel
The Parcel approach is mainly based on a zero configuration environment 😱 I was reluctant to believe it at first (that's the main reason why I wanted to try it out so bad), but, yes, it's possible to bundle a project like the one we're testing in this post by writing the bare minimum configuration, in a few minutes and without racking your brains 🙌
Zero configuration? Are you sure? 😪
By zero they mean very little and precise. Let me show you the configuration I used for this basic project:
package.json
...
"scripts": {
"build": "rm -rf dist && rm -rf && parcel build src/index.js --no-scope-hoist --no-source-maps"
}
...
The procedure is pretty much the same: we need to indicate where the entry point for our app is located. And I also added the flags --no-scope-hoist to avoid odd behaviors regarding require when running js scripts and --no-source-maps to avoid the creation of sourcemaps. Otherwise, Parcel will create one for every bundle file by default.
Now, if we want to change the location and the name of the output bundle file, we need to change the value of the main property attribute in package.json, like this:
...
"main": "dist/bundle.js"
...
Otherwise, the bundle will be generated at root level and will be called with the name that is stored in main, in most cases index.js (if we didn't change it when running npm init).
Now, let's (zero)configure the styles and Babel
Since we're using SCSS, we need to use SASS as a preprocessor. So, what was my surprise when I read that SASS is already included with Parcel installation. But not only SASS, also LESS, Stylus, and... Babel! 😧
So the only step to take here is to create a couple of config files for SASS and Babel.
Our SASS config file will be named .sassrc and will contain the following code inside:
{
"includePaths": ["node_modules"]
}
And when we run the build command, Parcel will automatically install the plugin @parcel/transformer-sass as a dependency and will create a bundle.css file in the same specified directory for the bundle, and that's all the configuration. Pretty cool, right?
Now don't forget to link this file to your HTML 🤗 And remember that your .scss file should has been previously imported on your entry point file in order for the bundler to know what file it has to transform.
On Babel side, we need to create a .babelrcconfig file to specify the needed presets (let's say we want to get it ready for using React in the future):
{
"presets": ["@babel/preset-env", "@babel/preset-react"]
}
Parcel will automatically call @parcel/transformer-babel and will do the job for us.
Don't forget to previously install @babel/preset-env, @babel/preset-react and all the dependencies needed by React.
And that's... it. We're all set and ready to rock 😁
My first impressions about Parcel 👇
The first thing I want to point out is that Parcel wasn't that easy for me at the beginning since I had a really (really) hard time trying to get it ready to work, and it seemed like it wouldn't stop throwing errors regarding the OS and creating more trouble out of outdated versions of some dependencies 😥 So, to be honest, Parcel wasn't going to be in this list because I didn't want to talk about it if I couldn't try it out myself.
But, magically ✨ (and due to my tireless perseverance 😅), I finally could make it and set everything up to get it ready 🙌
And after that, it was really easy compared to the rest of the bundlers. So let's draw a veil over the setbacks and let's give it a chance.
Parcel is also pretty fast, because it uses cache.
But... something I don't like at all is the several security vulnerabilities that appear after installing it (around 12, some of them high risk) 😖 That doesn't speak well of you, Parcel. Not to mention the huge size of the project. The heaviest in this comparative.
The comparison 📈
Here you have the highlights of this comparative summed up in a table:
What is my final verdict? 😼
Well, I think some of these other bundlers apart from Webpack can be cool to use for small or side projects, but in reality, I personally think that Webpack is still the best option for robust projects (we just have to look at the huge number of downloads per week compared to the rest).
Also, I find it the easiest to manage since once you get the sense of how it deals with configuration, it's easier to keep adding values to that configuration. But it's not something that obvious. You have to take your time playing with it to get a very basic idea at first.
Moreover, you have the majority of resources you need (loaders, plugins...) available from the creators, so you make sure you're using a real source of truth. And they are updated really frequently, so you can use it without worry with newer versions of Node and other packages.
So, yes, I will keep choosing Webpack as my first option over the others.
My second choice would be Rollup for sure, and I truly think I will definitely use it in some of my side projects since I found it intuitive to configure and it seems like it works properly on robust projects as well.
And about their plugins, most of them are also available from the creators, so, again, a real source of truth and many more advantages.
I also think Parcel is a very interesting option and I'd like to try it with larger projects and check if it really doesn't need further configuration. Definitely a great find.
And a big plus to the fact that plugins like Babel, SASS, LESS and some more are built-in and ready to use out of the box.
What about Browserify and ESBuild?
These two have been the ones with which I have struggled more, especially Browserify. The fact that it doesn't require a config file and everything should be declared in package.json kinda forces you to change the way you think of how bundlers are traditionally configured. Not to mention you end up saturating the file with way a lot tricky configurations, which makes it difficult to read and maintain.
Also, when it comes to plugins, most of them are not developed and maintained by the creators (especially the most common) and are really outdated (many of them haven't been updated in the last 4 years) and this fact leads to problems with newer Node/other packages versions and compatibility in general.
And on ESBuild side, I didn't especially like it either. The first impression was good but then, since the config file caused me some trouble, it mainly ended up in confusion about how to manage configuration with and without this file. So I found it quite ambiguous and took me a bit to realize how to set up both scenarios in different ways.
About their plugins, same as Browserify, practically all of them has been created by the community, not the author, so you have to use them at your own risk. But as a plus point, they are often updated and maintained.
Now it's your turn! 🔥
What do you think of this comparative? Do you agree? Which one is your preferred bundler? Do you know some other bundler that is not on the list? Would you like to suggest different bundlers for future comparative posts? Comment below!
Disclaimer 👇
Remember this is just a post showing my impressions about something I tried for the first time. I have decided to share the process with you and my opinion about what I experienced. The opinions expressed in this post don't mean that some bundlers are better over others. My advice is to try them all out and draw your own conclusions, like I did. And based on that, use the ones you like best and fit your needs.
🎉 Don't forget to follow @underscorecode on Instagram and Twitter for more daily webdev content 🖥🖤
And last but not least... A quick friendly reminder before we go 😊
We all know there are million ways to get things done when it comes to programming and development, and we're here to help and learn, so, if you know another possible way to do what others are sharing (not better, not worse, just different), feel free to share it if you feel like it, but, please, always be kind and respectful with the author and the rest of the community. Thank you and happy coding!
Top comments (32)
I suggest taking a look at Moiva.io (I'm the author) to compare the libraries using different metrics moiva.io/?npm=rollup+snowpack+vite...
Great article!
I think Parcel would be a good choice after beta 3.
They use swc, a JavaScript compiler written in Rust to replace Babel, it really saves my day to deal with Typescript + Jest + ES Modules.
It's a huge pain to configure in Babel.
Thanks for your feedback!
Use vite. Problem solved.
Fast like really fast , built on top of esbuild, extremely diverse plugin system. Good typed APIs. Really good
Good reasons to give Vite a try. Thanks for your comment!
It's really good that you didn't mention vite in this article as vite is not a bundler. It's a build tool and I'd love to see another informative article after you try vite. Thanks
On spa projects I personally prefer es-based bundlers (I use vitejs). But if the project is large and non-monorepo -- webpack. More options, more plugins. And the killer feature -- module federation.
So webpack still dominating, despite the fact that it bundles projects as slow as a snail 😒
I've heard good about Vite, so I guess it won't be long until I try it out. And I think the same about Webpack, still the best for large (and many times overloaded) projects.
Thanks for your comment!
Yeah... Among the cool kids Vite is the new hotness. Def should add to the above. Maybe snowpack too?
How about snowpack?
It was next on the list 👌 And it'll be in the next comparative for sure! Thanks for your suggestion.
you can learn usage is not now. I think if we use with deno it's the awesome bundler.
"Update (April 20, 2022): Snowpack is no longer actively maintained and is not recommended for new projects." Source
There is the tooling report from April 2021.
webpack is deeply embedded in the React and Vue ecosystems so it's not going anywhere.
That said when Google DevRels shy away from writing plugins for webpack one has to wonder (i.e. if you need to write you own plugins Rollup may be the better choice).
microbundle by Jason Miller is based on Rollup and he has worked with webpack extensively!
Apart form the sheer speed there are other reasons to keep an eye on esbuild (though a proliferation of JavaScript rather than Go plugins might kill it's speed);
Not sure what's going on with Packem. Given Rust's position in the WebAssembly space (minimal runtime size, similar to C) it may be a good companion language for the tooling ecosystem (swc; Writing JavaScript tools in other languages – a new trend?).
This could be nice as a post series grouped under a title, as it's currently hard to jump to sections.
I have quickstarts here comparing a few options including working with TS and React where a bundler/transposer is necessary
github.com/MichaelCurrin/javascrip...
I'm a fan of esbuild as well as it is supposed to be several times faster then alternatives, it supports esmodules i.e.
import from ...and it is zero config so you can use it from the command line for any project.npx esbuild ...michaelcurrin.github.io/dev-cheats...
I’ve found the development flow is really really good with Vite. I’ve been using it with SvelteKit and it makes me wish other frameworks grab it by default as well.
I'll be definitely trying Vite soon since I only read good reviews about it. Thanks for your suggestion!
So much I love this summary and style of writing giving POV and yet putting things in a table at the end and separating pros and cons, this is cool style of writing and pretty helpful. Thanks a lot for the time. 💪
Great technical analysis. Keep at it ;)
This was a great article, and I really appreciate you posting it, thanks!
You covered enough functionality to get a good idea about each bundler, and you stated your biases up front even as you did a good job of trying to set them aside for the review.
I'm just about to set up a new project and thought I'd see if rollup was worth exploring (over webpack). The one thing I'm most interested besides what you covered is how easy it is to use typescript sources.
Thanks for this article, I'm curious about esbuild will be the next trend or not cause of using by Vite (Next Generation Frontend Tooling) for pre-bundles and as we know, esbuild written in Go that take effect 10-100x faster than JavaScript-based bundlers.
The part about Rollup looks way too optimistic. In real life you need a lot of configuration to allow Rollup work with CJS modules.
For example, when working with React you have to manually declare every imported name in configuration file. That's not super convenient.
So good to know. I've tried Rollup with a very simple example, just to start off with it, but I guess trouble comes with more complex scenarios. Thanks for pointing that out.
Great comparison. Do you by any chance know which are the ones dealing nicely with code splitting?
I'm afraid to move away from webpack and lack this functionality.
It seems like Webpack and Browserify are still the best in handling code splitting, but Parcel and Rollup are able to handle it as well. As for ESBuild, this feature is still in progress.
Thank you very much that is a clear answer.
This article is really interesting don't you think