Why use a module bundler?

A bundler reads your entry file, follows every import, and produces the files a browser should actually download. The original reason was that browsers could not load modules at all; that is no longer true, but the other jobs remain.

What it does beyond combining files

• Transforms. It runs TypeScript, JSX, Sass and PostCSS, so the browser receives plain JS and CSS.
• Resolves bare imports. import React from "react" is not a valid URL to a browser — the bundler maps it into node_modules.
• Tree shaking. Drops exports nobody imported, which is only possible because it sees the whole graph.
• Code splitting. Produces separate chunks per route or per dynamic import(), so the first load ships less.
• Content hashing. app.8f3c2a.js lets you cache assets forever and invalidate them by filename.
• Minification and dead-code elimination, including stripping development-only branches.
• Asset handling. Imports of images, fonts and CSS become URLs with hashes.
• Dev server with HMR, replacing a changed module without losing application state.

The bundling itself matters less than it used to

Over HTTP/2 many small files are multiplexed on one connection, so concatenating everything is no longer the win it was in the HTTP/1.1 era. Today the value is in the transforms, the dependency resolution and the splitting.

The current tools

Vite for applications — an unbundled dev server for instant startup, Rollup for production. Rollup for libraries, where clean ESM output matters. esbuild and Rspack when raw speed is the priority. Webpack remains widespread and highly configurable, but is rarely the choice for a new project.

When you can skip one

A small site with a few plain .js files and no framework can use native ES modules directly with an import map. The moment you add TypeScript, JSX, npm dependencies or want production optimisation, a bundler stops being optional.