React Compiler's Rust Port: Inside the Architecture and Performance Play

The migration of JavaScript tooling to systems languages has reached a critical milestone. In an experimental pull request on the React repository, Meta developer Joseph Savona introduced a work-in-progress port of the React Compiler to Rust.

This move signals a step-change in build-time performance and positions the compiler for native embedding within modern, high-speed bundlers and compilers. While the project is in its early stages and lacks public pre-built binaries, the architectural decisions and initial benchmarks reveal a highly pragmatic approach to rewriting complex JavaScript compiler logic in Rust.

The Architecture: A Direct Port with Arena Allocation

Rather than redesigning the compiler from scratch, the Rust port maintains the exact same internal architecture as its TypeScript predecessor. The compiler ingests an Abstract Syntax Tree (AST), converts it into a High-level Intermediate Representation (HIR), and processes it using a control-flow graph (CFG) and single-static assignment (SSA).

To replicate this pass-by-pass pipeline within Rust's strict memory safety model, the developers bypassed traditional nested pointer structures in favor of arena allocation. The compiler represents data structures using arena-like layouts, referencing nodes via indices into these arenas. This pattern is a common and effective strategy for working within Rust's borrowing system, avoiding the overhead of reference counting or complex lifetime annotations while maintaining high cache locality.

To ensure absolute correctness during the transition, the team implemented a rigorous multi-tiered testing strategy. All 1,725 existing compiler fixtures pass verification. The testing suite compares not only the final generated code and error outputs but also the internal state of the compiler after every single pass. Using a dedicated script (compiler/script/test-rust-port.sh), the developers verified that the intermediate representations, log events, and errors remain virtually identical to the TypeScript implementation, modulo minor ID normalizations.

The Integration Strategy: Babel, SWC, and OXC

One of the steepest hurdles for any Rust-based JavaScript tool is interfacing with existing ecosystem pipelines. To address this, the Rust compiler defines its public API around a Rust representation of the Babel AST combined with serialized scope information.

Currently, the compiler does not perform its own scope analysis; it relies on the host integration to provide this metadata. The public API takes the Rust Babel AST and scope info, processes it, and outputs a modified Rust Babel AST. Individual integrations are then responsible for converting this AST to and from their native representations.

The pull request includes three initial integrations:

1. An alternative Babel plugin wrapper.
2. An integration example for SWC (react_compiler_swc).
3. An integration example for OXC (react_compiler_oxc).

This design introduces a known bottleneck: serialization overhead. When operating as a Babel plugin, the cost of serializing data back and forth between the JavaScript and Rust boundaries is high. However, because the actual transformation logic in Rust is roughly 10x faster than the TypeScript version, the plugin still achieves a net 3x overall speedup in early, unvalidated benchmarks. For native integrations like SWC and OXC, which run entirely within native pipelines, the serialization penalty disappears, promising even greater performance gains.

AI-Assisted Systems Engineering

An intriguing aspect of the port's development is its execution model. While the overall architecture, testing framework, and migration strategy were heavily guided by human engineering, the majority of the actual Rust code was generated by AI.

This hybrid approach highlights a shifting paradigm in systems rewriting. By establishing strict verification boundaries—specifically the per-pass intermediate representation diffing—the engineers could safely offload the tedious task of translating TypeScript algorithms into Rust syntax to language models, focusing human effort on code quality reviews, API design, and debugging subtle logic gaps.

What's Next for the Compiler

As the port moves toward internal testing at Meta and collaboration with external tooling partners, several key API refinements are already under consideration.

Currently, the compiler returns an Option<Program>, which evaluates to Some if any changes occurred, requiring the host toolchain to replace the entire program AST. To optimize this, the team plans to transition to a patch-based API. Instead of returning a wholesale program, the compiler will emit a series of discrete patches to apply, minimizing memory overhead and making the compiler significantly more efficient for integration into modern, incremental bundlers.