7 ms·
Port React Compiler to Rust
- ai_slop_hater 4mo agoAnd the great era of rewriting in Rust has begun (again).
- Trung0246 4mo agoCurious but can we use lean4 as port target instead of Rust?
- jon-wood 4mo agoI'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 4mo 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.
- HeavyStorm 4mo agoOh, PhDs, you're right, that's not approximately no one... It's probably approximately one. I like Lean (and more generally dependent types) but ffs Lean has a very, very small userbase for a project like this. GGP would have to really justifyv the benefits for such a switch.
- deleted 4mo ago[deleted]
- jcelerier 4mo agoApparently roughly ~150k math PhDs live on earth right now, assuming they all know Lean that's between 0.001% and 0.002% of earth population so quite closer to no one than one
- bhy 4mo agoI don’t think lean4 compiled code is as efficient as rust. For verification purposes, there are some tools allowing formal verification of rust code.
- giancarlostoro 4mo agoNever 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 4mo agoAre people actually using the react compiler? Haven't heard about since ages ago when it was extremely slow
- paavohtl 4mo agoWe 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.
- molf 4mo agoYes 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 4mo agoVery insightful, thanks. I just delved into it, starting here: https://react.dev/learn/react-compiler/introduction https://react.dev/learn/react-compiler/introduction
- DanielHB 4mo agoI 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.
- molf 4mo agoIt really does work very well in practice. A few things really help: - Lints [1] that flag code that cannot be (correctly) optimised. Usually this is obscure code that is too smart for its own good. But the compiler leaves it alone and flags it for review, so most things just keep working. - Lints that flag code that violate the rules of hooks. These rules became more critical to follow: failure to do so may break rendering. But non-compliant code can be easily be excluded from compilation [2], so you do not have to fix everything at once. - Popular libraries that are not compatible (yet) are flagged and excluded automatically [3]. The compiler is better than manual memoization, because 1) it is hard not to forget memoizations, and 2) the compiler's output memoizes more granularly than manual memoization realistically could. I have not found performance regressions. Not saying they're not possible; but we haven't encountered them. We have a very performance-sensitive project that used preact (chosen for performance) via its compatibility layer, that we switched to React + React compiler. Performance is noticeably better than with preact. Whereas previously the React-only version was incredibly slow even with carefully placed memoizations, because they were very hard to get right. [1]: https://react.dev/learn/react-compiler/installation#eslint-integration https://react.dev/learn/react-compiler/installation#eslint-i... [2]: https://react.dev/learn/react-compiler/incremental-adoption https://react.dev/learn/react-compiler/incremental-adoption [3]: https://react.dev/reference/eslint-plugin-react-hooks/lints/incompatible-library https://react.dev/reference/eslint-plugin-react-hooks/lints/...
- voidUpdate 4mo agoWhat is the react compiler written in currently?
- LoganDark 4mo agoUh, TypeScript?
- iammrpayments 4mo agoI 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.
- LoganDark 4mo agoYou may be right. I think Flow was a predecessor to TypeScript. I just checked out Flow and woah. First-class syntax sugar for React. Maybe cool. (If it doesn't break catastrophically in a sane build system like Vite)
- __jonas 4mo agoAre you sure? The React compiler is a fairly new addition to React, Flow is Facebook's old alternative to Typescript, but Typescript won the ecosystem in terms of broad adoption in the end. I think Flow is barely used today, I would be really surprised if they choose it for a new tool, even for a Facebook project. You may be thinking about React itself, not the new compiler? I'm sure there must be some flow in there still from back in the day.
- voidUpdate 4mo agoIsnt the benefit of rust that it's memory safe? Is typescript not?
- LoganDark 4mo agoThe benefit of Rust over TypeScript is that Rust is faster. TypeScript is memory-safe, but you can't really control where the memory comes from. In Rust you have structs, traits, references and all sorts of things to control both your memory usage and your memory efficiency, and you just don't really get that in TypeScript. Plus, in Rust it's a lot easier to utilize multithreading -- JS is notoriously tedious to parallelize (message-passing between JS workers is a bit annoying compared to structured concurrency in Rust)
- ramon156 4mo agoI 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.
- LoganDark 4mo agoWhy 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?
- molf 4mo agoOXC 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.
- LoganDark 4mo agoI 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.
- molf 4mo agoSo isn't not changing more sensible than changing to an arbitrary alternative? The current developers surely are more familiar with the Babel representation than OXC, so why switch?
- LoganDark 4mo agoWhat I mean is, if you're going to rewrite it in Rust, why rewrite Babel rather than leaning on the existing ecosystem? I know they're not actually rewriting Babel, just reusing the semantic layout of its AST, but it's feeling a bit like the MediaWiki parser situation to me (roughly "if we started from scratch today, we wouldn't choose to have it this way, but we started a different way before, and it's been a difficult path to get to where we want to be"). Maybe that's a fairly remote analogy but it feels similar.
- AbuAssar 4mo agonow we need to port angular compiler to rust!
- flufluflufluffy 4mo agoWe should compile Firefox to wasm, and run Firefox inside Firefox so we can Rust while we Rust
- AbuAssar 4mo agoYo dawg I heard you like to rust
- swiftcoder 4mo agoI can hear Gary Bernhardt saying 'YavaScript'[1] in my mind [1]: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- deleted 4mo ago[deleted]
- Klaster_1 4mo agoA 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 4mo ago<something> rewrite to rust using AI sound like meme now.
- giancarlostoro 4mo agoSpeaks 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 4mo ago> you focus on all the other programming logic Does that actually happen?
- insanitybit 4mo agoFor a model, yeah absolutely. You'll spend virtually 0 tokens on memory safety, which means your token budget gets allocated elsewhere. If you wrote a C codebase you'd need to allocate some portion of your budget towards memory safety.
- EddieRingle 4mo agoThey're not talking about the model, and they're not talking about token budgets.
- molf 4mo agoAfter 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 https://news.ycombinator.com/item?id=48132488
- absintini 4mo ago[flagged]
- IshKebab 4mo agoI'd love to see Asciidoctor vibe-ported to Rust! Have either of these people detailed their methodology & costs?
- benjaminleonard 4mo agoI 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 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.
- deleted 4mo ago[deleted]
- mohsen1 4mo agoShameless 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 https://github.com/tsz-org/tsz
- bhouston 4mo agoSo 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 4mo agoHow is using arenas complex? If anything it should make things simpler to understand to people who are not used to manual memory management.
- pmarin 4mo agoThe arena is replacing the javacript garbage collector not memory managament.
- logicprog 4mo agoI 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?
- pjmlp 4mo agoI 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.
- CamouflagedKiwi 4mo agoTBF 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.
- pjmlp 4mo agoJava 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.
- CamouflagedKiwi 4mo agoI think you miss my point a bit. It's not about what can be done with those ecosystems in 2026 - you mentioned what was done in the 2000's, and I'm suggesting one reason that wasn't perceived as "cool" is because of the whole VM / overhead requirement. Maybe technologies for that existed then, but they certainly weren't being used much - every experience I remember with Java back then was "download this jar, now go and get yourself a JVM to run it". And I do still think there is an advantage for this kind of tooling to choose languages that are designed to compile to a native binary. At best Java and C# are equivalent to Go and Rust here, maybe they are less "cool" but I don't see any reason why this rewrite would be better if it were to Java than Rust.
- arcadialeak 4mo agoIt'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 4mo agoThe public contract previously discussed in RFCs and conference talks hasn't changed. Coding language is just an implementation detail.
- dwb 4mo agoImplementation details matter! Especially when reviewing the implementation.
- arcadialeak 4mo agoNevertheless, 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 4mo agoWhile this is true, the fact that it is Rust provides a much greater level of confidence than if it was Python or something.
- absintini 4mo agoConfidence about what? That it works properly? Hopefully? Why don’t you read the 120k lines of code and tell us all how it works.
- jchw 4mo agoIf 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 4mo ago>If this works and passes all of the tests Only if the existing tests were actually useful in what they tested and covered.
- jchw 4mo agoSure 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 4mo agoInteresting how LLMs are possibly putting an end to the era where we were increasingly trading off machine performance for developer productivity.
- gilgamesh-OG 4mo agoThis 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.
- absintini 4mo agoHonestly 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.
- deleted 4mo ago[deleted]
- preg_match 4mo agoDynamic 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.
- bingemaker 4mo agoI'm curious how reviews happen for such huge PRs (120k lines). Do reviewers sit and go through all these changes over days?
- theappsecguy 4mo agoThe reviews don't happen...
- bingemaker 4mo agoTrust and move forward?
- insanitybit 4mo agoIf 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 4mo agoThese 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 4mo agoThis 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.
- ryanshrott 4mo agoThe 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.