Choosing a Bundler Today: Vite, Webpack, Rspack and Turbopack Compared

Most comparisons of Vite and Webpack reach the same conclusion in the same words: Webpack is the configurable veteran, Vite is the fast newcomer, so use Vite for greenfield work and keep Webpack if you have to. That summary is not wrong, but it skips the parts that actually decide a migration: why the speed difference exists, what Vite asks you to trade away, why well-funded teams still run Webpack in production, and which two other bundlers belong in the conversation. This guide walks through the architecture, the recent changes to the landscape, the real gaps on both sides, and a decision framework you can apply to your own codebase.

Be Skeptical of the Numbers First

Before looking at any tradeoff, it helps to know how unreliable the popular figures are. Comparison pages frequently quote weekly npm download counts for Vite, and in mid-2026 those quotes ranged from about 20 million to more than 140 million, sometimes on pages published only days apart. A spread that wide is not measurement noise. It suggests much of this content is generated from templates, never checked, and republished with a new year in the headline.

The same applies to benchmark charts that claim an oddly precise startup speedup. Treat any single exact number, including the ones in this article, as a hint rather than a fact. The trustworthy sources are the tools' own release notes and, above all, measurements taken on your own project.

Two Opposite Approaches to the Dev Server

Webpack and Vite solve the same core problem: turning your source files into something a browser can load efficiently. Where they diverge is how they serve code during local development.

Webpack bundles before it serves

Webpack constructs a complete dependency graph of the application and produces a bundle before the dev server responds with anything. For a small project that is effectively instant. For a large one, every dev server start can take anywhere from several seconds to a couple of minutes, because the whole graph must be traversed and bundled first. Incremental rebuilds are faster than a cold start, but the upfront cost still grows with the size of the app.

Vite serves source on demand

Vite skips upfront bundling in development. It relies on native ES modules, which all modern browsers support, and serves your source files directly, transforming each one only when the browser asks for it. Bundling happens only when you run a production build. This is why Vite's startup time does not climb with project size in the way Webpack's does: it simply does far less work before the first page loads. A module that the current page never imports is never transformed at all.

The dev/prod parity problem

For production, Vite historically delegated bundling to Rollup, a separate tool with its own plugin API, while development transforms went through esbuild. Webpack, by contrast, has always used a single engine for both modes. That split was one of Vite's more legitimate weaknesses for years. Code could behave one way under the esbuild-based dev pipeline and slightly differently once Rollup produced the production bundle, and tracking down those mismatches was an occasional but real source of frustration. As described below, recent releases have largely removed this issue.

How the Landscape Shifted Recently

The tooling world has moved quickly, and much of the content still in circulation describes a situation that no longer exists. The main milestones, as reported at the time of writing:

• February 2025: the React team officially deprecated Create React App, the tool through which many developers used Webpack without ever opening a config file. The recommended alternatives were frameworks, Vite, Parcel and Rsbuild. A hand-written Webpack setup was not on the list.
• October 2025: Next.js 16 made Turbopack, Vercel's Rust-based bundler, the default for both next dev and next build. A newly created Next.js app uses Turbopack unless you explicitly opt back into Webpack. Tobias Koppers, who created Webpack, now works on Turbopack at Vercel, which says something about where tooling expertise has been flowing.
• March 2026: Vite 8 reached a stable release with the largest architectural change in its history. Rolldown, a Rust-based bundler, took over from esbuild and Rollup as one engine for both development and production. That is what closes the parity gap: there is no longer a handoff between two bundlers with two plugin systems.
• June 2026: Cloudflare announced the acquisition of VoidZero, the company founded by Vite's creator Evan You to develop Vite, Vitest, Rolldown and the Oxc toolchain. Cloudflare said the projects would remain open source, pledged $1 million to an independent Vite ecosystem fund and signaled closer integration with its Workers platform and edge network.

Because several of these events are recent, check the current release notes and announcements before relying on the details. None of it means Webpack has gone away. It has not. But the ecosystem today is quite different from the one many comparisons still describe. For a wider view of this shift toward Rust-based tooling, see JavaScript's 2026 shift toward new runtimes, TypeScript 7 and Rust tooling.

What the Speed Difference Means in Practice

With Rolldown in place, the performance gap on large codebases became hard to miss. The Vite team has reported production build times dropping by roughly 10 to 30 times for projects that migrate, and independent reports describe similar multiples for cold starts and hot module replacement. Once a codebase grows to many thousands of modules, rebuilding with Rolldown-powered Vite versus Webpack is a contrast nobody needs a stopwatch for.

Project size decides whether you will notice

The caveat that rarely makes it into headlines is that the benefit scales with the codebase. With a few hundred modules, Webpack might start two or three seconds slower than Vite, a difference you will not feel during a normal working day. Dramatic benchmark charts are almost always produced against very large, synthetic or enterprise-scale projects, because that is where the architectural difference compounds from seconds into minutes. For a mid-sized internal tool, the claim that Vite is twenty times faster can be both true and practically irrelevant.

Directional trends versus exact figures

Many of the most striking figures online, such as very large weekly download counts or HMR speed ratios quoted to one decimal place, come from SEO-driven content that benefits from making the gap look as large as possible. The general trend is well supported by independent sources: during 2025 Vite passed Webpack in weekly npm installs, and it has been pulling further ahead since then. The specific numbers attached to that trend are something to verify yourself before repeating them.

A practical rule: if you want to know what migration would gain you, time a cold dev server start, a typical HMR update and a production build on your actual repository, with both tools, on the hardware your team uses.

Why Webpack Is Still in Production

Treating Webpack as a joke is lazy analysis. Webpack 5 is actively maintained and continues to receive updates, and it sits underneath a large share of production frontends built roughly between 2016 and 2023. Several kinds of teams have entirely rational reasons to stay:

• Teams with heavily customized build pipelines that encode years of decisions.
• Organizations whose security review process turns a bundler swap into a project lasting several quarters.
• Teams with firm requirements to develop against legacy browsers.

What has changed is momentum rather than maintenance. New tutorials, framework defaults and conference talks rarely begin with a Webpack config anymore. New Svelte and Vue projects default to Vite. Angular's CLI now uses an esbuild-based application builder instead of Webpack. Next.js defaults to Turbopack.

That shift has a staffing consequence worth planning for: engineers who understand Webpack internals in depth will become harder to hire over time, simply because fewer people are learning those internals now. If your business depends on a complex Webpack configuration, documenting it well is a form of risk management.

Where Vite Still Has Real Gaps

Enthusiasm for Vite tends to skip over a few specific weaknesses.

Module Federation is less mature

Module Federation lets independently deployed applications share code at runtime, and it is the backbone of most micro-frontend architectures. It shipped natively in Webpack 5 and has years of production use behind it. Vite's federation support has depended on community plugins that historically trailed the original. For a long time only the host application had a proper dev-mode experience; remote applications had to be built first and served from their output, which made local development noticeably clumsier than with Webpack.

That situation improved considerably through 2025 and 2026, with more mature plugins reaching production-oriented releases, and Rspack now provides its own federation implementation as well. Still, if your architecture relies heavily on federation, do not assume parity. Test your specific topology.

The unbundled dev server depends on modern ESM

The fast dev experience assumes the browser loads ES modules natively. Practically every browser in active use does, but teams that must run their dev server against genuinely old targets will feel friction. Production output can be transformed for older browsers through plugins; the unbundled dev mode itself cannot.

The plugin ecosystem is younger

Over more than fourteen years, Webpack accumulated a vast collection of loaders and plugins. Some are redundant, many are abandoned, but for almost any unusual asset type or legacy integration, something exists. Vite's ecosystem is large and growing quickly, and most Rollup-compatible plugins work with it, but for rare enterprise integrations you can still run into a gap that Webpack's community covered years ago. Before migrating, list every loader and plugin your build uses and confirm each has an equivalent.

Rspack and Turbopack: The Options Headlines Leave Out

Framing the choice as Vite versus Webpack was already outdated by 2025. Two more tools matter.

Rspack: Webpack compatibility with Rust speed

Rspack is a Rust reimplementation of Webpack, backed by ByteDance and designed to be close to a drop-in replacement. It keeps the same configuration shape and the same loader and plugin model while running much faster. For a team carrying years of Webpack configuration, custom loaders and a Module Federation setup, moving to Rspack is usually a far safer path than rebuilding around Vite's dev-server model. You capture most of the speed improvement without changing your architecture.

Rspack is part of a broader family that includes Rsbuild, a zero-config build tool, and Rslib, a bundler for libraries. It is growing around its core bundler much as Vite grew Vitest and VitePress around itself.

Turbopack: the default inside Next.js

Turbopack is Vercel's Rust-based bundler and, since Next.js 16, the default for Next.js applications. It is not really a general-purpose tool that you evaluate on its own. If you use Next.js, the framework has essentially chosen for you; if you do not, Turbopack is currently not something you would adopt outside that ecosystem. If you are already on it and want to tune its output, see tuning Turbopack's chunking controls in Next.js 16.3.

Ignoring these two tools means missing what is, for many real-world migrations, the most pragmatic answer.

A Decision Framework by Scenario

Rather than a single verdict, match your situation to one of these cases:

• New project without legacy constraints (a single-page app, a Vue or Svelte app, a component library): choose Vite. It is no longer a close decision. Development is faster, configuration is simpler and the major frameworks already build their tooling around it.
• New Next.js application: you get Turbopack by default. There is nothing to decide unless you have a specific reason to return to Webpack.
• Large, working Webpack app with heavy customization or Module Federation: evaluate Rspack before considering a full move to Vite. Its compatibility goals target exactly this case, and a complete architectural migration to Vite is larger and riskier than most teams expect at the start.
• Regulated or tightly governed enterprise app (formal change management, mandatory security sign-off, or a need to develop against old browsers): remaining on Webpack is a sound choice you can justify, not evidence of falling behind. When switching costs are measured in engineer-quarters rather than engineer-days, the fastest tool is not automatically the right one.
• Existing micro-frontend architecture built on Module Federation: evaluate carefully instead of assuming any tool will simply work. Webpack and Rspack currently have the most proven federation implementations; Vite's options have matured quickly but have less production history. Validate your real topology before committing.

Wrapping Up

Vite has won the case for new projects, and it won it on merit. Serving source on demand is a better fit for how most teams work every day, and the move to Rolldown removed the last major structural weakness. Webpack has lost mindshare rather than capability; it remains a capable, maintained and deeply configurable bundler, even if the energy and the tutorials have moved elsewhere. Rspack turns leaving Webpack into a much smaller project than it sounds for teams with heavy legacy investment, and Turbopack has settled the question for anyone building on Next.js.

What to avoid is the idea that there is one universal answer. The right choice depends on the size of your project, how much migration risk your team can absorb and how much of your architecture depends on Webpack-specific features such as federation. Anyone offering a single confident verdict in either direction deserves the same skepticism as a benchmark chart with a suspiciously precise number on it.