The premise baked into the headline is backwards. Vercel’s “Turbopack: Moving homes” post moved Turbopack’s source into the vercel/next.js monorepo, not out of it, and a standalone, framework-agnostic Turbopack remains unshipped roughly four years after the project was first announced. For anyone not building on Next.js, the bundler decision is between Rspack and Vite. Turbopack is not in the running.
Did Turbopack Actually Leave Next.js?
Vercel’s announcement moved Turbopack deeper into Next.js, not out of it, and explicitly deferred a standalone repo until the bundler reaches a stable standalone state it has not reached.
The post title, “Moving homes,” is where the confusion starts. Turbopack’s source was relocated from the vercel/turbo monorepo into vercel/next.js, with co-development with Next.js given as the rationale. The same post says a separate home for general-purpose Turbopack will arrive only once the project is stable as a standalone tool, a milestone that has not happened. As of mid-2026, Turbopack is usable only through Next.js: there is no standalone CLI, and no adapters exist for Remix, SvelteKit, Nuxt, or plain React projects, per the Kunal Ganglani benchmark writeup. Vercel has discussed framework-agnostic support for years without shipping it (yes, it has been “coming soon” since the 2022 alpha).
Why Does Framework Coupling Matter More Than Raw Speed?
A bundler welded to one framework is a Next.js implementation detail, not a general-purpose tool, and that shapes every downstream tradeoff.
In 2026, Turbopack is the default bundler in Next.js 16 for both next dev and next build, with no flags required, per the migration guide. The config key moved from experimental.turbopack to a top-level turbopack key in next.config.ts; projects with custom webpack configurations can opt back via --webpack, per the Turbopack docs. The framework is making a one-bundler bet on your behalf. Next.js 16.2, shipped March 18 2026, then layered Server Fast Refresh on top: only the changed module reloads rather than its entire require.cache chain, yielding 67, 100% faster application refresh and 400, 900% faster compile time on real apps including vercel.com. The four-pillar architecture underneath (per the Turbopack API reference) is real engineering: a unified dependency graph, function-level incremental caching, lazy bundling, and bundling in dev rather than native ESM. It is also engineering optimized for the Next.js dev loop, and none of it is reachable from a Remix or Vite project.
Cold Start, HMR, or Production Build: Which Bundler Wins Which Race?
There is no single fastest bundler. Cold start, HMR, and production build are three separate races with three different winners.
Two public 2026 benchmarks exist, and they run on different hardware with different project sizes, so they should not be cross-compared. Read each dataset internally and the pattern holds.
On an 800-component React app (~95k lines of TypeScript, M3 MacBook Pro, five-run median), the Kunal Ganglani benchmark reports cold dev start at Rspack 1.4s, Turbopack 2.1s, Vite 8 2.8s; HMR on a deeply nested component at Turbopack 70ms, Vite 130ms, Rspack 160ms; and production build at Rspack 3.4s, Vite 4.1s, Next.js build 8.2s (standalone Turbopack is not applicable).
On a 2000-component project with 500 npm deps (M4 Max), the DevTool Reviews comparison reports cold start at Rspack 188ms, Vite 6.0 245ms, Turbopack 410ms; HMR at Turbopack 8ms, Vite 12ms, Rspack 15ms; production build at Rspack 11.5s, Vite 14.2s, Turbopack 18.4s; and memory at Vite 420MB, Rspack 610MB, Turbopack 890MB.
How Much Webpack Config Can You Reuse? Rspack’s Real Moat
Rspack reuses roughly 95% of an existing webpack config, per the Kunal Ganglani benchmark; Turbopack and Vite reuse none.
Rspack was built by ByteDance from day one as a drop-in webpack replacement. It supports module.rules and popular plugins through a Rust bridge. In the same 800-component benchmark, the author found the webpack-to-Rspack migration substantially faster than an equivalent Vite migration, because Vite’s different plugin model requires rewriting config rather than adapting it. The migration-cost gap, not raw speed, is the actual moat for teams sitting on a large webpack config. Cold-start and build numbers can be clawed back over time; a six-month plugin rewrite cannot.
What Is Missing From Turbopack’s Plugin Story?
Turbopack’s webpack config compatibility is zero: any webpack() configuration in next.config.ts needs to be replaced, not adapted. If you need to stay on webpack, the --webpack flag is available, per the Turbopack docs.
Webpack loaders are supported, per the Turbopack announcement. Beyond loaders, the broader plugin and config ecosystem requires case-by-case verification against the Turbopack API reference; the tool’s Next.js coupling means anything outside the framework’s defaults has no guaranteed migration path. The Kunal Ganglani benchmark required restructuring the entire app to run inside Next.js before testing was even possible: that friction is a preview of what any webpack-heavy project faces before the first build number appears.
Is Vite With Rolldown the Safe Pick for Framework-Agnostic Teams?
For teams not on Next.js and not migrating a webpack monolith, Vite 6 with Rolldown is the lowest-friction default, and the 2026 Rolldown upgrade materially closed its old build-speed gap.
Vite 6.0 unified its dev and production pipelines behind Rolldown, a Rust port of Rollup, replacing the previous esbuild/Rollup split that produced dev-versus-prod behavior divergence. Production builds are reported at roughly 4x faster than the old JS-based Rollup while keeping full plugin-ecosystem compatibility, per the DevTool Reviews comparison. Vite also covers the widest set of frameworks of the three: Turbopack has no adapters outside Next.js, and Rspack’s surface is webpack-shaped, which leaves Vite as the only option with first-class stories across the major meta-frameworks. The tradeoff is that Vite’s dev mode is unbundled native ESM, the exact pattern Turbopack’s bundled-dev pillar was designed to avoid beyond a certain module count. Whether that matters depends on your project size.
What Did Yelp’s Rspack Migration Actually Save?
Yelp reported approximately a 50% build-time reduction moving their monorepo from webpack to Rspack, per the Yelp engineering blog.
The Yelp engineering blog is one of the few production-scale Rspack case studies with public numbers. The team used a staged rollout across their multi-page monorepo, completing the full switchover in a single PR once individual pages had been validated. These are the kind of build-budget numbers that justify a bundler swap on their own.
Which Bundler Should You Pick?
The choice reduces to two questions: are you on Next.js, and are you migrating from a webpack monolith?
| Situation | Bundler | Rationale |
|---|---|---|
| New or existing Next.js app | Turbopack (via Next.js 16) | Default for dev and build, no flags; Server Fast Refresh in 16.2 |
| Large webpack config, any framework | Rspack | ~95% config reuse; drop-in via module.rules and a Rust plugin bridge (benchmark) |
| New non-Next.js project, want framework flexibility | Vite 6 (Rolldown) | Widest framework coverage; Rolldown closed the build-speed gap |
The architectural tradeoffs in this table are durable. The version numbers are not. Turbopack’s standalone CLI, the Rolldown rollout, and Rspack’s webpack-compatibility edge will all move over the next year, so recheck the primary sources before you commit to a migration. The one thing unlikely to change soon is the constraint that frames the whole comparison: as of mid-2026, if you are not on Next.js, Turbopack is simply not available to you.
Frequently Asked Questions
Does Module Federation work with Turbopack in Next.js 16?
Module Federation is explicitly unsupported in Turbopack, and projects that depend on it must stay on webpack via the --webpack flag. Custom Sass functions (sassOptions.functions) and webpack-bundle-analyzer are also incompatible; teams need @next/bundle-analyzer as a replacement before a Turbopack-mode build will succeed.
Does Next.js 16 warn or hard-error when it finds a legacy webpack() config block?
Next.js 16 issues a hard build error if a legacy webpack() block is present in next.config.ts. Teams must remove the block or commit to --webpack fallback mode; there is no warning-only path or graceful degradation.
Does Rspack’s persistent cache hold up in CI environments, where webpack’s cache typically fails?
Rspack uses a portable persistent cache that survives path changes between CI runs, unlike webpack’s absolute-path cache, which breaks whenever the working directory differs. On fully warm caches, Rspack can reach up to 80% build-time reduction per the Yelp migration data, compared to the 52% figure that applied to their cold-build baseline.
What specific failure mode does Turbopack’s bundled-in-dev approach prevent that Vite’s native ESM does not?
Native ESM dev servers issue one HTTP request per module to the browser. Once a project exceeds several thousand modules, those requests compound into visible latency even when individual modules load quickly. Turbopack bundles modules before serving them in development, eliminating this request-volume ceiling.
