React Compiler Gets a Rust Port, Mostly Written by AI

React Compiler, the optimizing build-time tool that automatically memoizes React components so developers stop hand-writing useMemo and useCallback, now has a second life in Rust. Joseph Savona, a React core team contributor at Meta, opened pull request #36173 describing a work-in-progress port and merged it into react:main after review. The framing is unusually candid for a project of this size: it is shared early, before internal testing at Meta, specifically to pull partners into the conversation while development continues.

What the compiler actually does

React Compiler sits in your build pipeline and rewrites component code to skip unnecessary re-renders. Instead of asking developers to manually wrap values and callbacks in memoization hooks, the compiler analyzes the code, figures out what depends on what, and inserts the caching automatically. The original implementation, babel-plugin-react-compiler, is written in TypeScript and runs as a Babel plugin.

The interesting engineering detail is that this is not a from-scratch reimagining. It is a pass-by-pass port. The Rust version converts source into the same intermediate representation the TypeScript version uses, called HIR (High-level Intermediate Representation), which is built on a control-flow graph and single-static-assignment form. It runs through the same sequence of passes with the same algorithms. The main divergence is in data layout: Rust's borrow checker pushes you toward arena-style structures where you pass around integer indices into a backing store rather than references. Anyone who has fought the borrow checker on a graph-heavy data structure will recognize the move.

The numbers, with a caveat

Savona is upfront that the performance figures come from AI-driven benchmarking he has not fully validated. With that caveat attached, the early results are notable. As a Babel plugin, the Rust version runs about 3x faster end to end. Serialization between Babel's AST and the compiler's own representation eats a large chunk of that, because the actual transformation logic is roughly 10x faster on its own. Native integrations that skip the Babel round-trip, like OXC and SWC, should see more of that 10x.

That serialization cost explains the architecture. The public API is essentially "Rust Babel AST plus scope info in, Rust Babel AST out." Each integration converts to and from its own native representation. The team settled on a Babel-like AST as the contract because converting any AST into HIR is genuinely complex and they can only maintain one such conversion. For now, integrations also have to hand over scope information, since the TypeScript version leaned on Babel's scope analysis. Computing bindings and references from the AST directly is on the roadmap, which would let them throw away the current scope serialization format entirely.

The AI angle, stated plainly

The line drawing the most attention is the development process. Savona writes that the architecture was heavily guided by humans, himself in particular, but the majority was coded by AI. He describes being hands-on with the architecture, the testing and verification strategy, and the incremental migration approach, then spending real time reviewing output and iterating to get code quality to a decent level.

The verification story is what makes this claim credible rather than a press release. All 1,725 fixtures in the snap test suite pass when comparing the Rust plugin against the main version, covering both generated code and error output. Beyond final output, the fixtures also pass a full comparison of the per-pass intermediate representation. The internal state, including log events and errors, is reported as nearly identical after every single pass, modulo some ID normalization. That is a much stronger bar than "the output matches." It means each individual transformation step captured the same detail. The key script, test-rust-port.sh, checks this internal state after each pass and can be pointed at any directory of JavaScript files, which is how Meta plans to test internally.

Three integrations and a request to publish

The PR ships three integration examples: an alternative Babel plugin that will eventually be removed as the work folds into the main plugin, plus react_compiler_oxc and react_compiler_swc crates demonstrating what OXC and SWC integrations could look like. OXC and SWC are both Rust-based JavaScript toolchains positioning themselves as faster alternatives to the Babel-centric ecosystem, so a native React Compiler is directly relevant to their pitch. OXC's maintainer Boshen has already referenced the PR in website documentation work, and the Biome project has an open issue touching React Compiler options.

The most practical friction surfaced in the comments. SWC maintainer kdy1 asked whether the crates could be published to crates.io. Another developer noted the catch: crates that depend on git sources cannot themselves be published to crates.io, which is why projects like OXC maintain and publish forked crates as a workaround. Official, versioned crates from the React team would remove that hurdle. It is a small logistical point, but it is the kind of thing that determines whether external tools actually adopt this or keep shipping their own forks.

What changes

For developers, nothing changes today. There are no builds available, and trying it requires hacking. The reviewers, mofeiZ and mvitousek, approved and merged with the enthusiasm of people shipping research rather than a stable release, and mvitousek noted they are fixing forward a lone surrogate issue rather than blocking on it.

The larger signal is about where build tooling is heading. React Compiler in TypeScript was always going to be a bottleneck for the Rust-native toolchains trying to replace Babel. A faithful Rust port, verified pass-by-pass against the original, gives OXC, SWC, and others a path to offer React's automatic memoization without a slow JavaScript dependency in the hot path. The planned changes are telling about the direction: returning a series of patches instead of replacing the entire program, arena allocation for the AST, and switching string storage to smol_str. Those are all about shaving the serialization overhead that currently caps the speedup at 3x in the Babel case.

The AI-authored framing will get the headlines, and it deserves scrutiny rather than applause. What makes this worth watching is not that a model wrote the code but that the team built a verification harness strict enough to trust it, comparing intermediate compiler state after every pass rather than waving at matching output. That methodology is the reusable lesson here, more than the language choice or the authorship.