How React Compiler Performs on Real Code

Thank you for the intro. As mentioned, my name is Nadia. Let me start by quickly introducing myself and talking a little bit about myself. I've been a developer for a very long time now. I worked for a small startup at some point. I worked for Atlassian for a few years on a product that some of you probably know and probably love called JIRM. I'm a bit lazy and also I love to travel. So a few years ago, I moved from Australia to Austria just because it's easier to spell. I'm a little bit of a nerd and one of my nerdy hobbies is to investigate how things work and then write the results down. I spent the last few years investigating everything that I could about performance, about re-renders, and React. I wrote a bunch of articles on this topic, I did YouTube videos, I even published a book, half of which is dedicated to the topic of re-renders, memoization, and how to control them. And during those years I kept seeing visitors from the future probably who would kindly inform everyone around them that memoization is not needed anymore because of React forget, currently known as React compiler. This April, our timeline finally caught up with theirs. React team released the compiler to the public and of course I had to try it and see the future for myself. So I tried the compiler on a few synthetic examples, I ran it on a few real apps, measured how it performs and what it does. Of course, I wrote it down and now I am happy to share with you how the future really looks like. So this is what the talk is all about.

What is the problem the compiler solves? Are there any downsides to it? How it performs on synthetic examples and how it performs on real life code?

Let's start with the problem. So what exactly are we trying to solve here? Here is our beautiful user interface, it's really nice. When some new information comes in there, we want to update it. To do this in React, we trigger what is known as a re-render. Re-renders in React are cascading, as you probably know. Every time a re-render of a component is triggered, it triggers a re-render of every component inside and then every component inside this component until the end of the tree is reached. If those downstream re-renders affect some really heavy component, our app becomes slow. So that might cause performance problems.

To fix this, we need to stop this chain of re-renders from happening. One way to do it in React is to tell this component that it doesn't change and it can skip re-renders and re-render of every component inside. And of course, as always in React, there are multiple ways to do it, but one of them is memoization. Memoization starts with the React memo, a file or the component given to us by the React team. It wraps our original component and then renders itself on its place. Now, when the React reaches this component in the tree, it will stop and check whether its props have changed. If none of the props changed, then re-renders will be stopped. If even one of the props changes, React will continue with the re-renders as if no memoization happened. That means that for the memo to work properly, we need to make sure that every single prop on this component is exactly the same between the re-renders, otherwise, it just will not work.

For primitive values, it's easy. We don't need to do anything other than not changing them. For objects, arrays, and functions, however, they need some help. React uses referential equality to check for anything between re-renders. And if we declare those non-primitive values inside the component like I did here, they will be recreated on every re-render. Reference to them will change and memoization won't work. To fix this, we have two hooks, useMemo and useCallback. We will drop arrays and objects into useMemo, functions into useCallback, and then those hooks will preserve a reference to the values between the re-renders. And next time a re-render here in the parent happens, the very slow component will not re-render. And the chain of re-renders will be stopped. That is enough of the theory for today, I promise. This is a very simplified explanation, but as you can see, it's actually already quite complicated.

This is a very simplified explanation, but as you can see, it's actually already quite complicated. So anyone who used those hooks in real life knows how hard it is to trace those changing references and how quickly our beautiful apps turn into an incomprehensible and unusable mess of useMemo and useCallbacks. So solving this situation is React Compiler's main promise.

The compiler is a tool given to us by the React team. It plugs into our build system, grabs the original component code, and then tries to convert it into code where components, the props, and dependencies of hooks are memoized by default. The end result is as if our normal React code behaves as if everything is wrapped in memoUse, memoUseCallback, which is already very cool. But it doesn't actually do this. It doesn't wrap things blindly. It's much smarter than that.

For example, something as simple as this will be transformed into this. Notice how onClick is cached at the very bottom, but the data object is not really cached. It just moved inside the if statement. However, if I reference this data inside onClick, the compiler understands this and rearranges the code to sound like this. Mechanics of all of this are absolutely fascinating. However, in this case, I'm more interested in practical applications of this engineering miracle.

So more specifically, I want to know whether our expectations from the compiler match the reality. And three main questions immediately pop into mind for almost everyone. First one is, what about the initial load performance? One of the big arguments against memoizing everything by default has always been that it can negatively affect initial load, because React needs to do much more stuff in advance where everything is memoized. Second one is, will it actually have a positive impact at all? How much of a problem re-renders really are? And the third one is, JavaScript is notorious for being fluid and ambiguous. Is the compiler smart enough to really catch absolutely everything? Is it true that we will never have to think about memorization and re-renders ever again? Before answering those questions, let's quickly check out the compiler on a few synthetic examples. Maybe, who knows, maybe it doesn't work at all.

So our first example, we have a component with a dialogue, a state for this dialogue, and a button that can open it. And a very slow component somewhere underneath. So let's say it takes five milliseconds to re-render. Normal React behavior here would be to re-render everything, including the very slow component when the state changes. And as a result, the dialogue pops up with a delay because of the slow component. If I wanted to fix it with memoization, I would have to do this. Just wrap it in the React memo. Let's get rid of it and enable the compiler for this code and see what will happen. In the dev tools, I see the magical memo appearing everywhere, the blue stuff.

That means that components are optimized by the compiler. And now all I need to do is just put the logger inside the very slow component and try to trigger the dialogue. As you can see, only the button that it renders, the dialogue, well, the dialogue shows up instantly. If a slow component doesn't re-render. So that's the first win for the compiler.

Let's now make it a little bit more complicated and add some props to the very slow component. A standard stuff, an object, and a function. So if I wanted to memorize it manually, this would be the classic trio. Use memo, use callback, and memo itself. Let's again get rid of it and apply the compiler to the code. The end result, exactly the same. Only the button re-renders. Slow component doesn't re-render. The dialogue pops instantly. I'm adding another win to the compiler. Good job. I love it.

Third one, and that is the fun one. Let's try on something even more complicated before going for a real app. And what if the very slow component accepts children? Off the top of your head, think how would you memoize it? I will give you a second while I think. Who thinks it should be this? Raise your hands. Anyone? Cool. Very, very smart people here. Because yes, this is incorrect. Children here are nothing more than syntax sugar for a prop named children. Child memo is exactly the same as syntax sugar for an object that looks like this, that references child memo component. So what we have here is a non-memoized prop on a memoized component. Very slow component, memoization will not work, and it will re-render with every state change. To memoize it correctly, we need to do this. We need to use memo as if we would use it on every object.

This pattern is the most counterintuitive pattern in React, and even the most senior developers often get it wrong. However, what will happen with the compiler? Can it handle it? And the same story as before. The compiler does a really good job. The dialogue pops up instantly. No slow re-renders are happening. Another win for the compiler.

Now to the good stuff. Small examples like that are easy, but I want to test it on a real app. The real app looks like this. It's an app I've been working for a few months. It's completely new. I've fully typed scriptified, no legacy code, only hooks, and everything is best practice, more or less, because I'm a bit lazy. The app has a few pages. In total, it has around 15,000 lines of code. Not the largest app, but I think it's good enough for a proper test. Before turning on the compiler, I run a health check and ESLint rules provided by the React team. Those are the health check results. No incompatible libraries, and zero ESLint violations. And finally, I haven't done any performance optimizations there yet, exactly so I can try out the compiler for this talk. The app is as prepared for React compiler as it can possibly be.

Testing conditions. I used Lighthouse to measure the initial load and interactions performance. All measurements are five times, so I'm actually showing you the average of those. All measurements are run on production build in the mobile mode of the Lighthouse, where CPU is slowed down four times. Okay, so first question to answer, how the compiler affects initial load. First page to measure is the initial landing page. It's beautiful and actually quite long. Before the compiler, the results were like this. Almost everything is green, except for one red thing. I will fix it later.

Now with the compiler, I have lots of memos, that means compiler is working, and here are the stats. That's not so bad. I ran it on a few more pages just to make sure, and the results were more or less the same. So some of the numbers go a little bit up, some of them are a little bit down. Nothing drastic. So I think I can add another point to the compiler and answer the very first question, is the compiler seems to have a very minimal impact on initial load performance. So that's good.

Second question, how much of an impact will it have on interactions performance? For this one, I use this page. The app is actually a showcase of a UI components library. Here we see a preview of a very large component, actually the whole settings page, and over there I have a dark mode switcher. As you can see, everything re-renders when I switch between light and dark mode. Before the compiler, the numbers looked like this, which is a bit ouch, it's a bit red. I enabled the compiler and wow, that is very impressive, and actually it's too good to be true for me because I'm a very suspicious person. How exactly did that happen? I'm not the worst developer in the world, trust me. So yeah, I need to investigate this. The answer is here. This is the code for this entire page.

The thing that renders the preview of the big components is this. The preview is sent as a string, the entire page here is just really tiny components. I literally have here the synthetic example from before, where we have a very slow component with some minor props. So I will add another point to the compiler. It's very cool that it was able to pick it up, but also, I feel a little bit like it's cheating because clear situations like this are quite rare in real life. So in real life, we will have a bunch of smallish components and the job for the compiler will be much harder. The next page is closer to real life. Let's take a look. I have a header here with some stuff, footer and a long list of cards in between. The quick filter at the top controls which cards are shown, and as you have seen, when I click on checkbox, for example, everything re-renders. So without memorization, the entire page re-renders, all the cards re-render. The stats for this one looks like this.

The stats for this one looks like this. It's okay-ish, it's green, but there is some room for improvement. Enabling the compiler and checking the numbers is good, but it's actually more believable to me. But also, it's very interesting because I actually expected it to be better because this list is very long, and if all the re-renders in this list were eliminated, adding just a few new cards for the checkbox should have been actually instantaneous. So let's investigate what is happening here. And what is happening is the list is actually still re-rendering, even with the compiler enabled. That's not so good.

Okay, what's going on with the code? That's not so good. Okay, what's going on with the code? The first ones, nothing criminal. I just have an array of items, a map over the array, and a render card component. I even have the correct key here, so no arbitrary props, everything is coming from the data array. So let's investigate. The very first thing that I do when debugging compiler issues is to re-implement memorization manually with the classic tools. In this case, all I need to do is just wrap the card in the react.memo. And if the code is good, the existing card should stop re-rendering, and that would mean that the compiler bailed on its components for some reason. I did that, and this didn't happen. That means that's not the compiler's fault, actually. Something is deeply wrong with the code itself.

I wonder if anyone can guess, because the code is the most standard code that you can see in React. Okay, so let's solve it. As we know already, if even a single prop on the memoized component changes, the memoization will not work, and re-renders will happen. So something is probably wrong with the props here. All of them are primitives except for this one. It's an object with two strings inside. So it has to be its fault. But it's also a little bit weird because it's not like I'm recreating it inside the component every time. It's just the data that is coming from an array that is coming from a React query. So should I blame Dominic and React query then? Let's take a look at this code. This is the code that fetches the data. We all know React query now.

It's a beautiful library. I love it. It simplifies data fetching and caching. So we have a key to identify the cache entry, and we have an async function that returns some data for this key. Usually, it's just a fetch or some fetch variation. If it's called with the same key, it returns the data that it already has without doing a fetch again. So what is happening here in my case? I have a dynamic key. It depends on selected filters. And I have a fetch function that returns some data.

When only the button in the quick filters is selected, the key is this. The library that returns an array that is associated with this key. When I turn on the checkbox, the key is this. The library returns a completely different set of data that is associated with this key. It doesn't merge them together to preserve the reference to the internal objects because how would it know to do it? And I never told it to do it. So I cannot blame the React query for this one, unfortunately. All of this is my fault. React query does exactly what it should do. No one to blame, but as a result, I have a different array with different references rendered on the screen that happen to have the same data for the most part.

And one piece of this data is an object that is passed to a probe to a memoized component. The easiest way to fix it, to fix memoization here, is to just spread this object and turn it into primitive props. Sounds like this. So the memoized component receives only primitive values and those don't actually change. So a bit of refactoring and no more unnecessary renders. Okay, so I'm not the worst developer in the world. Let's make sure that it was actually worth it and let's measure it. So this was before and after the compiler. Now, the last measurement after the manual fixed. I feel it's a mic drop situation. Humans are still better than robots. They will never take over the world.

I will give a win for myself this time. Okay, so that was the interactions. I think it's safe to say that the impact of the compiler is noticeable but varied from page to page and humans are still better if they really try.

Final question. Is the compiler smart enough to really catch absolutely everything? We already see that the answer is probably no. But to test it a little bit more, I collected a list of noticeable re-renders in my app and checked how many re-renders are still present after I enabled the compiler. I had something like nine of them. Stuff like the entire draw re-renders when tabs change. The end result was this. I had two cases where absolutely every single re-render was solved, two cases where none of them were solved and five cases where it was like in the situation before. Almost all of them but sometimes not.

The cases where nothing was fixed was the most interesting one because the compiler bailed on the entire component because of this line and this line only. I never even used the filtered data, I just added this line and it's just oops I cannot do it. And the problem here is that Fuse is an external library that does search for you. So the most likely reason here is this library is just doing something deeply incompatible with the compiler, unfortunately. And speaking of the external libraries, just a few days ago React team confirmed that external libraries will not be transpiled by the compiler. So don't expect miracles if you consume in some external library.

So I'm going to be cruel, sorry. I'm going to take one award from the compiler for this one. Because the answer to whether the compiler can catch absolutely every singular re-render is sorry to know. Because there will always be some external libraries that do some really weird stuff or they're just incompatible with memorization or there will be some legacy code that again does some really weird stuff that the compiler doesn't know how to process. Or the code that I had, which is not exactly wrong but it's just not fine-tuned for memorization. So let's recap quickly what we were investigating and how the compiler dealt with it. Initial performance, check. No impact, no bad impact. Initial load performance, I would say also check. Interactions, interactions performance, check. I saw good improvements there. Some of them were really good, some of them just a little bit but still really good. Can it catch all re-renders? No and probably never will.

So the biggest question then of this year, can we forget about memorization soon? Does the previous slide mean that the answer to this question is no? Not necessarily because it really depends. If performance of your app is not the most important thing in the world for you or maybe it's okayish but could be improved but I don't have time to bother, then enabling the compiler will most likely make it good enough at a very low cost. The definition of good enough and low cost is of course going to be up to you but I suspect that for most people turning on the compiler and forgetting about memorization and all those hooks will be just enough. However, if good enough is not so good for you or you need to for some reason squeeze every millisecond out of your app, you will be welcome back to manual memorization. For you the answer will be no. You cannot forget about it. You would have to know everything that we know about memorization now. Plus on top of that you would need to know what the compiler is and what it does and how. So your job will become slightly harder but I think there will be very very few of you who would actually need it so that will improve your job safety I would say in the long run.

So it's also a good positive result for you. I hope this was good enough for this presentation. If you want to read more about memorization and re-renders and everything, here are the links. If you want to check out the very very early version of the components I'm working on, you can do it here. It's very much work in progress so please don't judge too much. And if you want really cool cat themed stickers, catch me after the talk. I have quite a few of them. Thank you. And that is the end.

Well let me pull out my little questions here. Remember you can ask questions on slide.do and let's dive right into the compiler. There's a couple questions here. So this one says what manual optimizations work best with a compiler in a large React project and any tips for finding bottlenecks? So manual optimizations work best moving state down and just isolating it as much as possible so you never have components that handle a lot of state. Also extracting state instead of passing through props into external library like something like Sustan for example and then memoizing the selectors. Yeah we have the Toka thing. Yeah. It was about finding bottlenecks. The state thing is good. Do you think people or developers are going to start changing their behavior based on what compiler is good at? We will see I guess. Because that list example you did, that was just the little component. Yeah.

I could see people trying. So what I'm slightly afraid of is that people will relock and say oh the compiler will just handle everything. So it might lead to messy code in the long run. But I'm confident in the group here because actually no one raised their hand on the memoization problem. I'm very impressed. Good job. Yeah.

Is there a way to if the compiler doesn't do it for some reason to force the memoization? Yeah we use the hooks and React memo. Just manual memoization like good old times. Like the good old days. Vintage. So adorable. Very nice.

How does the re-render system work when the props don't change but a context provider does? Context if we're talking about React context. Until very recently it would just force re-render on absolutely everything. Even if you don't use the data. But I think there was some talk from React team to introduce selector stub functionality but I'm not as sure. But currently it will just re-render everything that uses context. Interesting.

Can you think of any reasons to not use the React compiler? To not use the React compiler. It might be slightly scary in the very large and very old apps because who knows what the effects will be of this manual memoization. So for those apps I would just say enable it file by file or folder by folder and then do a lot of testing. Take it easy. Yeah, take it easy and try stuff. I like that advice actually. It's very sensible. This is a great one. We're going to step outside of the React compiler for a second. They loved your slides. They're very cool.

A lot of good cats. How do you make them? Lots of practice. They're incredible. Good job. With software do you use Keynote? Keynote. Keynote and Magic Move for most of them. Yeah, Magic Move. Who doesn't love Magic Move? Steve Jobs himself.

Let's see. What else do the people have? Has the compiler in your explorations ever tried to fix something and actually introduced a negative behavior or a bug? Not for me. There probably is a possibility. I saw people saying that something happened but it's very, very rare from my understanding. And it works for like Instagram and Facebook and a few larger apps so I'm sure they found almost everything that can be. Yeah, well I would hope.

And then when you enable the compiler on your app where you've already sort of previously used Callback or Memo is it bad practice to still have those optimizations? Do we have to strip them out to use the compiler? As far as I remember you don't have to. It will just either use them or just convert them into code. So you don't have to remember them. But probably we have a React members team who remember here. So let's make sure to go ask them the really yeah really really deep questions. Sorry I'm just dropping things on you. We don't have a lot of time so I'm actually going to ask you just one more question which is what is your process for doing all these like deep dive explorations you did for your book and now for this talk. Do you have like a system of research? Do you look at the source code a lot? Do you more run it or more read it? That's like half an hour answer.

TLDR. TLDR. So I usually just have an idea that comes from doing regular stuff. Then I start exploring this idea. I start writing examples for it. Then I start writing the article and then I'm throwing away all the examples because they don't actually match the article and rewrite them completely from scratch. But then how I rewrite them I usually discover some new things so I have to then rewrite the article again. So it's like iterative. It's basically agile. Yeah basically agile.

Will you remind everyone where they can find you online on Twitter or LinkedIn? Advanced Dev. A-Dev Nadia. Thank you so much Nadia for that talk.