A Guide to React Compiler Rendering

All right. Good morning, Amsterdam. My name is Marc Erickson, and I'm very excited to share with you a guide to React compiler rendering. A couple of quick things about myself. I'm a senior time-travel engineer at Replay where we built a time-travel debugger for both humans and agents. I will answer questions anywhere there is a text box on the internet. I help moderate the React communities. I collect interesting links and talk about them in places like the This Month in React podcast. I write extremely long blog posts. I recently wrote an article about my own emotional experience using AI as well as my workflow, and I am a Redux maintainer. It is almost exactly ten years that I've been working on Redux. But also most people know me as that guy with the Simpsons avatar, which is actually now slightly out of date. I had LASIK back in January.

Why are we talking about React rendering today? I am a firm believer that it is important to know fundamentals of the tools we are using, and that's even more true in an age of AI. Even today, I see a lot of people with misconceptions about how React actually works. When we talk about the React compiler, it flips some of that default behaviour upside down. You need to make sure you understand the fundamentals first. And this is really science, not magic. So the goals for today, we will spend some time reviewing some fundamentals of React behaviour, we are going to look at the options we have available for optimising React performance, we will look at what the compiler does and what the output looks like, and then we will finish by talking about how it changes our mental model of how to use React. The slides are up on my blog, blog.isquaredsoftware.com, and I will have the link there again at the end.

Back to the beginning. What is rendering? Rendering is the process of React asking your components, what do you want the UI to look like at this point in time? Normally, the render output is based on the current props and the state for that component. When we write components, we write this angle bracket JSX syntax that we have seen and all know and love, and when we write the JSX syntax in our code, at build time, that gets converted into create element calls, and then at runtime, your component executes, it calls create element, and it returns these element objects that have the component and its props and the children. If you've ever heard the term virtual DOM, that's really just describing these element objects. So during a render, React loops over all your components, it collects all the element objects in a tree, and then it diffs the old and the new element trees to figure out, are you asking for anything different in the UI this time? Now, a very, very important point, if there's anything you remember, please remember this slide right here. React's default behaviour is that when you render in one component, you call set state, React will keep recursing down through all the children below that. So if I call set state in the app component up there, it is going to continue through all four of the children below that. If I call set state in the inspiration component, it will also render the two children below that. It keeps going down through all the children below. Now, when we render, this does not always mean that there's an update to the DOM.

React originally talked about rendering is like redrawing your whole page, but in reality, it's were there any differences? Are there any requested changes to the UI? So it's possible to render a component, have it request I want the same output as last time, and if you think about it, then that's kind of wasted effort. We went through the process of running the component and outputting the elements and nothing actually needed to change, and so we can kind of think of those as wasted renders, and usually that's if there's the same props in the same state, then we're asking for the same children as last time. But overall, rendering is not a bad thing. It's how React knows if there's anything that we need to update.

Now, React does have a number of rules that you're supposed to follow. We're not supposed to mutate existing values like props and state, you should not be generating random values while rendering, and especially don't ever use those as keys. It is okay to mutate values you created during the rendering process. A console log is technically a side effect, but that's okay, that doesn't break anything. There are times you can lazily initialise a ref object. You shouldn't be triggering requests while rendering, unless you're doing suspense, and in theory you can call set state while rendering but only if it's conditional. There are some things you have to keep in mind while rendering.

So how do we actually optimise performance? React gives us some tools to do that, and the main way you optimise is by saying if the props for this component have not changed, don't render it. And if we skip this component, that means we also skip all the children inside of it. So the main tool React gives us is the memo function. If you've ever heard the term higher order component, it just means it's a wrapper around the actual component that you have. So memo is a higher-order component that automatically looks at all the incoming props, and if none of the props have changed, it skips this component. Now there is one other very little-known trick that is built into React that has been around really since the beginning, but nobody knows this exists. If you're rendering a component, and, as part of the output, you include the exact same element object reference that you had the last time, React will get to that part, and it will say this is the same element. I'm just going to skip this. There's a couple of ways you can do this. One is by doing a use memo to memoise the creation of some of the elements, or if you've ever used the children prop and included that in the output, that's the same element as last time. The way that I like to think about this is React.memo is the child component itself saying, I want to be optimised. Only re-render me if my props change. I like to think about the element reference trick as the parent component saying if the inputs to this one haven't changed, don't render it. Now on that note, this is one of the most common misconceptions that I've still seen over the years. People have really from the beginning assumed React only re-renders my components when their props change. No, no, that's not the case. I said earlier, when React renders, it just keeps going top to bottom from where you did a set state. The only time props references matter is if you are trying to optimise it. If you have a React.memo, then the props matter.

Otherwise, React says next component, next component, and it keeps on going. This brings up a common set of questions about using React.memo extensively, wrapping all components, and the React compiler's role. Historically, the React team advises against memoising everything due to added complexity and potential wasted efforts. Instead, they recommend identifying specific components for memoisation based on performance issues.

The React compiler automatically optimises components by memoising calculations. It reads and analyses the component's JavaScript code, identifies dependencies, and then rewrites the code to memoise calculations efficiently. This process simplifies complex calculations into if-else statements similar to the useMemo hook, enhancing performance without manual intervention. The compiler output may initially seem complex with dollar sign variables, but it essentially optimises calculations for improved rendering efficiency.

The compiler ensures that recalculations occur only when necessary by comparing input values. If there are changes, it reruns the calculation; otherwise, it uses the previously saved result. This mechanism mirrors the behavior of the useMemo hook by efficiently managing component renders based on input changes. While the compiler uses slightly different syntax, the underlying concept aligns with memoisation principles, streamlining component performance optimizations.

We've got a user value and an on-follow prop, it formats the name, and then it returns a bit of JSX. If I run this through the compiler, what does this look like? Oh. Oh dear, what happened here? What are all these dollar signs? Did someone spill some jQuery in here? I've seen some people look at compiler output and kind of panic. It's actually not that complicated. Let's break it down.

If you were to look at the way the compiler rewrites your component, it actually just keeps writing the same pattern over and over. Here's a made-up example of what it's doing with some more readable variable names. What it does is it looks at all the inputs for a specific calculation, and it looks at a cache value, and it says, have any of these input values changed from the last time this component ran? If any of them changed, then it will rerun the calculation, and it saves both the result and the inputs. Otherwise, if none of them changed, we can just use the result we calculated last time.

So how does this actually improve performance? It does a couple of things. One is that if you have logic that might be expensive, it's only going to run when the inputs change, not every time through the component. We're also saving a little bit of work because we're not necessarily recreating all the JSX elements every time, but the really big win is that we have memoised the JSX elements. We only recreate them when the inputs change, and that makes that same element reference optimisation kick in, and so React will end up skipping rendering those child components unless the data changed. What about other uses? What if you have some context? It's the same thing. In this example, we extract a couple of values from context, and React will automatically see that those are getting used, write the if-else memoisation logic, and produce the results. What about if you're using Redux or Zustan? Same thing, and in fact, this actually makes a small improvement. Here I'm writing an inline arrow function as the selector, and you can do that just fine with React Redux.

In the actual output, the compiler is using a dollar sign variable, and it's an array, not an object. So these, I have my made-up example on the left, and then we have the actual output on the right side. Again, it's the same thing, we're just saying, here's the previous inputs, have any of them changed? If so, reuse the result.

What about that underscore C thing? What is that? So React 19 actually ships with a new hook called use memo cache, and they actually have a polyfill that makes this work for older versions of React, and really all it is is a used memo that creates an array, and the compiler figures out how big does this array need to be? How many spaces and how many values do I need to save? It passes that to a hook, the hook makes an array that is that big, and now it has all the space it needs to cache the results.

So by the time we have rewritten the first parts of the component, we get down to the end, it's going to assemble all the values to create the final result, and again, we take some more inputs, in this case the pieces of the JSX we calculated earlier, we assemble them into one final result, and return that, so again, it's the same if-else pattern all the way down.

So how does this actually improve performance? It does a couple of things. One is that if you have logic that might be expensive, it's only going to run when the inputs change, not every time through the component. We're also saving a little bit of work because we're not necessarily recreating all the JSX elements every time, but the really big win is that we have memoised the JSX elements. We only recreate them when the inputs change, and that makes that same element reference optimisation kick in, and so React will end up skipping rendering those child components unless the data changed.

What about other uses? What if you have some context? It's the same thing. In this example, we extract a couple of values from context, and React will automatically see that those are getting used, write the if-else memoisation logic, and produce the results. What about if you're using Redux or Zustan? Same thing, and in fact, this actually makes a small improvement. Here I'm writing an inline arrow function as the selector, and you can do that just fine with React Redux. It does make the internal logic say, oh, wait, this is a new function reference, let me double-check the results. And the compiler has actually saved that arrow function, so it only gets recreated when the category ID prop changes. So very, very small improvement, but, again, it's making things better.

So what happens if you have useMemo in your component, or what happens if you are using context in your component? The compiler will actually look for useMemo and useCallback that you have written and replace those with its own output. Same result, but maybe it works a little better. If you have context in your component, it does not change how context works. If I put a new value in the context provider, every component that reads the context will still rerender. But the biggest problem with context for performance is that I put a new value in up top, these components read it, and then everything below those renders. Now, with the compiler, this component reads the context, it still rerenders, but the children only rerender if the data actually change. So it doesn't necessarily cascade all the way down. Didn't we say you aren't supposed to mutate values while rendering? Technically, this is mutating the array, but it is the React team, it is the compiler, I don't know. I guess it is okay. They can do whatever they want to.

How does this change the way that we think about React? I said earlier that it is a very common misconception that my component only re-renders when the props change. With React out of the box, that's not true. It just recurses all the way down. This is where it is important to understand the default behaviour, because the React compiler flips that upside down. When you install the compiler and run it on your components, now, for the first time, your child components truly only do re-render if their props and input have changed. That does change how we think about how we are writing our components.

So how do we actually teach this? What happens if a dev comes into a codebase that already has the compiler installed and they're not seeing use memos and everything works auto-magically, and then they switch to another project that doesn't have the compiler installed? I can see some learning problems here where they get it confused, they don't understand that the compiler is doing all this extra work for them, so they might have some wrong assumptions. It goes back to the principles that I very firmly believe in, which is that it is really important that we understand how our tools work and the fundamentals. We had this same issue with Redux. We use the immutable update library in Redux toolkit which lets you write mutating code, and you have to remember that this only works inside functions like create slice.

All right. I am, I believe, sort of, kind of on time. So where does the React compiler stand today? It is out, it hit 1.0 last fall, the React docs have a section that talk about setting it up and how you can configure it. Also, there's some, I believe there's some linting rules that will tell you if you have components that break the rules of React, FYI, the compiler won't optimise these, you might want to update those specific components. There is an online playground, which, let's see if that works. There's a playground where you can interactively try editing some components and see the output. One note about the compiler, the compiler itself is originally written in TypeScript, and it's delivered as a Babel plug-in, and unfortunately we've spent the last few years changing our build tools to use Rust and removing Babel, and so up until just a few days ago, you really had to re-add Babel to your build step in order to use the compiler, which unfortunately slows things down. The React team has spent the last couple of months porting the React compiler to Rust. They just merged that PR a couple of days ago. There's still some integration work that has to happen so it works with the rest of the JavaScript toolchain ecosystem, but that should speed things up. And again, it wants that new hook that only exists in React 19. If you are using React 17 or 18, there is a poly fill for that hook so that it can work with those as well. All right. That's all the official information I had. Quick plug for the day job. I mentioned earlier that I work at Replay, where we have built a time-travelling debugger for JavaScript, make a recording of a bug, and then you can investigate it with time-travel powers. Originally we built browser dev tools with time-travel built in so that humans can investigate.

Quick plug for the day job. I mentioned earlier that I work at Replay, where we have built a time-travelling debugger for JavaScript, make a recording of a bug, and then you can investigate it with time-travel powers. Originally we built browser dev tools with time-travel built in so that humans can investigate. Unfortunately, we turned out that people really don't like to spend time debugging. I don't know why. It's fun figuring out what went wrong. We shipped an MCP earlier this year that lets agents do a lot of the investigating. I have spent a bunch of time improving our MCP tools with analysis about React renders and performance timings, even in production builds, as well as tools that can tell you about the state management. I even put up a couple of blog posts. I wrote one about how Replay found a React bug faster than Dan Abramov did. We have built cool tools on top of the MCP. We shipped a QA tool that can investigate websites, figure out how users would use them, auto find and report bugs for you, and we have a CI agent tool that can record playwright and Cypress tests and investigate failed tests and tell you what broke in CI. You can check those out now at Replay IO or come ask me. I would love to tell you how awesome they are and how much time they will save you. As always, I have links to a bunch of these things on the slides on my blog, and you can find those there. Thank you very much.

First of all, amazing talk. And thank you folks for your questions that have been coming in. Make sure you upvote questions. If you spot one that is there that you find interesting as well. And even if we don't get through to all of them, there will be the in-person Q&A where you can go and get a follow-up. So let's start by the first one, which I find hilarious because Dan Abramov is the name of the person who has written it, which is what impact do you think the Rust rewrites of the React compiler will have? Observing things, I think there have been two or three different barriers to people adopting the React compiler. One is that it's not just turned on by default, and a lot of that is that there's so many different React frameworks and React build systems. So Next.js includes a React compiler option already built in, but if you're using Tanstack, Start, Vite, RSPack, something else, you actually have to install the plugin. It takes a choice to turn it on. But the other two issues are that you have to reintroduce Babel into the build system, and we've spent the last couple years trying to rip out Babel, and then I have seen a lot of people say that adding that does drastically make their build times slower. So I am hopeful that the Rust port will improve the adoption by removing the latter two as problems. That if you are using any, you know, V8 is rolled down, which is the OXC tool set, that the Rust tooling will integrate with that better, so there's no Babel plugin needed, and then both the removal of a Babel plugin as well as the compiler logic being in Rust will make it run faster and remove that as a problem. So you still have to choose to use it, but at least, oops, my build time's tripled won't be a concern. No, that would make sense.

That makes sense a lot. We've got another question. This one's from anonymous. Is there still a use case for use memo? And you talked a little bit about that in your talk, but could you... Some, yes. One is that the compiler will look for use memo and, you know, automatically place that so it can, in some ways it might actually act as a hint to the compiler that yes, this definitely should be memoized. But hopefully you won't have to spend as much time writing that in your own code. It was really interesting when you talked about how there's going to be a lot of learning where people don't realize that these things are happening under the hood. It's always really interesting seeing that as an engineer and seeing how that changes.

One of the great things about software is that we get to build abstractions. I don't have to think about C++ or Win32 or POSIX APIs when I'm writing JavaScript in a browser, but I at least need to know what are my libraries doing and how do they work, like the level right under the code that I'm writing. The next kind of question leads to looking under the hood of the compiler. So this one is when the compiler can't statically analyze a component and it bails out of memoizing and optimization. How does a developer actually know that happened? What's the debugging story if there is maybe a component that is silently left unoptimized? I believe this is where either the compiler or the compiler-powered lint rules will tell you... They'll do a scan of your codebase and tell you which components break the rules of React. Conversely, there is a directive that you can add, which I think is use no memo as a string. Just specifically tell it, don't try to optimize this component. We know this component has a problem, just don't even try to do that. But generally using the lint rules should tell you which components it would bail out on.

I love that there's the ability to just be like, no, this is unoptimized and I like it that way. I like it that way. All right. Another question, which is kind of general, which is what, if any, are good reasons not to use this? Because a lot of times we give answers and it depends. So what's the other side of this it depends? To me, I actually think everyone should at least try to turn this on in your codebase. The meta team has done a lot of work to try to make sure that it fully understands JavaScript and React semantics. They've done tests on memory usage and how this actually affects mount times, render times, update times. It's not necessarily going to make every application 5,000 times faster, and there might be a bit of an increase in bundle size. But general principle, I think basically everybody should go back and try to install this in your projects and see the results. It shouldn't make things worse, and it should make a number of performance aspects better. And circling back to that kind of question that we had about learning as well, the next one is that there's a lot of performance optimizations that are included for free in the React compiler.

And is it okay for us to just switch our brains off and be like, oh, it works? Or do you really think it's important that engineers understand every single piece of code and optimization that's happening under the hood? Software engineers have never understood every bit of code. That's what I was saying a minute ago. When I write JavaScript code, there are so many layers of abstraction under the hood that I don't have to think about. Part of the point of React is we don't have to think about writing DOM updates by hand. So you will never understand everything, but as I said multiple times, the more you understand the fundamentals of the tools that you're using and at least understand the next level down, what is it, why is it there, the better you are able to think about how your program works.

So with the compiler, I mean, I actually just explained most of what it did. If you don't understand it, please watch the talk again. But it is also something you probably should be able to turn on and mostly not think about. Awesome. So my next question is that since useMemo itself has a kind of computational cost, how do you decide when a computation is expensive enough to justify memoization? Do you have any practical rules of thumb or any profiling approaches for making that decision? Funny you mention that. So one of the other conference talks I've been giving this year is actually literally about how to perform performance investigations. So plug for my other talk that I've done. I have spent a lot of time doing performance investigations in my career, and like, mini version of the talk. Nobody gets taught how to debug, but we all learn how to debug because we have to ship code that actually works.

But nobody gets taught how to do performance investigations and nobody actually spends time investigating performance because all we care about is was CI green, did the test pass, did it run, ship it. We don't spend time checking if the code was faster, if we made things slower. And so there's a lot of tools you can use to do performance investigations from the built-in browser CPU profilers, the React dev tools profiler, a lot of other tools you can do to do perf checking. And so the real answer is measure your whole app, whether it's the components or the JavaScript runtime, understand where things are slow. Like if a single function call takes .01 milliseconds to execute, there's no reason to optimize it. Let it run every time. That's how React works in the first place. But if you do performance checking on, you know, the whole app, and you see this component is consistently slow.

Why is this component slow? Because it's calling this massive transformation function every time. Okay. Now I've zeroed in. Now I see the evidence that this is slow. But like the number one rule of performance investigations is measure, understand where it's slow, and then figure out why it's slow.

And then the next question comes from Robert. So lots of people might be excited about this, might want to go and use it straight away. And they already have an existing code base and they want to turn it on. What does it look like? Is it a flip a switch and just start taking use memos out? Is there kind of a transition process that you would encourage for people?

It's pretty much that. Like I said, it's primarily a build tool plug-in. The React docs have the instructions on how you can set it up. But it's pretty much you add a plug-in to your build setup and you rerun your build and it does everything invisibly as part of the build process in the same way that the JSX to plain JavaScript transformation happens in the build process. Awesome. Now we are nearly out of time. So I'm just going to quickly go off the questions and say, like, lots of people have been asking so many questions. They want to find out more. Where can people find you online? Maybe there are people joining online as well?