Port React Compiler to Rust

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.