React Compiler oxc plugin

[poteto]

I wanted to open an issue capturing some of our past discussion on adding support for React Compiler as an oxc plugin.

For context, the React team reached out to both the swc and oxc projects a few months ago to collaborate on an official plugin for both projects to run React Compiler, allowing React apps to eliminate their Babel pipelines if it only existed to run the compiler.

There has been some progress on the swc side which has allowed us to start experimenting with running the compiler in swc in the compiler playground: facebook/react#32428. More testing is still required, but we've been excited to make progress on this as one of the most requested features for React Compiler is swc and oxc support.

We would love to collaborate on an official plugin for oxc. I understand oxc is not yet the default for Vite, but it would be incredible if we can get React Compiler support in oxc before it does. Please reach out via DM (X, Bluesky, etc) if you're interested in working together on this!

[yyx990803]

Thanks for reaching out!

We definitely want to make sure React Compiler can work efficiently with OXC, but I want to clarify a few constraints that are present:

• The React Compiler logic is currently written as Babel plugins and the primary logic is in JS.
• Both SWC and OXC are Rust toolchains. Supporting a Babel-compatible JS Plugin API is not very practical.
  • It will likely involve passing entire ASTs back and forth between Rust and JS
  • The core logic will still happen in JS, likely with limited parallelism, depending on how the logic is implemented
  • There will likely be limited, if not negative performance gains compared to an out-of-band approach (i.e. running OXC transforms and plain Babel transforms in separate passes)

As far as I can tell, SWC's current support for React Compiler involves running Babel via an embedded QuickJS instance inside SWC. I haven't benchmarked this myself but I assume it's not going to be very performant. The main benefit is so that on the surface React Compiler can be used in an SWC-only toolchain without involving Babel, but fundamentally it's far from ideal.

For OXC, we do not think doing something like this is worth it. In the short term, we recommend end users to use React Compiler directly via a separate Babel pass (e.g. Vite and Vite-based-framework users can configure it in @vitejs/plugin-react's babel option).

For the long run, we hope we can figure out a way to make React Compiler performant for all users. Our observation is the performance wins with Rust-based toolchains heavily depends on minimizing the amount of compilation work done in JS (which is slower and harder to parallelize). Vanilla React apps with Rolldown/OXC-powered-Vite can be up to 16x faster than Rollup-powered-Vite. The gain will likely be much smaller when React Compiler is involved. If the React team intends for React Compiler to become a default recommendation for all React users, I strongly suggest re-evaluating the potential performance tax it would incur on the React ecosystem.

I don't think there is a way to make the current React Compiler magically fast from either SWC or OXC side - that change needs to come from React Compiler itself. Some thoughts on this:

• Porting it to Rust will be very challenging - porting it to native OXC transforms will obviously yield the best performance, but the port will not be straightforward due to how differently Rust and JS works (and how OXC places some constraints on memory management for performance). That said, VoidZero would be open to exploring commercial arrangements to help with this if Meta is interested in having the best possible performance for React Compiler in the long run (likely 20~50x faster than Babel-based implementation based on benchmarks).

• Rewrite the transforms in Go (much easier for a straight port), and expose ways for Rust toolchains to call it via C FFI. TypeScript team has shown success in porting JS/TS code to Go with decent velocity and behavior alignment.

• Leaving it in JS: we do have plans to offer an API for "simple transforms in JS" - Rust sends AST directly to JS, where the JS-side uses a magic-string style API to do manipulations. Calls are buffered and sent back to Rust, and the final heavy lifting of string manipulation + source map generation happens all on the Rust side. There are many Vite ecosystem transforms using this approach currently and can be migrated to this approach with massive perf gains. The primary concern is that I am not sure this approach would suffice for React Compiler due to its complexity - but if the complexity is mainly in analysis rather than code generation, then I think this is still something worth exploring.

[josephsavona]

Hey @yyx990803, thanks for getting back to us! We appreciate your thoughts on how you'd approach an integration like this from the oxc side.

I don't think there is a way to make the current React Compiler magically fast from either SWC or OXC side - that change needs to come from React Compiler itself. Some thoughts on this

Yes, we've previously ported Relay Compiler from JS to Rust so we're familiar with the performance challenges of using JS for tooling and the tradeoffs of the languages involved. I'm personally a huge fan of Rust and previously experimented with a partial port of React Compiler to Rust to explore a more native integration with SWC and OXC. Porting to Rust is more straightforward than you may suspect, but it definitely would take a bunch of time to convert that would take time away from work on features and correctness. We hope to be able to prioritize build performance after the compiler is stable.

One discovery from our Rust exploration was that unlike JS with ESTree as the de facto standard representation, every tool (Hermes, SWC, OXC, ESBuild, Rome before its fall) has its own internal CST/AST-like representation (and sometimes different string representations!). Also note that ASTs aren't a good fit for React Compiler's low-level transformations, so the compiler internally converts from an AST into our own SSA-based intermediate representation, then compiles back to an AST at the end. We ended up defining our own ESTree-like Rust representation to use in the public API (our AST in, our AST out with the SSA form being purely internal), with the idea that we could have a converter for each integration (SWC <> our format, OXC <> our format, etc).

Long story short: if we did go forward with a native compiler, we'd likely need help implementing the conversion between the OXC AST and our AST.

I wonder if we can consider the collaboration and integration on two time scales:

• The initial stable version of React Compiler will remain JS-based. If OXC becomes the default on a shorter time frame, we'd love to make sure that there's at least a reasonable (if not perfectly optimal) way to use React Compiler in Vite-with-OXC. Our main priority is that it be easy to configure and not impose unreasonable overhead (ie if embedded QuickJS is faster than spinning up a Babel pre-pass, it would be nice to do the faster thing).
• Long-term, build performance is one of several priorities for us after the stable release. Given that we're continuing to expand the feature set of React Compiler, though, our preference is to achieve native-level performance with our existing JS code (the majority of the code is fully decoupled from Babel). We're partnering closely with the Hermes and Flow teams at Meta to explore using Static Hermes for React Compiler. It's very early, but we're likely to pursue this direction rather than a port to a different language. Regardless of whether we stay in JS or port to Rust, though, we'd likely need to explore the AST conversion step noted above.

[yyx990803]

Very nice to hear about the feasibility for a Rust port.

The initial stable version of React Compiler will remain JS-based. If OXC becomes the default on a shorter time frame, we'd love to make sure that there's at least a reasonable (if not perfectly optimal) way to use React Compiler in Vite-with-OXC. Our main priority is that it be easy to configure and not impose unreasonable overhead (ie if embedded QuickJS is faster than spinning up a Babel pre-pass, it would be nice to do the faster thing).

I think for the short term, having a separate Babel pass is straightforward enough for Vite users. I haven't really compared the embedded QuickJS perf vs. separate Babel pass, and would love to hear how it's doing for SWC.

We are definitely be open to collaborate on the AST conversion. Assuming you end up going with Static Hermes, and I am understanding it correctly, the eventual pipeline for React Compiler usage in OXC / Rolldown would be:

src --(oxc parser)--> oxc AST
  --(oxc-to-rc-ir conversion layer)--> React Compiler IR
    --(React Compiler Static Hermes build)--(rc-ir-to-oxc conversion layer)--> oxc AST
      --(other oxc transforms)--(oxc codegen)--> final code

Is this what you have in mind?

[josephsavona]

Thanks for the feedback! Re the pipeline — yeah that's the idea, except that the React Compiler public format would be an AST. The IR is purely internal, the conversion from AST to IR and back is complex enough that we want to write it just once.

I haven't really compared the embedded QuickJS perf vs. separate Babel pass, and would love to hear how it's doing for SWC.

I don't know if we have perf numbers comparing this in SWC but I'll ask around!