Port React Compiler to Rust

https://github.com/react/react/pull/36173

by boudra • 1 month ago

124 118 1 month ago

Trung0246• 1 month ago

Curious but can we use lean4 as port target instead of Rust?

jon-wood• 1 month ago

I'm sure its technically possible, you might need to provide a bit more context if you expect anyone to change course here and port it to a programming language approximately no one has heard of rather than Rust though. What makes you think that would be a good idea?

koito17• 1 month ago

approximately no one has heard of

Just cause it isn't used for webshit doesn't mean "approximately no one" has heard of it.

Lean is pretty much the most popular language mathematicians use today for computer-assisted proofs. More mature audiences may know about Rocq, Isabelle, etc., but Lean was already popular enough for a few people I know to have written their PhD theses on it about a decade ago.

I think GP is joking about a port to Lean because that would at least produce a formally verifiable output.

bhy• 1 month ago

I don’t think lean4 compiled code is as efficient as rust. For verification purposes, there are some tools allowing formal verification of rust code.

giancarlostoro2• 1 month ago

Never heard of it, and I nerd out on programming languages. Reminds me of a convo yesterday with my coworkers where I noted I never heard of Sheerpower a language someone who worked there had done, and I have heard of languages so old and niche most people are shocked.

My first programming interview my interviewer was like what the heck are you doing with D? And he noted he has a room full of devs where nobody knows what D is.

willsmith72• 1 month ago

Are people actually using the react compiler?

Haven't heard about since ages ago when it was extremely slow

paavohtl• 1 month ago

We have used React Compiler in production for a large ecom / media website for about a year. Performance has been fine overall, and we haven't ran into any major bugs attributable to it in that time.

molf6• 1 month ago

Yes absolutely.

It's brilliant: all useMemo and useCallback can be removed and you get the same runtime performance and then some, at the cost of only a slight increase in code size.

A small downside at the moment is the build time. This change will hopefully help address that because it will no longer depend on babel.

_the_inflator• 1 month ago

Very insightful, thanks. I just delved into it, starting here: https://react.dev/learn/react-compiler/introduction

DanielHB2• 1 month ago

I haven't tried the compiler yet, but I been very skeptical of the automatic memoization features. Both in that sometimes the default strategy to decide when to memoize is not good enough but also the hidden flow to trigger the memoization causing hard to spot performance regressions.

I would be interest to hear how it worked out for you.

esperent• 1 month ago

I think the reason you haven't heard about it is that it just works. It's fast - with Vite 8 my moderately large app compiles in ~800ms, which includes typescript, react compiler etc.

I also took a step to clean out all memo, useMemo, useCallback across the app and so far have not run into any issues from doing this.

Ambroos• 1 month ago

We started using it for unifi.ui.com and the render performance gain has been massive.

pjmlp7• 1 month ago

Yes, and no. For some of us, there are projects with Next.js we cannot get away from, but those use Vercel stuff, also written in Rust.

Not sure how they relate to each other.

ameliaquining• 1 month ago

Next.js supports React Compiler: https://nextjs.org/docs/app/api-reference/config/next-config...

veidelis• 1 month ago

My company tried it but reverted the changes. The biggest reasons - it's not compatible with mobx and we didn't notice any perf gains on an existing codebase.

voidUpdate2• 1 month ago

What is the react compiler written in currently?

LoganDark6• 1 month ago

Uh, TypeScript?

iammrpayments• 1 month ago

I think they use something called “flow” last time I’ve checked, it’s like typescript but when I went to visit the website with more information it was so slow it crashed my browser.

voidUpdate2• 1 month ago

Isnt the benefit of rust that it's memory safe? Is typescript not?

ramon156• 1 month ago

I think it's fine to experiment, just communicate with your users and make sure its opt-in.

Seems like they kind of did that? The thread seems like people already were waiting on this, so that's positive.

LoganDark6• 1 month ago

Why are they porting the Babel-isms? They should be using Oxc tooling directly, not hanging onto JavaScript parsers, IMHO -- isn't the benefit of porting to Rust that you can use fast native code?

It seems backwards that they are freezing the Babel AST into the interoperability contract and only using the more efficient native representations in an isolated fashion -- shouldn't it be the other way around?

molf6• 1 month ago

OXC is not the only consumer, so using the OXC AST wouldn't particularly make sense? I thought it was pretty well explained in the PR:

Note that the conversion from any AST into our HIR is complex, and we can only maintain one version. Hence we've aligned on using a Babel-like AST as our public API. Another key point is that we don't yet implement our own scope analysis (since the TS version of the compiler relied on Babel's scope analysis), so for now we require that the scope data be serialized. It's a denormalized graph, and some metadata has to be stored to associate nodes with scopes. We're open to feedback about the AST and scope representation - we iterated a bit just to get things to work, but it can be more optimal.

LoganDark6• 1 month ago

I saw, I just don't understand the rationale for picking Babel over OXC or something else as the interchange format -- other than "we were already doing it this way". After all, you know what they say about temporary solutions.

AbuAssar2• 1 month ago

now we need to port angular compiler to rust!

flufluflufluffy• 1 month ago

We should compile Firefox to wasm, and run Firefox inside Firefox so we can Rust while we Rust

AbuAssar2• 1 month ago

Yo dawg I heard you like to rust

swiftcoder4• 1 month ago

I can hear Gary Bernhardt saying 'YavaScript'[1] in my mind

[1] https://www.destroyallsoftware.com/talks/wat

Klaster_1• 1 month ago

A couple of months ago, I experimented with this - took tsgo and ported tsc to go with Claude. The main issue why this still didn't happen yet is because tsgo doesn't expose plugin API externally, but it's still there, so you can just co-locate your plugin as extra Go module and compile everything together. Managed to get my fairly large Angular app to compile and even run unit tests. Cold compile time went down about 2x - so the benefits are there, but not as dramatic. I think this would still need architecture level optimizations that enable build parallelization, but that also requires making some changes to framework API so components can be isolated-compiled or something.

Surac• 1 month ago

<something> rewrite to rust using AI sound like meme now.

giancarlostoro2• 1 month ago

Speaks volumes to the strengths of the language, also speaks volumes that LLMs lift the barrier of entry for Rust programming, the borrow checker woes can be offloaded to the model, you focus on all the other programming logic.

Whats funny is I had been using Rust more with Claude because of this, and before Anthropic did their rewrite of Bun I tried a Rust rewrite of a C# project I had laying around (.NET 3.5 from back in 2008) it wasnt perfect but its nearly there now, mostly for fun, and I did it because for a little while I realized LLMs can be useful for more serious refactors, and figured it might be good for a language rewrite. Sure enough.

I think rewriting tooling that takes text and transforms it in a language like Rust is fine for JS projects, so is Go, which is why TypeScript is migrating to Go. The “free” optimized speed increases are worth it, at the temporary cost of dealing with the migration for a year or two, which with LLMs trims down the initial work into a week effort it seems? Wild.

fg137• 1 month ago

you focus on all the other programming logic

Does that actually happen?

rob74• 1 month ago

LLMs lift the barrier of entry for Rust programming

I think you actually meant "lower the barrier" (which would make it easier to pass the barrier, while lifting it makes it harder)?

nirui2• 1 month ago

Speaks volumes to the strengths of the language

Memory safety is just a tiny part of over all security. If a LLM can transcode correctly, then it should also output 100% correct C code.

On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.

pjmlp7• 1 month ago

Not really, any Standard ML derived language would do.

Also I think this is all temporary, just like devs still did not believe on optimising compilers and checked each line of generated Assembly code, during the 1960's.

Eventually it will be natural language, and all languages will be kind of irrelevant.

EddieRingle3• 1 month ago

Speaks volumes to the strengths of the language, also speaks volumes that LLMs lift the barrier of entry for Rust programming, the borrow checker woes can be offloaded to the model, you focus on all the other programming logic.

I get the opposite impression. If they aren't confident enough to write it by hand, I think it means the language is either hard to write, hard to read, or both. And by delegating to a LLM, there's no "barrier of entry" being lifted, it's just saving you typing time (like it would if it was being translated to C or Kotlin). If they actually decide to "focus on all the other programming logic" and they aren't just vibe coding this, they'll still need to be able to understand and reason about the code.

bogdanoff_2• 1 month ago

Just because something is written in Rust, doesn't mean it's good Rust.

I have noticed, in general, LLMs tend to "fix" problems by shoving them under the rug (like adding a cast) or writing a super-local "fix" instead of taking the time to understand the deeper problem or structure.

In Rust, when you get stuck in a complicated borrow-checking problem, Rust people will tell you it's a Good Thing(tm) because it forces you to think about the higher level architecture of your code. An LLM, on the other hand, might bash its head a couple of times trying to "fix" the problem, and then just throw in a Refcell (or other workaround), see that it compiles, and call it a day.

Refcells "move borrow checking to runtime", meaning that the code will compile, and will crash at runtime if the object is tried to be accessed from two different places at the same time. In most "normal" programming languages it's not an issue -- but it's a crash in Rust.

Now, maybe the models have gotten better, and maybe you can get around this problem by using a good system prompt/"tools" and a good testing methodology. What I am saying however is that you shouldn't automatically take "rewritten to Rust by AI" at face value of it being good Rust code, or a testimonial of "Rust and AI being a good match". (Go is better I think)

lioeters2• 1 month ago

Soon: Microsoft announces entire TypeScript language ported to Rust using LLM, with a 1M LoC merged after a week of intense vibe coding. And nobody would be surprised.

KolmogorovComp• 1 month ago

The day after, Microsoft announces the depreciation of the TS compilers as all programs get written in rust with IA from now on.

molf6• 1 month ago

After bun [1] this is another high-profile project that was ported to Rust by extensively using LLMs.

Very curious to see how these rewrites play out. Is the LLM foundation solid enough to build upon and iterate on? Or does this cause projects to become unmaintainable because no person understands the implementation anymore?

[1] https://news.ycombinator.com/item?id=48132488

IshKebab2• 1 month ago

I'd love to see Asciidoctor vibe-ported to Rust! Have either of these people detailed their methodology & costs?

benjaminleonard• 1 month ago

I think there's a few Rust ones knocking around, some LLM-assisted. I've recently had Claude re-implement the inline parser (https://github.com/oxidecomputer/react-asciidoc) using our large corpus (600+) of AsciiDoc documents

Had it convert it in this and the stock version, compare the output, fix and repeat.

mohsen1• 1 month ago

Shameless plug. I'm writing a TypeScript checker in Rust. It's not a port. I made this with a different architecture that hopefully once is done will be proven to be a better set of trade-off

https://github.com/tsz-org/tsz

bhouston• 1 month ago

So the port makes sense logically but how easy it is to contribute new features to it? Does the complex memory model (arena) impose complexity?

awesan• 1 month ago

How is using arenas complex? If anything it should make things simpler to understand to people who are not used to manual memory management.

pmarin• 1 month ago

The arena is replacing the javacript garbage collector not memory managament.

logicprog• 1 month ago

I thought arenas were one of the simplest and most easy to deal with and conceptualize memory management strategies around. Arguably easy, even easier to understand and just as easy to manage as GC. Did they do something special?

pjmlp7• 1 month ago

I love it starts with the usual hand waving,

This is an experimental, work-in-progress port of React Compiler to Rust. ...

And then gets merged.

So after the craziness to use node on the backend, we are back to using compiled languages to compile Javascript assets and Web resources, just like Java and .NET were doing in the 2000's, however since it is Go and Rust it is cool, not the boring languages grandpas were using on their heyday.

CamouflagedKiwi2• 1 month ago

TBF there is an advantage to having a tool like this being a native binary in Rust or Go, which are rather smaller, faster to start up and don't need a runtime like the JVM or .NET. It's also a lot more "web native" than Java applets were.

I'm not sad to see the pendulum swing away from "javascript everywhere" though.

pjmlp7• 1 month ago

Java has had native code compilers at very least since Excelsior JET exists, and there is a whole story of commercial offerings, before GraalVM and OpenJ9 come to be, so a moot point in 2026.

Likewise, .NET has had NGEN since day one even if with limitations, and after several detours in AOT approaches, NativeAOT is in the package and cross platform, thus also a moot point in 2026.

But again, they aren't cool for the kids today.

Aurornis• 1 month ago

I love it starts with the usual hand waving,
And then gets merged.

The initial commit attached to that message was the start of the experiment. Are you reading the first message as if it was the last?

It was merged after 3 months and a huge number of incremental commits. The code that was merged was completely different than the code used to open the experimental WIP PR

Why is it a criticism that they started as a work in progress experiment? That’s how experiments work. It’s normal to push code as a work in progress PR and then add to it over time.

arcadialeak2• 1 month ago

It's quite frightening to see how an enormous 120KLOC pull request gets merged at once with very little public discussion or coverage by the devs after just 3 months (which IMO is very little time in relation to the amount of code). There used to be extensive RFCs and series of conference talks long preceding changes this big, e.g. React Fiber.

I support wholeheartedly the move to AOT-compiled languages but it looks like paying off the cognitive debt is going to be brutal on whichever team gets to maintain it in the long run.

herrkanin• 1 month ago

The public contract previously discussed in RFCs and conference talks hasn't changed. Coding language is just an implementation detail.

dwb• 1 month ago

Implementation details matter! Especially when reviewing the implementation.

arcadialeak2• 1 month ago

Nevertheless, it's also React team that came up with prefixes like __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED in their codebase because people couldn't stop messing with the internals. So any documentation about the new compiler would be anything but rejected by the community.

xedrac• 1 month ago

While this is true, the fact that it is Rust provides a much greater level of confidence than if it was Python or something.

bwfan1232• 1 month ago

Coding language is just an implementation detail

Sure, but what machine model do the public contract docs and RFCs target ? While the specific coding language is a detail, programming languages target a precise machine model. There is no machine model for english prompts and spec docs. So expect fuzziness - he-said-she-said bugs in your code - things that the LLM made up because the RFCs were not precise. And by the time you add precision to the specs, it has morphed into a new programming language with a machine model. In this usecase, since it is a port, the impact is mitigated because it is a clone of some existing functionality.

rvz• 1 month ago

Seems like all the "best practices" that were preached from these engineers for years are just disregarded and thrown out of the window with this reckless use of LLMs on high profile project.

Just creating permanent cognitive debt for everyone else with no-one else understanding what the code is doing.

lioeters2• 1 month ago

The cognitive debt is by design. Now everyone must use an LLM to maintain the codebase, because it's beyond any single human's capacity for understanding.

game_the0ry• 1 month ago

It was def ai generated work. If anything, this is a good use of ai.

jchw2• 1 month ago

If this works and passes all of the tests, then it seems like a done deal to me. LLMs are just too good at doing ports where they have a rigorous automated test suite or oracle to compare against. They're oddly bad at following instructions like "port this mechanically, exactly" - worse than a human for sure - but they seem to do a great job of sitting there and comparing results to find bugs for hours and hours. It's hard for me to imagine a world where they aren't used to assist ports, not just writing them but especially refining them.

I suspect this won't have as big of a shit storm as the Bun port in part just due to the input/output nature of the React compiler.

That said, while I use React still, I still have never tried the React compiler... So I have no idea how important this is. But you know, very few people are ever upset over faster iteration cycles or CI builds.

JCTheDenthog• 1 month ago

If this works and passes all of the tests

Only if the existing tests were actually useful in what they tested and covered.

jchw2• 1 month ago

Sure but it certainly seems that way. There were already thousands and this PR adds a fair bit more too.

It is possible to have thousands of tests and a lot of blind spots, but it's easier to get a grip on that using instrumentation like code coverage and indeed by using LLMs to prod at edge cases.

I am OK with trusting that it is likely the React team understands how to rigorously test based on how well-tested React itself is.

olalonde• 1 month ago

Interesting how LLMs are possibly putting an end to the era where we were increasingly trading off machine performance for developer productivity.

gilgamesh-OG• 1 month ago

This is a great point, previously the tradeoff was build in python in 2 weeks versus 2 months and even if your app performance is worse you built it faster and maintain it more easily. Now I am wondering, for all the devs who do not have experience in Rust, can they still maintain the code when the usage limits get hit? Since there is an automated test suite and easily verifiable results, this is a good area where you can be assured the compiler is working properly; however, if new features need to be added, I'm not sure how easy it will be for them.

absintini2• 1 month ago

Honestly it is a moot point. The benefit of languages like Python compare to Rust still hold. Algorithmic complexity rules the roost. For the hot path, write a C extension that is rigorously tested. Python you can iterate much faster same as any scripting language.

The AI can iterate faster in Python too, guaranteed, because you don’t have any compile time.

Also, this is how AIs already get stuff done: they write SCRIPTS to perform tasks in a sandbox with tool calls. This is the future, dynamic languages, not using static languages.

preg_match• 1 month ago

Dynamic languages like python or JS might be faster to build, but they’re certainly not easier to maintain. The type system still exists, it just changes at runtime (JS) and exists purely in your head (both of them). The value of static analysis, like reading code, goes down significantly.

As codebases grow it only gets worse, as more of your mind is filled with building a mental model of the type system.

That’s why you end up seeing crazy defensive coding practices in these languages. In PHP, I often see isset and instanceof spammed everywhere because nobody can garauntee that thing X is actually X all the time.

tracker1• 1 month ago

It depends... about the hardest part for me to keep track of in Rust is complex lifetimes... you can do things and organize in ways to reduce this cognitive overhead, but it may result in slightly less performant code.

The real boost to AI, is it can do a lot of things pretty easily, that you might not on your own... really thorough test suites, or even standing up a demo application just to test a single complex component. The latter I've done a few times now.

Rust itself seems to be very well supported by the coding models and is a pretty sane language to use. I cannot really comment on Go, as I've been using a lot more Rust as I have been targeting stand alone and wasm targets respectively, the latter really isn't a good structure for Go. I can say that C# is a really mixed bag, and would assume Java is similar.

bingemaker2• 1 month ago

I'm curious how reviews happen for such huge PRs (120k lines). Do reviewers sit and go through all these changes over days?

theappsecguy• 1 month ago

The reviews don't happen...

bingemaker2• 1 month ago

Trust and move forward?

insanitybit8• 1 month ago

If I had to guess, some humans skim things quickly for structural red flags, a bunch of LLMs do reviews based on various humans prompting to look for mistakes/ bugs, and then "tests pass == the code is good to merge".

odie5533• 1 month ago

These ports make me question the creators a little. They chose the wrong language to begin with, and then used an LLM to try to fix their mistake.

dust-jacket• 1 month ago

This feels like a bad take, IMO. Starting with something that gets you up and running quickly, then transferring to something else when things are more settled is a pretty standard practice.

ai_slop_hater• 1 month ago

And the great era of rewriting in Rust has begun (again).

ryanshrott• 1 month ago

The test suite gets you through the port. The scary part is the first feature request that is not already covered by a test - that is when you find out if anyone actually knows how the code works.

Port React Compiler to Rust

Related Stories