Context
Saving a file and waiting for the browser to update is the experience that most separates Vite from webpack day to day — and the reason for that speed difference lives entirely in the architecture behind each one. webpack was born at a time when bundling everything before serving was the only viable option: it builds a complete dependency graph and produces one (or several) bundles before anything reaches the browser, both in development and production. Vite was born after browsers started supporting ES modules natively, and takes advantage of that: in development, it doesn't bundle anything — it serves each module on demand, letting the browser itself resolve the imports, and only compiles what the current screen actually needs.
That architectural difference is why Vite's dev server starts up almost instantly even in large projects, while webpack's needs to assemble the initial bundle before serving the first page. For production builds, though, serving module by module stops making sense — and that's where the two converge: Vite uses a real bundler under the hood to generate the final artifacts. That engine, which historically split the work between a dependency pre-bundler and a build bundler, is today Rolldown — a unified bundler written in Rust that, from version 8 on, is already the default for both dev and build, bringing build speed closer to the speed the dev server already had.
When to choose Vite
Vite pays off in any new project based on ES modules, where the day-to-day speed gain — every file save reflecting almost instantly in the browser — matters more than compatibility with a legacy bundler configuration:
// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
export default defineConfig({ plugins: [react()] });
The typical configuration fits in a few lines because Vite already assumes reasonable conventions for most modern front-end projects — serving static files, resolving CSS and asset imports, applying HMR automatically. It's also compatible with much of the plugin ecosystem originally built for Rollup, which narrows the gap of specific plugins that Vite still lacks compared to webpack. The point to watch is exactly that: for very specific edge cases — unusual build transformations, integration with legacy tools that only speak webpack's loader language — Vite's ecosystem is still newer and less exhaustively tested in production.
When to choose webpack
webpack pays off when the project already exists, already has a mature build configuration invested over years, or needs very specific behavior that only a loader or plugin from the webpack ecosystem solves:
// webpack.config.js
module.exports = {
entry: "./src/index.js",
module: { rules: [{ test: /\.css$/, use: ["style-loader", "css-loader"] }] },
};
That explicitness of rules — every file type needs a loader saying how to transform it — is both webpack's strength and its weakness: it gives granular control over every step of the pipeline, but requires more manual configuration for cases other tools already solve by convention. In exchange, it was for almost a decade the reference bundler of the JavaScript ecosystem, and that installed base is still enormous — loaders and plugins for practically any conceivable scenario, including robust support for older browsers and complex enterprise build pipelines that already exist and won't be rewritten for the sake of a faster dev server.
Verdict
If your team is already on Vite 8, the answer about the build engine is already given: Rolldown, the unified bundler written in Rust, is now the default for both dev and build. But choosing purely on speed says less and less — webpack's historical production bottleneck keeps shrinking across the whole ecosystem, which is migrating to bundlers written in systems languages. What separates the two today is track record: webpack carries years of configuration, loaders, and institutional knowledge accumulated in existing projects, and rewriting that investment rarely pays off just for the promise of a faster dev server. For a project starting now, without that track record to carry, starting with the tool that already assumes the right conventions by default tends to save more time than any custom configuration would make up for later.