Parcel vs. WebPack 2021

Selecting the right bundler for your frontend

If you are a frontend developer, you may be familiar with WebPack as a bundler for your project. Most developers and teams use WebPack as their primary JavaScript bundler. I used WebPack in most of my projects too. However, once I came across Parcel, I took the liberty of testing it out.

In this article, I will share my experience of using Parcel and compare it with WebPack.

Before we dive in, let me give a small spoiler about why Parcel was attractive to me.

Parcel requires zero configurations to get it up and running as opposed to other bundlers which need a lot of configuration setup.

Isn’t that a good reason to start exploring this bundler? 😃

Zero configuration setup

Most of us are used to generating our React project using Create React App (CRA). This is the easiest way to set up a React project without much manual configuration setup. However, the problem is, CRA hides the WebPack configurations within it. Therefore, if you need to customize your bundling configs or if you need more advanced features, you need to set up WebPack manually anyway.

There are instances where I have spent days configuring and optimizing the bundle of a project. The most basic WebPack configuration would look as follows.

const webpack = require('webpack');
const path = require('path');

const config = {
    entry: './src/app.js',
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: 'bundle.js'
    },
    module: {
        rules: [
            {
                test: /\.(js|jsx)$/,
                exclude: /node_modules/,
                use: 'babel-loader'
            }
        ]
    }
};
module.exports = config;

This can be extended as required based on the configurations you need. The WebPack script to start the project needs to be added to the package.json .

Point to note:

With the latest release of WebPack (version 5), you can use WebPack with zero configurations as well. It will assume your project entry point is src/index.js and output the bundle to dist/main.js minified and optimized for production.

However, in most scenarios, if you are using WebPack, you will have to extend the default configuration to suit your needs. Therefore, a WebPack configuration file will be essential for large-scale projects.

Now let’s look at what’s required to get Parcel up and running.

The only requirement to bundle and run your project with Parcel is to add this script to your package.json

"scripts": {
  "start": "parcel index.html",
}

Your application scripts should be included in the HTML file and Parcel watches this HTML file to do its job right. It can also watch a JavaScript file instead of an HTML file too.

Just one line! Isn’t that awesome? 😃

Dependencies and pre-processors

Parcel requires no configuration to handle pre-processors and dependencies, unlike WebPack. Parcel handles it automatically and will be installed with no manual effort.

This is hassle-free as you don’t need to mess with pre-processor versions, including them in config files, etc.

Parcel makes managing dependencies and pre-processors nice and easy for you. So far, Parcel seems to be the winner. But don’t get too excited. WebPack is famous for many reasons.

In fact, Parcel has a few problems on its own too. We’ll talk about those as we progress in this article.

Code Splitting

Parcel is known for code splitting support and dynamic imports. Yes, it does and it works as expected. However, there are a few downsides with Parcel when it comes to code splitting.

In Parcel, the bundled folder has a flat structure. Therefore, it will not include your images, CSS, JS separately in the bundled folder. Everything will be together. In my opinion, this looks a bit messy as it is hard to find a bundled file quickly. Even the index.html will be squeezed in together with the rest of the files.

Opposed to that, WebPack will have a clean structure in the bundled folder where you can identify images, CSS files, JS files, etc. separately.

Speed of bundling

When you bundle your application initially, usually Parcel takes a considerable amount of time compared to WebPack. WebPack is faster. However, in subsequent builds (when you are watching and building), Parcel is much faster.

Besides, I rarely experienced long build times with Parcel after the initial build. This is very useful for developers as it improves the quality of development and saves a significant amount of time.

Parcel also has a,

Hot Module Replacement to update elements without a page refresh during development.

Further, it has a “Production Mode” that speeds up the build by preventing unnecessary build steps.

Third-Party Tools Using these Bundlers

Customization with Parcel is very minimal, where many Third-Party tools couldn’t use it. However, WebPack remains the king of customization to date and many Third-Party tools as their go-to bundler technology. Below, tools use WebPack internally as the default bundler.

Gatsby — Is a site generator based on React that lets you create highly optimized websites that we can serve through CDNs. It uses WebPack as the default bundler and allows you to customize some of its configuration, such as code splitting.

Bit — Is is an open-source tool that lets you create truly modular applications with independently authored, versioned, and maintained components. Bit uses WebPack to bundle the isolated components and uses the module federation feature for runtime integrations for Microfrontends.

Angular/React/VueJS — The most popular front-end frameworks and libraries come with default WebPack configuration and extend depending on the need.

Summary

As you can see, WebPack is still leading as the most popular bundler out there and continuously do so for the foreseeable future.

Source: NPM Trends

However, in my opinion, Parcel is a good bundler for small-scale applications. It worked well for me. However, there are few things to note.

But using Parcel v1 in your applications is a bit risky. This version had issues when installing dependencies, and they had to be mitigated by adding flags to the build script.

However, an improved new version of Parcel (v2) is out now and most of the previous issues have been fixed in this. You can refer to the Parcel v2 documentation here.

If your application is enterprise-grade, I feel like it is not safer to migrate to Parcel so far as it might limit your options despite the attractive features Parcel possess. Therefore, it is better to stick with WebPack.

Webpack 5 Vs. Parcel v2

Let me know your thoughts about Parcel too. Thanks for reading!