Ndeye Fatou Diop

Posted on Feb 24 • Originally published at frontendjoy.com

✨ Module Bundlers, Demystified: What You Actually Need to Know

#frontend #webdev #javascript #bundler

When I first heard module bundler as a front-end developer, I thought, “What is that magic again?” 😅

I remember trying to read about them or even use one, but I didn’t see the usefulness.

All I knew was that every article recommended using module bundlers like Webpack—and setting them up was hell 🔥.

I later realized that they’re one of the most crucial parts of modern frontend development, and you absolutely need to understand them.

In this post, I’ll share what I wish I had known about module bundlers.

Let’s get started. 🚀

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

First, what do module bundlers do?

Let’s start with an example.

For this post, I made a React app called demo_bundling_esbuild (Github code).

It’s a simple app that displays my name, age, and other personal information. (I know it's it's a bit self-centered 😅)

It uses esbuild as a module bundler and is structured like this:

project/
├── src/
│   ├── App.tsx
│   ├── index.tsx
│   ├── data.json
│   ├── utils.ts
│   └── constants.ts
├── index.html
├── build.js
└── package.json

Once I finished development, I needed to build the app so I could have an index.html file to load in the browser.

This is roughly what the app looks like:

But then something interesting happens...

When I open my Network tab, I don’t see the same files as in my code editor.

I can see the index.html file, but where are App.tsx, index.tsx, and constants.ts? 🤷‍♀️

Instead, I see a single file: dist/bundle.js.

When I open it (see in this gif link), I find the content of App.tsx, index.tsx, and utils.ts—but in a weird/minified format.

So, what happened?

How did I go from 5 files (index.tsx, utils.ts, constants.ts, App.tsx, data.json) to 1 file (dist/bundle.js)?

How did all these files turn into a single big file?

👉 Bundling happened.

My module bundler (esbuild) took all the .ts and .json files and compiled them into one file: dist/bundle.js.

PS: You can find the configuration here 👉 build.js.

In summary:

Module bundlers are tools that combine multiple files in your codebase into fewer files.

And this is amazing for several reasons.

Why bundling is important

Benefit #1. It ensures your dependencies load in the correct order

If you’re using dependencies (i.e., npm packages), you probably import them like this:

import { partition } from "lodash-es";
import { v4 as uuidv4 } from 'uuid';

In the past, these imports didn’t work in all browsers.

Module bundlers solve this by ensuring that dependencies load correctly.

For example, if File A depends on File B, which depends on File C, the bundler makes sure all necessary files are present before execution.

Benefit #2. It reduces the number of HTTP requests

Without bundling, every file would need to be loaded separately.

Browsers limit the number of parallel network requests, so for large apps, this could mean waiting minutes (or even hours) just for files to download and parse.

Bundlers reduce the number of files (usually 1–2 for small apps), significantly speeding up the loading process.

Benefit #3. It optimizes the size of your files

Before bundling your files, module bundlers apply optimizations to make them as small as possible.

Some of the key optimizations include:

🌴 Tree-shaking: If you import a package but don’t use it, the bundler doesn’t include it in the final bundle. The bundler only consists of the code needed.
✂️ Minification: It removes unnecessary whitespace and comments and renames variables to make files smaller.

In our example app, I have a constant called NOT_USED_CONSTANT that I am importing inside index.tsx but not using. So it won’t be inside bundle.js.

Benefit #4. It enables dynamic imports (a.k.a. code-splitting)

Let’s say part of your app is only needed for specific users (e.g., a dashboard for logged-in users).

You don’t want to load everything upfront—you want to lazy-load that code only when needed.

You can tell your module bundler to “put some piece of code in a separate file and load it only when required.

When you do this, you increase your app speed 🚀 since there are fewer files to download.

Benefit #5. (Bonus) It supports different file types (.ts, .json, etc.)

By default, bundlers work with JavaScript files.

But they also support other formats (.ts, .json, .jsx, etc.) using loaders (Webpack, Esbuild, etc.)

Without this, you’d need to manually process these files before bundling them.

Do I need to know how to configure a module bundler?

👉 No.

Unless you’re very unlucky, you shouldn’t have to.

For this post, I asked v0.dev to generate the esbuild setup for me 😅.

In my professional life, I’ve never had to configure bundlers myself—our great infra team handles it.

If you don’t have an infra team, here are your options:

Use tools (like Vite) that configure bundlers for you.
Google how to do it (plenty of examples out there).
Ask AI (which is what I did).

What matters is understanding what bundlers do so you don’t get in their way.

Summary

Module bundlers (esbuild, Rollup, Webpack, etc.) are not hard to understand.

They take many files and output fewer files.

They’re useful because they:

✅ Ensure dependencies load in the correct order.

✅ Reduce the number of HTTP requests needed.

✅ Optimize file sizes for faster downloads.

✅ Enable code-splitting for better performance.

✅ (Bonus) Support non-JS files like .ts and .json.

So, pick a bundler, play with it, and see it in action.

In my next post, I’ll share tips to optimize bundle size.