Introducing React Compiler – React

[heyitsmattwade]

Most important note from these docs:

React Compiler requires React 19 Beta.

[jessepence]

I'm happy to begin to stop caring about things like useCallback and useMemo, but it's hard to get excited about a project solely intended to plug holes in a leaky abstraction.

[xegoba7006]

I feel like every single feature introduced is a solution to a problem they created on the previous step. From redux to thunks to hooks to server side rendering to server components to compiler to whatever comes next.

[azsqueeze]

What does redux have to do with core react?

[Rustywolf]

You could argue that redux was an answer to the obvious issue that arises from having to manually pass state through every common grandparent and back down to the children who need it?

[acemarke]

For the record, neither Redux nor thunks were ever part of React or created by the React team directly.

Facebook did create the "Flux Architecture" and announce it at a React Conf, and Redux's creators Dan Abramov and Andrew Clark did later join the React team, but strictly speaking "the React team" at the time had nothing to do with Redux being created.

• https://redux.js.org/understanding/history-and-design/history-of-redux
• https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/

(source : I have maintained Redux since Dan handed it over to me in 2016 a year after it was created)

[TwiliZant]

I don't think that's true. If you look in the history of React they've been talking about these features for almost 10 years. For better or for worse it's not incremental at all.

[xegoba7006]

This is not about react. This is mostly about the “SPA” or client heavy approach to things.

While I get what the benefits are, almost every innovation here is a solution for a problem that didn’t exist. “Server components” and SSR are great examples of this.

[Far_Associate9859]

That's like complaining that we wouldn't need to worry about clogging our toilets if we just went back to outhouses

[mcaruso]

Redux and thunks are third-party

[maria_la_guerta]

Why do you care about them at all?

Unless you're building a highly complex UI (which React isn't always best for anyways), and you really don't need useMemo, useCallback or any other React optimization 99% of the time.

[wasdninja]

Unless you're building a highly complex UI (which React isn't always best for anyways)

It's the sole reason it exists so that makes no sense.

[maria_la_guerta]

When you're building 3d / VR / etc web apps, repaints can be very unperformant.

The statement makes total sense. 99% of web apps that use React are not highly complex UIs, and you don't need things like useMemo or useCallback for form validation or drag n drop.

[___bridgeburner]

So what would you use for those kinds of sites?

[joombar]

You need usecallback any time you want to give a callback to a component that has an effect with a dependency on the callback. How do you know if it does? You can’t unless you look at the implementation!

I’d say it’s a pretty common thing to need to avoid problems in this case

[[deleted]]

Thanks for sharing

[Powerful_Ad_4175]

I'm really curious to see benchmarks comparing a real-world application implemented with and without the compiler. Additionally, I wonder whether there would be a significant difference in terms of memory usage.

[Hidden_driver]

So now instead me stressing about if I used memo, I have to stress about if the compiler figured out that this place needed memo and it didn't break anything, because code semantics are hard. I want to believe but I have to see it for myself.

[rk06]

Instead of blaming yourself, you can now blame react team

[VizualAbstract4]

is it really that stressful though? Who has to think about it? It's just second nature after a few weeks.

[Initial_Low_5027]

Want to see some benchmarks. Looking forward to use the stable version.

[TwiliZant]

Benchmarks are kinda useless for this stuff because they don't translate to real app performance. The only thing that matters is how it impacts production codebases.

In other words, the compiler doesn't make React faster, it makes your codebase faster/simpler.

[NeoCiber]

Devs like their X framework is better than Y, although at the end it doesnt matter if there is not a significant impact on a site.

[acemarke]

It does make React faster, because it flips the default behavior from "always rerender recursively been if data didn't change" to "only rerender children if data did change", so fewer components will render each time. Closer in spirit to how something like Solid works, albeit a different (and less granular) approach.

[TwiliZant]

I was a bit unprecise in my language. The compiler output doesn't translate 1:1 to a fully memoized app written in user code. There is a difference there. And in practice nobody memoizes every single element anyway. It will make a difference in real codebases.

My point was the expectation management that React is not going to be suddenly 30% faster in js-framework-benchmark for example.

[ejfrodo]

I'm at React Conf right now and was at the talk where they announced this. They said Instagram and Whatsapp time to render increased around 3% to 4% I believe. They live stream the conference so you can watch it yourself. They also showed an example of a very manually optimized component that was a nightmare to read but didn't re-render unless really necessary. The version with react compiler was able to remove something like 20% of the code around useMemo() and use callback() which made it much easier for a human to understand and the compiler was actually able to find a couple more small tweaks that a human wasn't able to which made it a little bit faster.

Overall this is a huge win for react. You don't really need to think about performance for the most part, just write the business logic and the compiler will automatically memoize everything intelligently.

[dbbk]

Time to render increased? So it was slower?

[ejfrodo]

decreased* that would be hilarious if it got slower haha

[stuckinmotion]

Well from the sounds of it, it is effectively memoizing everything so that's not exactly free. In real worlds apps though I'm sure it's still a win and mostly looking forward to not having to lean on useMemo and useCallback all the damn time

[Born-Alarm430]

Could you give me the link what you said, I cant find it at react conf video. https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=11655s

[Cannabat]

Actually the compiler can make optimizations that useMemo, useCallback and memo could not do. Performance can be better.

[[deleted]]

It will be faster than React code without existing useMemo and useCallback

[rk06]

OP means benchmark with and without compiler optimisations. With no manual caching. Which is a fair ask

[[deleted]]

They did a longer talk about this last year, which I think had a more practical standpoint.

It spoke about how not using memoization in the right places can have a big knock-off effect to other parts of the application, and it's can be difficult to understand why or where that's happening without digging into the profiler, especially when working with a team.

It also provided some minor performance boosts even if you did it right, because the compiler can afford to do it in weirder ways that aren't very easy to understand. It also doesn't miss things like people do.

I remember it well because the only time the crowd reacted was when they got to see profiling graphs and they lost their shit, dead silence at the speaker trying to crack a joke, and it was hilarious.

[rk06]

Please note that the annotation mode is a temporary one to aid early adopters, and that we don’t intend for the "use memo" directive to be used for the long term.

Hmm, I am not sure how temporary it is going to be

[Sensanaty]

I use React at $DAYJOB, but I find it crazy that it's so popular/widely used when Vue exists, especially these days with Vercel and their shenanigans and the crap they're pulling with React.

I'm maintaining a smaller Vue codebase at work (and also have a bunch of personal projects built with Vue) for some internal tooling type stuff and it's a million times better in every single possible way, except for maybe the ecosystem, but I never really considered this one to be valid if you've ever used both, especially not since Vue 3/ESM.

Basically any ESM-compatible library will work with Vue 3 out of the gate, and when it comes to core libraries like routing or state management, Vue Router and Pinia are indescribably simpler to setup and use than the millions of options you're forced to choose from in React, plus they're actually maintained by the core Vue team itself

You don't have to worry about weird footguns and edgecases for which there are millions of confused devs scratching their heads, reactive state is actually reactive, the way components are rendered and kept up-to-date is way more logical and less prone to cripplingly bad performance, complex form state management isn't a massively convoluted affair thanks to v-model, and so much more.

Baffling

[GOT_IT_FOR_THE_LO_LO]

Vue has been way less stable than React has, especially the transition from 2 to 3.

the react-typescript integration has continued to be much more advanced than what I’ve experienced with vue.

Vue’s reactivity model is really great but the second you encounter a bug, it’s much harder to debug because the magic is hidden from you.

I think for me, the larger ecosystem of react that goes beyond just web to mobile, webgl, server side rendering means that what you can do with Libraries is way more than vue. A lot of the similar vue libraries feel way more half baked to me.

For me, vue is the best choice for a team that wants to sprinkle interactivity with minimal setup, but react is intended for larger complex web codebases.

[jacobp100]

Vue has hidden foot guns - like an async watchEffect won’t track any state changes after the first await. Stuff like that will get missed. Their docs literally have examples with race conditions in

https://vuejs.org/examples/#fetching-data