Bun’s Native React Compiler Integration Delivers Up to 20× Faster Builds Than Babel

Bun integrates React Compiler natively

React projects normally need to add the React Compiler through Babel, Vite, or other build tools. Bun will now run the compiler directly in Rust with a single build flag.

bun build --react-compiler

According to Bun author Jarred Sumner, on a large React codebase the native chain is almost 20× faster than the Babel plugin.

What the new integration adds

Bun already parses JSX and TypeScript and can bundle React projects. The new feature makes the React Compiler a built‑in transformation step.

The compiler analyses components and hooks during the build, automatically applying memoisation optimisations that previously required developers to write useMemo and useCallback manually. bun build --react-compiler ./src/index.tsx When using the JavaScript API the equivalent option is:

await Bun.build({
  entrypoints: ["./src/index.tsx"],
  reactCompiler: true,
});

This removes the need for a separate Babel plugin for the React Compiler.

How the 20× speed was measured

Jarred’s test on a large React codebase shows:

Bun without React Compiler – 391 ms

Bun with React Compiler – 484 ms

Babel plugin (same input) – 9.58 s

The 484 ms vs 9.58 s yields a 19.8× speedup. Enabling the compiler adds only 93 ms (about a 1.24× increase over the baseline).

Another test round reported 394 ms → 465 ms for Bun, and 3.62 s → 13.04 s for the Babel plugin.

These results indicate that the React Compiler, previously a costly step, now behaves like an ordinary built‑in transformation.

Why it is so fast

The earlier Rust port of the React Compiler was about 3× faster as a Babel plugin and roughly 10× faster for the core conversion logic. The large gap comes from eliminating the compiler boundary.

Babel plugins must pass a Babel AST and scope information into the Rust compiler and then receive the transformed result, incurring AST conversion, serialization, and cross‑boundary call overhead.

Bun’s own parser already produces a fully resolved AST, allowing it to:

Convert the Bun AST to the HIR used by the React Compiler.

Run the Rust core analysis and optimisation passes.

Generate a Bun AST directly.

Continue with Bun’s existing minification, tree‑shaking and code‑generation steps.

No intermediate Babel AST is created.

Bun also swapped a HashMap for a Vec for hot data structures, packing small collections into a tighter memory layout and using a memory pool for objects created during compilation.

Performance notes show that across ~860 production components, the cumulative user time of all React Compiler passes dropped from ~2.5 s to ~0.5 s, with the heaviest InferMutationAliasingEffects pass falling from ~1850 ms to ~440 ms.

The speed gain is not just “Rust is faster than JavaScript”; it results from the combination of Rust core, Bun’s native AST, data‑structure optimisations, and a shorter build pipeline.

Was OXC used?

After the feature was announced, OXC core member Yunfei He noted an earlier PR that suggested using OXC. Jarred replied that the PR was not adopted.

The PR that actually landed in Bun’s main branch is #32504, which explicitly states that no Babel, SWC or OXC is pulled in; parsing, AST conversion and code generation all use Bun’s own implementation.

Do not pull in oxc. Do not pull in their ast, or allocator. Use bun's types only.

OXC is not part of the final implementation, although the official Rust React Compiler provides OXC and SWC integration examples.

Difference from the official Rust port

The React official PR #36173 moved the compiler core to Rust, while Bun PR #32504 integrated those Rust capabilities into Bun’s parser, AST and build flow.

The Rust port initially showed only Babel, OXC and SWC integration options; ten days later Bun offered a ready‑to‑use build flag.

Availability

PR #32504 was merged into Bun’s main branch on 2026‑06‑20. The feature is currently behind the next release; users can wait for an official version or build from the main branch.

Integration tests show that 1,647 of the upstream 1,807 React tests pass, with 160 skipped for Flow syntax, internal Meta capabilities, and debugging cases.

Because the new pipeline is fresh, edge cases such as exotic syntax, third‑party Babel plugins, error messages and upstream sync still need real‑world validation.

The key change is not the compiler’s capabilities but its usage cost: previously developers had to manage plugins, AST conversion and build‑time overhead; now a single build flag can enable the compiler, potentially making it a default part of the build process once compatibility is proven.