React Compiler Rust: from TypeScript plugin to performance engine
React Compiler Rust is a newly merged Rust port of Meta’s automatic memoization compiler for React that replaces the original TypeScript implementation to deliver faster builds, deeper JavaScript toolchain optimization, and more direct integration with modern Rust-based bundlers in order to improve web framework performance end to end.
Meta has merged a Rust port of the React Compiler into the main React repository, rewriting it from TypeScript as an “experimental, work-in-progress port” aimed at faster builds and tighter alignment with the Rust-heavy JavaScript toolchain. This is not a cosmetic refactor. As a drop-in Babel plugin the Rust version runs around 3x faster than the original, with the isolated transformation logic reaching up to 10x in some cases, although serialization keeps real-world gains lower. The key takeaway is clear: React’s maintainers have decided that performance now starts with language choice, not only with clever caching or configuration. That should change how framework authors, platform teams, and even product engineers think about their build pipelines.
Build speed improvements: why Rust in the JavaScript toolchain matters
The most important story is not that React Compiler Rust is faster in microbenchmarks, but that it slots into a Rust-first toolchain strategy that cuts whole classes of overhead from framework builds. Previously React Compiler ran as a Babel transform, so bundlers paid that cost on every build; wiring the Rust compiler directly into Turbopack, a Rust bundler, removes that plugin tax entirely. This is JavaScript toolchain optimization by subtraction, not by adding more layers.
The numbers show why this direction will be hard to ignore. One Vercel engineer reported over 40% faster compilation on the company’s large internal Next.js app after switching to the integrated Rust version, calling out the long WebAssembly cold start of the earlier SWC plugin path. The official Next.js account put route compilation improvements between 20% and 50% across test apps, with experimental support landing in Next.js 16.3. For teams staring at long CI queues and slow local feedback loops, that is not a minor tweak; it is time back every single day.
Developer experience: faster under the hood, familiar on the surface
A reasonable fear with low-level rewrites is that everyday developers pay in complexity for gains they did not ask for. Meta has pointedly avoided that trap. React Compiler, formerly known as React Forget, still does the same high-level job: it automatically memoizes components and hooks so teams no longer need to scatter useMemo and useCallback everywhere. The Rust port keeps the public, Babel-like API so existing users can upgrade as a drop-in swap with configuration left untouched.
That balance—aggressive internals, stable surface—is becoming the norm in performance-focused libraries. Jotai v2.20, a React state management library, follows the same pattern: it reworks internal store building blocks for high-throughput scenarios while leaving the daily API of creating and using a store unchanged for most developers. This is the right philosophy. Tool authors should chase every build speed improvement they can, but they should make those wins feel boring for application developers. Performance should be the default outcome, not another checklist item.
Beyond React: Jotai, TanStack Table and the performance-first mindset
React Compiler Rust is part of a broader shift where framework and library authors treat performance as a primary design constraint, including their choice of implementation language. The rewrite lines up with Rust’s growing role in frontend tooling: SWC has migrated to the official Rust compiler, Oxc packages it as reusable crates, and Rspack 2.1 ships native Rust support in its pipeline. The message is clear: performance-sensitive layers in the JavaScript stack no longer need to be written in JavaScript.
On the JavaScript side, libraries are chasing similar gains through careful internal engineering. Jotai v2.20 focuses on performance in high-throughput scenarios, rolling back a WeakMap-based design and passing parameters directly in its store building blocks after a reported regression. The release is framed as the last step before serious planning for Jotai v3 begins, with a roadmap that includes redesigning the building blocks array structure, dropping CommonJS builds, dropping support for React below 18, and removing the setSelf option. TanStack Table’s latest major version (V9) similarly targets memory efficiency and throughput, reinforcing that data-heavy UI infrastructure is now optimized as aggressively as back-end services.
Polyglot performance engineering: what comes next for web frameworks
Taken together, these moves signal a shift from JavaScript-only tooling toward polyglot performance engineering. React Compiler’s Rust port sits in the React monorepo and is evolving in the open through a dedicated working group. Jotai’s maintainers are explicit that v2.20’s internals are a stepping stone toward a v3 that bakes performance assumptions into its building blocks. Across the ecosystem, the hottest parts of the pipeline are migrating to Rust or being rewritten for maximum throughput, while user-facing APIs stay familiar.
There are trade-offs. The Rust port leaned heavily on large language models for mechanical translation, with humans handling architecture and review, raising valid questions about long-term maintainability and the quality of the resulting Rust. Not every integration has landed neatly either; one bundler withdrew an early Rust React Compiler integration from its tooling to “de-slopify” it despite promising 2x improvements. Yet the direction feels set. Framework authors who ignore language-level and toolchain-level web framework performance improvements will look slow and dated. The next competitive edge in frontend development will belong to teams willing to treat their stack as polyglot infrastructure, not a single-language comfort zone.
