Turbopack stable + React 19 Compiler: the end of webpack?

In 2021, the state of the JavaScript toolchain was rough. webpack, launched in 2012, was showing its limits on large codebases: 20 to 40 seconds to start a dev server on an average Next.js app, production builds beyond the minute, HMR running out of breath past a hundred modules. Babel, on which webpack largely depended, was 50 to 100 times slower than equivalent parsers in other ecosystems. The debt was piling up, and the community was looking for a way out.

The movement started with the building blocks. SWC, launched by Vercel and DongYoon Kang, replaced Babel for transpilation: 20x faster on average on a typical TypeScript project. Almost simultaneously, esbuild (Go) demonstrated that an incremental bundler could process 10,000 modules in a few hundred milliseconds. Rolldown, Vite's future bundler written in Rust, entered alpha in late 2024. Oxc, linters and formatters included, followed. The toolchain was no longer written in JavaScript: it was written in compiled, parallelisable, close-to-the-metal languages.

Five years later, in 2026, the wave has reached maturity. Turbopack is stable for both dev and build on Next.js 16. Rolldown goes from alpha to stable alongside Vite 6. Oxc ships a formatter, a linter, and a resolver that are starting to replace ESLint and Prettier on very large codebases. The production-measured figures are unambiguous: dev-server startup 10 to 50 times faster, production builds 2 to 5 times faster, HMR staying under 100 milliseconds even on apps with several thousand modules.

For a studio like VALRY LABS, this change is not anecdotal. It alters the cost-value ratio of product iteration: what cost 30 seconds of focus on every modification now costs less than a second. Over a development day, that is 30 to 45 minutes of engineering time recovered — and above all, a flow-state thread that no longer breaks. That is the context that makes this article relevant: the question is no longer whether the Rust toolchain is ready, but when and how to migrate.

Turbopack is the bundler developed by Vercel, written in Rust, designed to replace webpack in both dev and build. For four years, the project stayed in beta: the promise held on the dev server (near-instant startup), but functional parity with webpack remained incomplete — notably on production builds and on certain homegrown loaders. Next.js 16, released in early 2026, marks the move to stable: `next dev --turbo` and `next build --turbo` are officially supported, documented, and recommended for new projects.

Functional parity with webpack now covers over 95% of standard cases. Everything that forms the core of a modern Next app works natively: App Router, Server Components, Server Actions, edge runtime, middleware, internationalisation, image and font optimisation, automatic code splitting, tree shaking. The most common plugins (PostCSS, Tailwind, SVGR — historically a source of friction) are now ported. On our internal projects, migrating a typical Next 14 app (Tailwind v4, Supabase, Prisma, Server Actions) takes between two and four hours of work, with no business-code rewrite.

Free zones remain. The most exotic legacy webpack loaders are not all ported: some non-JS asset-processing pipelines (complex SVGs, video formats, very specific business pipelines) may require a fallback. Deeply customised webpack configurations, with nested loader chains and advanced `configure-webpack`, must be rewritten against the Turbopack API or equivalent loaders. Vercel's documentation explicitly lists the remaining gaps, and the resolution trajectory is public.

The recommended migration path is progressive. First `next dev --turbo` to validate the DX in development, without touching the production build. During that phase, you measure the gaps, identify missing loaders, and clean up inherited configuration. Once dev has been stable for a few weeks, you switch `next build --turbo` on CI to check the produced bundles, final size, and Lighthouse conformance. Finally, you enable Turbopack in production after a shadow-build period (running both builds in parallel and comparing artefacts). This three-step procedure drastically reduces the risk of silent regression.

The React Compiler, released as stable with React 19, changes an entire facet of React discipline: auto-memoization. Since 2018, every reasonably complex React component was riddled with `useMemo`, `useCallback`, and `React.memo` to avoid useless re-renders. The rule was implicit but applied everywhere: any intermediate value, any function passed as a prop to a memoised child, had to be wrapped manually. Production code grew heavier, code reviews debated the merits of each `useMemo`, and forgotten-dependency bugs stayed frequent.

The compiler statically analyses the component tree and automatically inserts memoization in the right places, respecting hook purity rules. Concretely, the developer writes direct code, without systematic wrapping, and the compiler produces an optimised output equivalent to what a senior React engineer would have written by hand. On a typical codebase, we observe a 30 to 50% reduction in memoization noise (deleted `useMemo` / `useCallback` lines) and a 5 to 15% rendering performance gain on non-trivial apps.

Public benchmarks and our own measurements converge. On an average React dashboard (40 components, virtualised lists, complex forms, two levels of context), the React Compiler reduces the render time of a full re-render from 18 ms to 11 ms on average (measured on an M2 Pro, Chrome 130). On a standard e-commerce product page (40 cards, filters, sorting), the gain sits between 8 and 12% on TBT (Total Blocking Time). The gains are more modest than those promised for Turbopack on the build, but they compound with every user interaction — it is the INP that durably improves.

The other benefit, more qualitative, is code readability. Components become functions that describe a UI again, not chains of defensive hooks. Code reviews no longer debate the merits of a `useCallback` on a click handler: the question is now trivial — the compiler handles it. Juniors ramp up faster, because the mental barrier of memoization rules disappears. This cognitive simplification is probably the most underrated gain of the React Compiler — and it is also the one senior teams benefit from most, in review time and in calm.

Taken in isolation, Turbopack and the React Compiler are two substantial improvements. Taken together, they transform the development experience systemically. On a typical Next 16 app (200 routes, 1,500 modules, Tailwind v4, Supabase Auth, Prisma, a score of Server Actions), we measure internally a dev-server startup of 1.4 seconds, versus 22 seconds on the same app on Next 14 + webpack. HMR on a component change sits under 80 milliseconds, versus 400 to 800 milliseconds before.

The impact on flow is hard to overstate. Over a development day, an engineer can trigger 200 to 400 modify-validate cycles. Taking each cycle from 30 seconds to 1 second does not multiply productivity by 30 — human concentration has its own limits — but it preserves the mental thread. You no longer lose your train of thought waiting for the bundle to rebuild. You no longer develop avoidance reflexes (staying on a tab for 30 seconds, doing another task in parallel). Development becomes a fluid dialogue with the machine again.

On the production build, the figures are just as eloquent. The same Next app, which built in 78 seconds on webpack (production mode, GitHub Actions CI, standard runner), now builds in 23 seconds with Turbopack. That is a 3.4x ratio. On a larger codebase (monorepo app, 4,000 modules, 80 dynamic routes), we went from 4 minutes 12 to 1 minute 18 — a 3.2x gain. CI chains faster, time-to-preview shrinks, and code reviews can rely on fresh ephemeral deployments on every push.

On the code side, the conjunction with the React Compiler removes an entire category of review discussions. Across the last 50 PRs of one of our pilot projects, the number of memoization-related comments dropped from 23 to 2 (both remaining ones concerned custom hooks the compiler did not yet cover). Production code is shorter, more readable, easier to maintain. It is this combination — execution speed and code clarity — that justifies the migration, not just the benchmarks.

Not everything is rosy, and honesty requires acknowledging the situations where migration is premature or counter-productive. The first case is heavy dependence on very specific webpack loaders. If your build transforms non-standard assets (proprietary formats, video-compression pipelines, complex sprite generation via nested loader chains), Turbopack does not necessarily have an equivalent. Forcing the migration means rewriting those pipelines, which can represent several weeks of work for a marginal DX gain on those parts.

The second case is the complex monorepo with shared webpack configuration. Large organisations that invested in a webpack config base mutualised across 5, 10, or 20 apps, with internal presets, homegrown plugins, and enterprise conventions, have built capital that is costly to call into question. Turbopack offers a different API, and translating a decade of webpack tweaks takes sustained effort. In that context, the migration must fit into a multi-year project, not a sprint.

The third case is the build pipeline deeply integrated with non-JS assets. Some industrial, 3D-design, or visualisation apps embed generated WASM, compiled GLSL shaders, asset-bundled binaries. These pipelines often rest on very specific (sometimes internal) webpack plugins that have no equivalent in the Turbopack ecosystem. Migrating means reworking the whole chain, which falls outside the scope of a simple Next.js version bump.

Finally, there is the common-sense rule: if it works, don't fix it. A stable Next 12 or 13 app that builds in under 60 seconds, has no DX problems, and whose teams are satisfied has no urgency to migrate. Stability has value. Migration is relevant when it solves an identified pain (slow dev server, code made unreadable by `useMemo`, CI feedback too slow), not when it ticks a tech-watch checkbox. Our job as engineers is not to chase novelty, but to maximise delivered value — and sometimes, that means waiting.

In 2026, the JS-toolchain map has clarified. For Next.js development, Turbopack is the reference bundler, stable in dev and in build. For the Vite ecosystem, Rolldown (Rust) goes from alpha to stable on Vite 6 and 7, progressively replacing Rollup (JavaScript) without breaking the API. Oxc, a suite of tools (lint, format, resolve, minify) written in Rust, is starting to replace ESLint and Prettier on very large codebases, where ESLint can take several minutes to run.

This specialisation of tools is healthy. Turbopack and Rolldown do not cover exactly the same use cases (Turbopack is deeply integrated with Next; Rolldown is neutral and multi-framework). SWC remains the cross-cutting parser, bridging ecosystems through its Babel compatibility. Oxc offers a more radical alternative, aiming to simultaneously replace several tools with a single coherent Rust binary. Competition between these projects moves everyone forward, and developers are the direct beneficiaries.

And webpack in all this? It remains for legacy applications, and that is perfectly fine. webpack is not dead — it is maintained, it works, and there are thousands of apps in production running on it without issue. The webpack community keeps releasing versions (webpack 6 is expected in late 2026), the plugins are documented, engineers know it. For an organisation with a stable build and low constraints, staying on webpack remains a reasonable choice. The end of webpack is not a brutal event; it is a slow, assumed decline.

For VALRY LABS, the guideline is clear: every new project starts on Next 16 + Turbopack + React Compiler. Existing projects on Next 14 or 15 migrate at the pace of their product roadmap, starting with `next dev --turbo` as a low-risk exposure. Heavy cases (heavily customised webpack configs, heritage monorepos) stay on their current stack as long as no pain justifies the investment. It is this discipline — adopt fast, migrate prudently, keep the legacy when it works — that turns hype into a durable competitive advantage.