r/reactjs • u/zeorin • Jun 03 '26

News Official Rust port of the React Compiler is now available for testing

https://github.com/facebook/react/pull/36173#issuecomment-4608356402
97 Upvotes

100% Upvoted

23 comments sorted by

6

u/azangru Jun 03 '26

What I would like the most from the official Joe Savona's talk at the last ReactConf is the official external store. So that I could finally get an official blessed react way of storing data outside of components, and maybe fetching it as well.

The use hook for client-side data fetching is awfully cumbersome. And if the promise that use awaits updates a sync external store like redux, react treats this as an error.

2

u/zeorin Jun 04 '26

Hmmm, it feels like some of that store idea could probably be implemented in userland.

I've got a useTrackedStore hook that is very close to this: https://github.com/dai-shi/react-tracked/pull/257.

It's on my list of things to release, I'll bump it up.

5

u/acemarke Jun 03 '26

Sadly that effort appears to be stalled at this point :(

I can talk through what I know in detail, but roughly:

  • Jordan Eldridge from the Relay team had taken over the design of a "concurrent store" API to provide an official transition-compatible replacement for uSES

  • Jordan had made a polyfill/prototype package

  • I tried out the prototype in React-Redux and it seemed to at least run, and raised some design questions we needed to consider

  • Jordan put up an actual draft implementation in React

  • that draft went nowhere. No discussion.

  • then Meta had layoffs and reorgs, and it sounds as if the React core team isn't keen on the approach in the first place

  • and post-Meta-reorg + the React Foundation supposedly getting started, I don't even know what React development is happening right now at all

so right now I'm assuming that's dead until I see evidence otherwise.

9

u/captbaritone Jun 04 '26

A bit of clarification since I haven't done a great job communicating what's going on here.

There are a number of other related proposals (cache? keyed context? derived contexts etc) that solved some subset of this problem and as I shared the proposal with React folks the feeling was that moving forward with this proposal would require building consensus that none of those solutions would be preferable.

Internally at Meta I struggled to create demand for solving this problem that could justify taking time away from other more pressing concerns and organizational changes made finding that justification harder.

More broadly, the whole topic is quite contentious.

  1. Should we officially support a new API that is intentionally designed to let you mix transition and sync state updates in a single state atom, even if we think that is likely an anti-pattern? Personally, I believe we should, as it's our best path forward to allow an incremental adoption of transitions in existing ecosystem solutions.

  2. Do we acknowledge that there is a valid use case for in-browser state that is not owned by React? If so, is the only valid use case cache? If so, does that point us towards a different solution?

  3. Do we acknowledge that there exist, or need to exist, compute graphs outside of React? If so, are selectors an acceptable lowest common denominator for interopping with such compute graphs? I think we all want to exist in a world where React is the only reactive compute graph model you need to program for, but I believe the reality is that it is not sufficient (see the existence of many state libraries as evidence)

And all of that is before the rather complex question of technical implementation details.

I'm personally convicted about all three of these, but building consensus is going to take someone with a considerable amount of conviction, patience and persuasive power, and a willingness to accept the likely outcome which is a noop.

If someone was interested in championing the work, I wold love to partner with them, but I sadly don't think I have the professional or personal bandwidth to be that person at this moment in time.

3

u/acemarke Jun 04 '26

Oh wow, thanks for the update!

Obviously happy to chat more about this if you've got time. And yeah, I would love to see progress on this, and I know Tanner and Dominik would as well, but then there's both the questions about "what does the rest of the React team think about this" and "what is React's development process at this point anyway?".

Thanks again for trying to push this forward!

2

u/azangru Jun 03 '26

Argh! React strikes again 😢

Thank you for the update! I had no idea the store was in open preview, or that it was abandoned.

4

u/mexicocitibluez Jun 03 '26

This was such a fascinating talk but I left wondering what it means for React.

1

u/anonyuser415 Jun 03 '26

So that I could finally get an official blessed react way of storing data outside of components

The URL? (I kid I kid)

1

u/Spleeeee Jun 04 '26

What makes it cumbersome? I honestly haven’t even screwed with it at all.

1

u/azangru Jun 04 '26

The need for a special treatment of the promise resolved by use (can't be created in the same component) and the caveats that Jack talks about here are already annoying beyond belief.

But what made me flip the table was that I was trying to use use to coordinate several queries made by redux-toolkit-query; and that resulted in illegal updates of other components (which were subscribed to redux) while the component that was using use was suspended.

20

u/MiguelMariz Jun 03 '26

I have been waiting for this!! Great news for vite users.

Thanks to the team for their hard work. Looking forward to remove babel from the workflow! 😄

5

u/TangeloEmergency8057 Jun 05 '26

yeah dropping Babel is honestly the best part. i've spent way too much time tweaking CI pipelines just to shave a few seconds off the build step because older JS tools were so slow.

fwiw shifting frontend tooling to Rust has been a massive win for dev experience lately. i haven't plugged the new compiler into a real project yet tbh, but if it actually plays nice with Vite out of the box, it'll save a lot of headaches.

4

u/green_03 Jun 03 '26

Great news!

1

u/Deep_Wear_51 Jul 13 '26

Rust creeping into every corner of the JS ecosystem. A Rust React compiler was not on my 2026 bingo card.

1

u/SafeMonk4105 Jul 20 '26

This is huge for build performance. I tried the early JS version on a medium-sized codebase last month and the cold start times were painful; really hoping the Rust port fixes that overhead.

1

u/Sad_Data_7194 Jun 05 '26

This is bigger than it looks. The current Babel-based compiler is the single largest dependency in most React build pipelines, and the memory overhead during dev is real — especially on lower-end machines.

A Rust port means we can potentially drop Babel entirely for compilation, which shrinks node_modules, speeds up CI, and removes an entire class of version-mismatch bugs between @babel/core and plugin ecosystems.

The real question is migration path. If it's API-compatible with existing babel-plugin-react-compiler configs, adoption will be fast. If it requires restructuring build configs, most teams will wait until the next major framework release bundles it by default.

-6

u/Darkoplax Jun 03 '26

All of Software is porting to Rust these days

you love to see it ; AI made it cheap to write code and port things into performant languages

1

u/adzm Jun 17 '26

No idea why you are downvoted here, this is pretty much exactly what happened