--- title: "18 — Module Bundlers — Two Jobs, One Dependency Graph" uid: module-bundlers tags: ["bundler", "esbuild", "webpack", "swc", "vite", "rolldown", "roadmap:frontend", "rollup"] excerpt: "A bundler does exactly two jobs — transform and bundle — and the modern split is a fast dev server plus a Rust-grade production build." date: 2026-08-12T18:35:09+0000 source: https://www.aveshina.my.id/en/blog/module-bundlers --- The tools between npm run dev and a working page were a magic black box until I named their two jobs. The unsticking: **a bundler does two jobs — transform and bundle** [1]. Once I could name those two jobs separately, the whole zoo of tools (Webpack, Rollup, Parcel, esbuild, SWC, Vite, Rolldown) collapsed into "which of the two jobs, and how fast." ## The dependency graph, first Browsers historically couldn't load a project's worth of JavaScript files the way I wrote them — scattered across folders, importing each other with import/export, mixing .tsx and .css and images. So a bundler's starting point is the same in every tool: starting from an entry file, follow every import/require and build a **dependency graph** of the whole project [1]. Then it walks that graph doing its two jobs. ```figure dependency graph App Button Card utils icon pkg ① TRANSFORM ② BUNDLE compile + transpile TS / JSX → plain JS resolve + split + shake code-split · tree-shake optimized assets ``` ## Job one — transform The first job is **translating files into something the browser can run.** TypeScript gets compiled to JavaScript; JSX becomes plain function calls; newer syntax gets *transpiled* (rewritten into an older version browsers already understand) [3][4]. Anything that isn't vanilla browser-runnable JS — CSS imports, image imports, .vue/.svelte files — gets turned into JS in this pass too. This is where the older tool, Babel, used to live. Babel is correct and mature but written in JavaScript, so on a big codebase the transform pass alone could take tens of seconds. The whole recent speed story in bundling is "rewrite the transform in a faster language." **SWC** does exactly that — a Rust-based compiler for JS/TypeScript/JSX that's orders of magnitude faster than Babel and now powers Next.js's compilation underneath [3]. **esbuild** is the parallel move with a different engine: a Go-based bundler/minifier that does the transform and bundling at near-instant speed (a *minifier* shrinks a file by stripping whitespace and shortening names), deliberately trading a few advanced plugin features for raw throughput [4]. SWC and esbuild aren't competitors so much as two answers to the same question — "can the transform stop being the slow part?" — built in Rust and Go respectively. ## Job two — bundle The second job is **walking that graph and turning many files into the few assets the browser actually loads** [1][2]. That means three sub-tasks I used to blur together: - **Resolve** the import graph — figure out which modules depend on which, and in what order. - **Code-split** — break the output into chunks so the browser loads a route's code lazily instead of one giant file up front. - **Tree-shake** — drop exported code that no importer ever uses, so dead code never ships [5]. This is the job **Rollup** made its name on. Rollup is built around ES modules (the modern import/export system) and its tree-shaking is the reference implementation — it produces unusually small, clean output, which is why it became the default for libraries [5]. **Webpack**, the legacy incumbent, does both jobs and does them with a configuration surface so large it became a meme; it earned its dominance by handling every asset type and edge case, at the cost of being slow and config-heavy [2]. **Parcel** sits at the opposite end of that dial: a zero-config bundler that detects your file types and transforms them automatically, favoring simplicity and rapid prototyping over control [7]. ## The Vite shift — dev and prod are not the same job The single idea that reorganized all of this for me: **the dev server and the production build don't have to be the same tool, and they shouldn't be.** During development I want instant feedback; for production I want the smallest, most optimized bundle. Vite's whole design is to stop forcing one tool to do both badly. **Vite** splits the work. In dev it doesn't bundle at all — it serves source files as **native ES modules** (the import/export system served straight to the browser, which resolves the imports itself), and it uses esbuild to transform files on the fly. The result is a dev server that starts in milliseconds regardless of project size, and Hot Module Replacement (HMR) — swapping in a changed file without reloading the whole page — that feels instantaneous [6]. For production, where native ESM would be too slow to ship, Vite hands off to a real bundler — historically **Rollup**, increasingly **Rolldown** — for code-splitting, tree-shaking, and minification [6]. ```figure DEV (Vite) source files esbuild native ESM to browser · no bundle instant HMR PROD (Vite) source files Rolldown code-split · tree-shake · minify optimized assets shipped ``` ## Rolldown — Rust-ifying the production bundler **Rolldown** is the piece that clicked last. Rollup's tree-shaking is great but, being JavaScript, it's the slow part of Vite's production build on large apps. Rolldown is a from-scratch **Rust rewrite of Rollup**, designed as a drop-in replacement — same module-resolution semantics and plugin compatibility, but with the bundling pass running at native speed [8]. Its whole reason for existing is to remove that last JS-shaped bottleneck so Vite's dev and prod paths can both be fast without trading away Rollup-grade output quality. That's the broader arc worth seeing: the transform job moved to Rust/Go (SWC, esbuild), the dev server moved to native ESM (Vite), and now the bundling job itself is moving to Rust (Rolldown). Webpack, Rollup-in-JS, and Babel aren't wrong — they're the mature generation the faster tools are standing on the shoulders of. ## How I map them When a tool name comes up now, I just ask which of the two jobs it's doing: - **esbuild / SWC** — the transform job, fast (Go / Rust). - **Webpack** — both jobs, legacy, maximal config. - **Rollup** — the bundle job, library-grade tree-shaking, written in JS. - **Rolldown** — the bundle job, Rollup's replacement in Rust. - **Parcel** — both jobs, zero config. - **Vite** — the orchestrator: native ESM + esbuild in dev, Rollup/Rolldown in prod. Two jobs, one graph, and a clear answer to "which job, and how fast." That's the whole category. The mystery was that I'd been treating six tools as six unrelated things; they're really six points on the same two-axis grid. ## References [1] webpack, "Concepts — Modules and the dependency graph," webpack Documentation. [Online]. Available: [https://webpack.js.org/concepts/dependency-graph/](https://webpack.js.org/concepts/dependency-graph/) [2] webpack, "What is webpack?," webpack Documentation. [Online]. Available: [https://webpack.js.org/concepts/](https://webpack.js.org/concepts/) [3] SWC Project, "SWC (Speedy Web Compiler) — Overview," 2024. [Online]. Available: [https://swc.rs/docs/](https://swc.rs/docs/) [4] E. Wallace, "esbuild — An extremely fast bundler for the web," 2024. [Online]. Available: [https://esbuild.github.io/](https://esbuild.github.io/) [5] Rollup, "Introduction — Tree-shaking," Rollup Documentation. [Online]. Available: [https://rollupjs.org/introduction/](https://rollupjs.org/introduction/) [6] Vite, "Why Vite — Problems & Solutions," Vite Documentation. [Online]. Available: [https://vite.dev/guide/why.html](https://vite.dev/guide/why.html) [7] Parcel, "Getting Started," Parcel Documentation. [Online]. Available: [https://parceljs.org/docs/](https://parceljs.org/docs/) [8] Rolldown, "Guide — Introduction," Rolldown Documentation. [Online]. Available: [https://rolldown.rs/guide/](https://rolldown.rs/guide/) ```quiz Q: A bundler's two core jobs are… - minify and serve - transform (compile/transpile) and bundle (resolve, split, tree-shake) - lint and format correct: 1 explain: Transform turns non-browser code (TS, JSX, CSS imports) into runnable JS; bundle walks the dependency graph to resolve, code-split, and tree-shake into optimized assets. Q: Why does Vite feel instant in development even on a huge project? - It pre-bundles everything into one file on startup - It skips bundling entirely and serves source over native ES modules, using esbuild to transform files on the fly correct: 1 explain: Vite's dev server lets the browser do dependency resolution via native ESM and only transforms individual files with esbuild, so server start and HMR don't depend on project size. Q: SWC and esbuild are both best described as… - fast transform/compilers written in Rust (SWC) and Go (esbuild), meant to replace Babel-era JS transforms - production bundlers that compete with Rollup correct: 0 explain: SWC (Rust) and esbuild (Go) focus on the transform job — compiling TS/JSX far faster than Babel. They're the speed layer other tools (Next.js, Vite) build on. Q: What is Rolldown? - A zero-config bundler like Parcel, rewritten in Rust - A from-scratch Rust rewrite of Rollup, designed as a drop-in replacement for faster production bundling correct: 1 explain: Rolldown keeps Rollup's module-resolution semantics and tree-shaking quality but moves the bundling pass into Rust so Vite's production build isn't bottlenecked by a JS bundler. Q: Tree-shaking is the bundler's job of… - dropping exported code that no importer ever uses, so dead code never ships - splitting the output into lazy-loaded chunks per route correct: 0 explain: Tree-shaking removes unused exports from the final bundle. Splitting into lazy chunks is code-splitting — a separate sub-task of the bundle job. ```