Port React Compiler to Rust

Original Article ↗ Hacker News Discussion ↗

Meta’s React team has merged an experimental port of the React Compiler from TypeScript/Flow to Rust, reportedly using LLMs heavily to translate roughly 120k lines of code. Commenters see clear benefits in faster, native tooling and improved build times, and several report good real‑world results from the compiler’s automatic memoization. At the same time, many raise concerns about maintainability, limited human review of such a large AI‑assisted rewrite, dependence on test coverage for correctness, and the broader trend toward “rewrite it in Rust with AI” becoming a norm for major JavaScript tooling.

React Compiler usage & real‑world performance

  • Multiple commenters report using React Compiler in production (e.g., large e‑commerce/media sites, Unifi UI, moderately large apps).
  • Reported benefits: noticeably better render performance, ability to delete most memo/useMemo/useCallback without regressions, and better performance than prior Preact setups in at least one case.
  • Downsides: increased build times, though some see acceptable compile times with modern bundlers; incompatibility with certain libraries (e.g., MobX) led at least one company to roll back as they also saw no clear perf gain on an existing codebase.

Automatic memoization & safety

  • Some are skeptical of automatic memoization due to risk of subtle performance regressions and hidden dependencies.
  • Others describe good experiences: ESLint lints flag non-optimizable or non-hook-compliant code, incompatible libraries are auto-excluded, and compiler-generated memoization is more granular and less error‑prone than manual patterns.
  • Tooling like the online compiler playground is suggested to inspect how code is transformed.

Why Rust, and how the port works

  • Current compiler was in TypeScript / Flow; Rust is seen as a way to gain speed, native binaries, easier parallelization, and independence from JS runtimes.
  • Memory safety is acknowledged as a plus but most see raw performance and startup time as the main motivation.
  • Arenas are used as a GC replacement; some see this as conceptually simple rather than added complexity.

AST design: Babel vs Oxc

  • Some question why the Rust port preserves a Babel-like AST instead of adopting Oxc’s AST.
  • Defenders argue: there are multiple consumers, the team already built logic around Babel’s representation, and they only want to maintain one complex AST→HIR conversion. Ecosystem-wide cleanups can come later.

LLM-assisted Rust port: trust, tests & maintainability

  • Many assume the port was heavily LLM-assisted and view this as a good match for mechanical rewrites when a strong test suite exists.
  • Supporters: if it passes thousands of tests (plus new ones), and public APIs don’t change, it’s a pragmatic win; LLMs excel at iterative “compare results, fix, repeat.”
  • Skeptics: 120k‑line PRs are nearly unreviewable by humans; “tests pass” may hide gaps; future feature work could be risky if few humans deeply understand the code.
  • Concerns about “cognitive debt” and a trend where codebases become effectively maintainable only with LLM help.

Process, reviews & broader reflections

  • Some worry about large PRs with limited visible review and fewer public RFCs than past React milestones.
  • Others reply that language choice is an implementation detail, and React’s public contract remains stable.
  • Broader debate: dynamic vs static languages, Java/.NET vs Go/Rust native tools, and whether LLMs lower or “remove” the barrier to using complex languages like Rust.