Why is a Vite dev server fast to start regardless of project size, while webpack gets slower?

Because they do different amounts of work before serving the first request. Webpack builds a dependency graph of the whole application and bundles it up front, so startup time scales with the number of modules - a large app takes tens of seconds or minutes. Vite serves source files over native ES modules and only transforms a file when the browser actually requests it, so cold start is roughly constant no matter how many modules exist. The browser resolves the import graph itself by fetching modules on demand. The trade is that a page with a very deep import graph issues a lot of requests on first load, which is why Vite pre-bundles third-party dependencies into single files.

What invalidates an incremental build cache, and why do caches miss more than teams expect?

A module's cache entry is keyed on its content plus everything that could change its output - the loader and plugin configuration, compiler options, environment variables read at build time, and the resolved versions of its dependencies. Changing a file invalidates that file and everything downstream of it in the graph. Caches miss more than expected because of things that look inert - touching the bundler config invalidates everything, a lockfile change invalidates every dependent module, and a build-time environment variable that differs between CI runs quietly poisons every entry. That last one is the classic reason a CI cache appears configured correctly and never actually hits.

Your CI takes 25 minutes and most of it is reinstalling and rebuilding unchanged code. What do you change?

Add three cache layers, in order of payoff. Cache the dependency store keyed on the lockfile hash, so installs are near-instant unless dependencies actually changed. Cache build artifacts keyed on source content, so unchanged packages are restored rather than rebuilt. And cache test results the same way, so unchanged packages do not rerun their tests. In a monorepo, pair this with affected-only execution using the dependency graph, so a change to one package does not trigger work in forty others. The important detail is that the cache should be remote and shared across CI runs and developers - a per-runner cache on ephemeral machines almost never hits.

Why does Turbopack use Rust, and where does that actually help?

Because bundling is CPU-bound work over a large graph, and JavaScript is single-threaded by default while Rust parallelises across cores with no serialisation cost between them. The gain is largest where the work is most repetitive and parallel - parsing and transforming thousands of modules on a cold build, and recomputing the affected subgraph on every hot update. Turbopack also caches at a much finer granularity than the module level, so a small edit recomputes very little. Where it helps least is anything dominated by something other than transform time, such as a slow type check or a slow test suite, which no bundler choice will fix.

Build Tooling and Developer Experience - System Design

Q: How does build tool choice affect a team differently at fifty engineers than at five?

Because the cost is multiplicative rather than additive. A ten-second hot reload is a mild irritation for one developer and, across fifty engineers making dozens of edits a day, it is a substantial fraction of the team's working time - and worse, it is long enough to break concentration, so the real cost exceeds the measured seconds. The same applies to CI - a twenty-minute pipeline sets the floor on how quickly anything can merge, and with many concurrent pull requests it becomes the queue everything waits in. At five people you can absorb slow tooling with discipline. At fifty it silently sets the pace of the whole organisation.

Why It Matters

Build tooling is easy to dismiss as a preference. It is not, because its costs are multiplicative: they are paid by every engineer, on every edit, on every build, every day.

A ten-second hot reload is a mild irritation for one developer. Across fifty engineers making dozens of edits a day it is a large fraction of the team's working time - and worse, ten seconds is long enough to break concentration, so the real cost exceeds the measured seconds. The same applies to CI: a twenty-minute pipeline sets the floor on how quickly anything can merge.

At five people you can absorb slow tooling with discipline. At fifty it silently sets the pace of the organisation.

Dev Server Architecture

The largest difference between modern bundlers is not output quality - it is what they do before serving the first request.

Bundle-then-serve

Webpack's model. On start it crawls the entire dependency graph from the entry point, transforms every module, and produces bundles. Only then does it serve anything.

Startup time scales with the number of modules. A large application takes tens of seconds or minutes to cold start, and every developer pays that on every branch switch.

Hot module replacement is comparatively fast because the graph is already in memory, but a change still requires recomputing the affected part of the bundle, which grows with the bundle.

Native ESM serve

Vite's model, enabled by browsers supporting ES modules natively. The dev server transforms a file only when the browser requests it, and the browser resolves the import graph itself by following imports.

Cold start is roughly constant regardless of project size, because almost no work happens up front. HMR is close to instant, because only the changed module is retransformed and swapped - not a bundle segment.

The trade: a page with a deep import graph issues a lot of small requests on first load. Vite mitigates this by pre-bundling third-party dependencies - which change rarely and often ship as many small CommonJS files - into single ESM files, while application source stays unbundled.


Diagram100%
flowchart TB
    subgraph WP["BUNDLE-THEN-SERVE - webpack"]
        W1["Dev server starts"] --> W2["Crawl entire dependency graph"]
        W2 --> W3["Transform every module"]
        W3 --> W4["Produce bundles"]
        W4 --> W5["NOW serve the first request"]
        W6["Cold start scales with module count.<br/>Large app = tens of seconds to minutes."]
    end

    subgraph VT["NATIVE ESM SERVE - Vite"]
        V1["Dev server starts"] --> V2["Pre-bundle node_modules only"]
        V2 --> V3["Serve immediately"]
        V3 --> V4["Browser requests a module"]
        V4 --> V5["Transform that one file, on demand"]
        V5 --> V4
        V6["Cold start roughly constant.<br/>HMR retransforms one module."]
    end

    style WP fill:#3f2d1e,stroke:#f59e0b
    style VT fill:#1e3f2d,stroke:#22c55e
Zoom or open fullscreen for a closer look
visualized by

Rust-based bundling

Turbopack (and esbuild and SWC before it) attacks a different axis: the language the bundler is written in.

Bundling is CPU-bound work over a large graph. JavaScript is single-threaded by default, and the parallelism it can achieve requires serialising data between workers. Rust parallelises across cores with no serialisation cost, so the gain is largest exactly where the work is most repetitive and parallel - parsing and transforming thousands of modules on a cold build.

Turbopack also caches at a much finer granularity than the module level, tracking individual function-level computations, so a small edit recomputes very little.

Where it helps least is anything not dominated by transform time. A slow type check or a slow test suite is untouched by bundler choice, and teams that switch expecting a broad speedup are often disappointed for exactly this reason.

Incremental Builds and Cache Invalidation

An incremental build reuses work from the previous build. Understanding what invalidates a cache entry is what turns "the cache is not working" into a diagnosable problem.

A module's entry is keyed on its content plus everything that could change its output:

The module's own source
The loader and plugin configuration applied to it
Compiler options - target, JSX transform, minification settings
Build-time environment variables it reads
Resolved versions of its dependencies

Change a file and you invalidate that file plus everything downstream of it in the graph. That downstream propagation is why a change to a widely-imported utility feels far more expensive than its size suggests, and it is a real argument for keeping shared modules small and focused.

Three things cause caches to miss far more than teams expect:

Touching the bundler config invalidates everything. Config is an input to every module's key.

A lockfile change invalidates every dependent module. Adding one unrelated dependency can cascade widely.

A build-time environment variable that differs between CI runs poisons every entry. A timestamp, a build number, or a run ID baked into the build means nothing ever hits. This is the single most common reason a CI cache appears correctly configured and never actually helps.

CI Caching

Most CI time in a typical frontend pipeline is spent redoing work that has not changed. Three cache layers, in order of payoff.

Dependency cache, keyed on the lockfile hash. Restore the package manager's store rather than downloading and linking from scratch. Because the key is the lockfile, it invalidates exactly when dependencies actually change and not otherwise. Largest single win, easiest to set up.

Build artifact cache, keyed on source content plus config. If a package's inputs are unchanged, restore its output instead of rebuilding it. This is what Nx and Turborepo provide, and it is what makes a monorepo viable - without it, CI time grows with repository size forever.

Test result cache, keyed the same way. If a package's code and its dependencies are unchanged, its tests cannot have changed outcome. Skip them.


Diagram100%
flowchart TB
    Start["CI run begins"] --> Dep{"Lockfile hash<br/>in cache?"}
    Dep -->|"hit"| DepR["Restore dependency store<br/>~5s"]
    Dep -->|"miss"| DepI["Full install<br/>~120s"]
    DepI --> DepS["Save to remote cache"]

    DepR --> Graph["Build dependency graph<br/>compute affected packages"]
    DepS --> Graph

    Graph --> Aff{"Package affected<br/>by this change?"}
    Aff -->|"no"| Skip["SKIP entirely -<br/>no build, no tests"]
    Aff -->|"yes"| BC{"Build artifact<br/>in cache?"}

    BC -->|"hit"| BR["Restore artifact"]
    BC -->|"miss"| BB["Build package"]
    BB --> BS["Save to remote cache"]

    BR --> TC{"Test result<br/>in cache?"}
    BS --> TC
    TC -->|"hit"| TR["Restore result - skip run"]
    TC -->|"miss"| TT["Run tests"]
    TT --> TS["Save to remote cache"]

    Skip --> Done["Pipeline complete"]
    TR --> Done
    TS --> Done

    Remote[("Remote cache<br/>shared across CI runs<br/>AND developer machines")]
    DepS -.-> Remote
    BS -.-> Remote
    TS -.-> Remote
    Remote -.-> DepR
    Remote -.-> BR
    Remote -.-> TR

    style Remote fill:#1e3a5f,stroke:#3b82f6
    style Skip fill:#1e3f2d,stroke:#22c55e
Zoom or open fullscreen for a closer look
visualized by

Two properties decide whether this actually works.

The cache must be remote and shared. CI runners are ephemeral, so a per-runner local cache almost never hits. A shared remote cache means one engineer's build populates the cache for everyone - including for developers running builds locally, which is where a large share of the real-world benefit comes from.

Affected-only execution needs a correct dependency graph. Nx and Turborepo derive it from imports and workspace configuration. If the graph is wrong - a dynamic import it cannot see, an implicit dependency through a generated file - you will skip work that should have run, which is worse than running everything. Graph correctness is a maintenance obligation, not a one-time setup.

Choosing, and When to Switch

Webpack remains the right answer when you depend on its ecosystem. Fifteen years of plugins cover cases newer tools have not reached, and the configuration surface handles genuinely unusual requirements. The costs are slow cold starts and configuration complexity that becomes tribal knowledge.

Vite is the sensible default for new projects. Near-instant dev server, fast HMR, sane defaults, Rollup for production output. The main caveat is that dev uses native ESM and production is bundled - two different code paths, and it is possible though uncommon for something to work in one and not the other.

Turbopack makes most sense inside Next.js, where it is integrated. Its advantage is largest on very large applications and on hot update latency.

The migration question deserves an honest answer: switching build tools is rarely the highest-value work available. A migration takes weeks, touches every developer, and risks subtle production differences. It is worth it when cold start or CI time is measurably costing meaningful engineering hours, and it is not worth it because the new tool benchmarks better. Measure the current cost first - if your pipeline is slow because of a slow test suite, a faster bundler changes nothing.

Tradeoffs

Option	Pros	Cons	When to Use
Webpack	Deepest plugin ecosystem, handles unusual requirements, battle-tested	Cold start scales with project size, complex configuration	Existing projects depending on specific plugins
Vite	Near-constant cold start, near-instant HMR, sane defaults	Dev and production use different pipelines, younger ecosystem	New projects, and most migrations away from webpack
Turbopack	Rust parallelism, fine-grained caching, fastest hot updates on large apps	Tightly coupled to Next.js, smaller ecosystem	Large Next.js applications
Dependency cache	Biggest single CI win, trivial to configure, keyed exactly right	None meaningful	Every pipeline
Build artifact cache	Unchanged packages never rebuild, keeps CI flat as the repo grows	Needs a correct dependency graph and remote storage	Monorepos and multi-package repositories
Affected-only execution	Pipeline time tracks change size, not repo size	A wrong graph skips work that should have run	Monorepos with Nx or Turborepo
Migrating build tools	Can substantially cut dev and CI time	Weeks of work, touches everyone, risks production differences	Only when the current cost is measured and material

Where This Applies

The dependency graph and remote caching described here are what make the monorepo option in Application Architecture at Scale viable - choosing a monorepo without them is choosing a pipeline that degrades every month. The affected-only execution and CI gates are the same machinery that runs the tiered suite in Testing Strategy, and code splitting, tree shaking, and bundle budgets are the production-output side of these tools, covered in Performance Engineering.

In the applied practice problems, this decides how much of a page's JavaScript is on the critical path - most visibly in Dashboard with Widgets, where a registry of dynamically imported widgets keeps a dozen charting libraries out of the main bundle, and in Video Player, where the player library's own download and parse sit directly in front of the first frame.