What is it?
A bundler takes your many small modules — JS, TS, CSS, images, MDX — and produces a few optimized files for the browser. It also runs your dev server with hot reload. Modern bundlers (Vite, esbuild, Turbopack, Rspack) are 10–100× faster than Webpack and ship near-instant feedback loops.
Why it matters
The bundler shapes how fast you can iterate and how fast users can load. A two-second hot reload is the difference between flow and frustration. A 500KB-too-big bundle is the difference between "snappy" and "we lost 5% of mobile users at LCP."
What to learn
- What a bundler does: dependency graph, tree-shaking, minification
- Vite: dev server using native ESM, production via Rollup
- esbuild: the speed leader (Go-based, used inside Vite + others)
- Turbopack: Next.js-native, fastest for App Router projects
- Hot Module Replacement (HMR) — why it preserves state
- Code splitting: dynamic imports + route-based + manual chunks
Common pitfall
Treating the dev bundle the same as production. Dev is uncompressed,
unminified, and slower per-byte but faster to rebuild. Production is
the opposite. Most "the site is slow" complaints check the wrong build.
Always measure with pnpm build output, not pnpm dev.
Resources
Primary (free):
- Vite — Why Vite? · docs
- Tooling.report · article
- Web.dev — Module bundling · article
Practice
Take a small project and run pnpm build. Open the output directory and
read the chunk names + sizes. Identify the largest chunk and find what
imports drove it. Bonus: use vite-bundle-visualizer or
webpack-bundle-analyzer to see the dependency tree. Done when you can
explain why the biggest chunk is big.
Outcomes
- Read a bundler's output and identify the biggest cost contributors.
- Configure code splitting so heavy routes don't slow the home page.
- Choose Vite, esbuild, or Turbopack for a new project with real reasons.
- Debug an HMR or build cache issue without restarting from scratch.