React 19 and the Compiler for the Rest of Us

Hi everyone. Really happy to be here to be talking about React 19 and the compiler for the rest of us. First quick note about me. I'm called Johnny. I mean, my full German name would be Johannes Bernhardt, but no one's using that. So just refer to Johnny if you want to speak to me later.

I'm currently working at Synthesia. Sizzle was a job before, but I'm combining my React 19 experience of both jobs because at Sizzle we used React 19 quite early, put in the beta, put in the compiler. So running production at Synthesia, we are just now moving to using the compiler in some places and the React 19 port later.

You might ask, well, what does the rest of us mean? Rest of us in this case means I'm just talking about React 19 as an application engineer who's building applications where the user will spend multiple hours in. So it's not from e-commerce perspective where it counts the milliseconds for us. It's really important. Does the user have a good performance experience after being on the page for six hours maybe? And so it's all focused on that. And we're going to talk a bit about the compiler, but also doing a talk on my own would be a bit boring. So I did bring some support like the people before, but not in person. Greetings. I am Bernhardt III and love defending my performance castle by well-placed memorization. Hi there, mate. I am John Rackham and I write my code like I live, wild and free. Well, and I think the three of us together will cover like a wild range of experience looking into React 19.

So what's our goal for today? Well, our goal is simple. We want to help you reach production mountain with React 19, but before we can set sail, I'm going to first step, we need to get a crew together. So I'm going to ask some questions to the audience just to see where are we with React 19 already or not. Then we're going to talk about motives. Why would you want to install like the compiler into your code base? I mean like JavaScript is slow enough in the build process anyway. And then we just have a quick back to vintage islet. We're going to talk about memorization because if you add in compiler to add memorization, we probably want to know memorization in depth. Then we're just going to go for it. We just going to install React 19. We're going to see what happened to our code base.

Then we learn something again about React rules and that sometimes not disabling lint rules is well the better idea. And so we're going to have a quick look back into the rules of React. Then we do the compiler climb. Compiler climb means we just look at two or three examples to see what does a compiler do to this code. And then we are on production mountain and then we sing a song. Well, I hope to get some support in the end because we're a crew now so we're going to sing some chanties. So let's do it.

Okay. Questions for the crew first. Who's team night? Who's adding use callbacks everywhere like big shout please. Okay. Well, that's not that many people. Who's team privateer? Team pirate? No, no? Okay. Well, and who's still using React 17 in his code base all over? Well, I'm talking about React 19. But maybe get to 18 first. But there's some good news for you at the end as well. And who's using 19 in production already? Because I mean, the release was last week. All right. Okay. Then I'm happy that I can share some experiences about that. All right, let's do it.

What might be motives adding a compiler to your application? I think let's take a step back to the 80s. There's this famous book called, well, the Red Dragon compiler book. They have like one quote I wanted to bring. I mean, like, oh, well, super interesting book. You can definitely check out if you just want to get a bit more about the computer science techniques. But the quote is simply stated a compiler is a program that can read a program in one language, the source language, and translate it into an equivalent program into another language, the target language. An important role of the compiler is to report any errors in the source program that it detects during the translation process. I think there's two or three very interesting points here. First is usually you use compilers to translate from one language into another.

The React compiler will be translating from JavaScript to JavaScript. So it's not really another language, but it will look quite different. But you'll see that in the compiler client. And the other thing is, it needs to report errors. I can definitely say it does report a lot of errors. So that's definitely covered. And we're going to have a look at that later.

OK, now you might ask, why do we want to add a compiler? Well, I think there's probably two or three main reasons you want to use it. But let's ask Bernhard that. I write the best code already. Exactly. So there's a lot of this stance that I don't need a compiler. I don't need optimization. I know all my code anyway. But what we have been seeing recently is it's all about stacking abstractions. No one of us is worrying about the electrons or photons or the transistors in your CPU anymore, in the user CPU. We are worrying about a very, very high-level language. Just what's happening in the browser. And there's a far disconnect of what's going on on a physical level. And that's all possible by compilation on multiple layers. And you need a compiler for that. I don't want to write the binary anymore to show a picture on my user screen. That would be crazy. So we're stacking abstractions. And in that sense, in LLM, when we write code, it's also a compiler. It's translating our thoughts into the code. So, well, it's a compilation process. Just the error reporting isn't that good there with the LLMs yet. But maybe that will get better. Another thing, performance optimizations.

The compiler can go in a much deeper level of optimization than you would want to do manually. The compiler can know the target architecture of the CPU. Or can know the target architecture of, well, the React runtime we are compiling for. And you can focus on what the application actually should do for its user. Because that's my main job as an application engineer. I want to give the user a good experience. They don't care about the tech running. So let me focus on that. And let's have the compiler optimize stuff.

Okay. But what does Rackham think about that? Because we said we want to compile stuff. We want memos. But… Memorization will eat all your RAM. Exactly. I think that's where we come in stance in the React community. That memorization does eat all the RAM and you should definitely not do it. And it doesn't work anyway. I think the first differentiation we need to make there is stack versus heap memory. I'm not sure who had that in computer science university classes. But basic principle is you have the heap. That's like the overall memory your application uses long-term. And then you have the stack of the current operations you're running. And the stack will grow. And if you render more components, the stack will grow further and further and deeper. You can look at the… Turn on the profiler in Chrome. Have a look at the stacks building. You see there's going to be a lot of memory usage there. So if we can memorize some of the components and skip parts of the rendering tree, we'll use less memory on the stack. So just saying you will use more memory with memorization is, in my opinion, just not correct. You need to differentiate it better.

What about the children? Exactly. Who heard that? Like, don't use memos because it won't work with children. So, well, let's dig in because that's actually not true. And that's an important principle the compiler will use. So sorry if that's super familiar to you. We'll get back to it later why we need that.

So memorization. A simple example. Let's do this. So we just have a counter. And you can click it and it's increasing the count. And then we have another render count function here that's just taking a ref and render counting there. So what's the render count if I click the button? Can someone say two? Wrong, because strict mode is on. Okay, no, but so I turned off strict mode for the other examples here.

Next example, we're just adding a memo here. So I click the button, strict mode is off again. So I click the button once and render count is one. Memorization works, all is fine. But then you start adding, okay, I have some children here. So into the render count I'm passing some paragraph or some text. So I click the button, what will happen? Well, render count is two now, because why? I had to create a new React element here and that's always a new thing. But then you're like, okay, so can I never use memo if I'm passing children? And then you might try something like, okay, well, let's just put some text in here, right? And I have the memo here. So any guesses, what's the count going to be, the render count? No, it's actually one. Because React is comparing the children there and you get the string as children, it's the same string. All good, I'm not going to render the component. And we can take that example slightly further. In this case, we are using not a string again, we're using paragraph, but we're putting it into like a use memo and then just passing in the inner child. So now you all should expect the answers like the render count is not going to change because we pass in the same children. So yes, you can use memos for children, works perfectly fine. So the main lesson here is, yes, you can memorize JSX and the compiler will be doing that everywhere.

All right, so we are ready. We know why we want to use a compiler. We have our old React18 code base. So what's the next step? I mean, pretty simple. You just go to your comment line and you install the latest React version. And then you see. Let's see what happens. Any guesses? Will it just work? Will there be issues?

Well, I mean, I would actually get fired for my job because there's a big error message saying secret interns do not use so you will be fired. That reminds me a bit of working at Twitter in 2022. Well, that's long ago. And that's an example from Sizzle. In this case, now we have been using the preact signals runtime for like some sub library of the monorep to just try it out, but that breaks. So in case you're using any crazy stuff hooking into the runtime, you probably want to check if you can disable that before you want to just move to React 19. Otherwise, you're going to get error messages like this.

And then next step, obviously, you need to enable the compiler. I mean, the first thing you really should do is read the manual of the React page. I have one or two areas where I would slightly differ from the manual. So I'm just going to give you the tips so you can go ahead when you just want to do it. So configuration is quite like one configuration file called compiler, something where you list the folders and you reuse that list of folders in a regular expression. So just get some utility function that's creating your regular expression to grab all the folders for the A and B and some source folder. And because then you can use that pattern in the React compiler config to test which files you want to actually have the compiler enabled on. But the good thing is you can reuse the folder list also in your ESLint files. So you're sure it's like the same thing happening. And then you have like some Babel config in our case because it was using our build process where you just say, I'm going to use the compiler config over here and pass it through like all our JavaScript files with a Babel pattern. That all very much depends on your local build setup. So there's really no point diving in. Just have a look at the documentation, really, but just take the tip of creating a list and sharing it.

All right. So we did do that. What happens? Well, it works.

Yes. We see one compiled component. How can you check that? Make sure to install the latest version of the React DevTools. You will see these nice blue memorize star sprinkles buttons, but then you're wondering, okay, I enabled the compiler for a lot more files. So what's going on in my application here? And then you're digging like, okay, well, what did we say about compilers earlier? It's all about error reporting as well. So if you have a quick look at the ESLint log, we see React compiler skipped optimizing this component because one or more React ESLint rules were disabled. So a quick question there, who of you regularly disables ESLint rules? Well, at least some people in the front, which, well, I also did do that in the code base. So what can you do about that? In our cases, I think there's like two main things going to be happening. First case is, you have some effects somewhere and that is saying like, oh, well, I don't want to re-render, but it turns out it's actually depending on something that's stable because use another hook here in this case was returning a stable action. So you might as well just put the do some action into the dependency area, it's going to be fine, and then that component will compile fine. In other cases, you might have some dependencies where you're skipping. So like this code here might use reference B, but in the dependency area, you only have reference A and C, and there's some business logic behind it. In this case, well, just stack another ESLint disable next line rule and, wow, also works. But that means that the file still won't compile, you just not get the warning on your lint. So that might be important depending on how your CI is set up. Okay, let's move on.

And then you have this example, you're like, okay, why is the compiler complaining about this? I'm like, this look like I have ref, I'm having some scroll handler and I'm attaching it to the window and like, why is the compiler complaining? Any guesses? All right, I did bring some help to look into this for a quick React rules recap. So let's do here by Bernhard. Let me help you. There are three main rules. One, components and hooks must be pure. Two, React calls components and hooks. Three, rules of hooks. Well, I think the third rule is a bit crappy, but it's the way it's stated in React docs, but you can rewrite that as open source. It's only called hooks at the top level of React functions. So, all right. Do we have any idea now? Well, it's actually the first rule. Components and hooks must be pure. What's the issue here? The issue here is like we are using this ref, but you're only really allowed to access the ref, well in callbacks. You're not allowed to access the ref in rendering time because that makes your function unpure.

And the issue here is we know that this callback function here won't be called till much later because load-throttle function is not calling the inner function, but there's no way for the compiler to know that the throttle function won't immediately call this function and this function will be called when they use memo update. So it would be called in the first render cycle. So the compiler is saying, I don't know what you're going to do here. So I can't compile this. So how can we solve this? Well, we can just reorder the code a bit. We still have like our scroll handler up top, but we create the throttle version just in the effect because this reference is now stable because there's no dependencies here. The use effect also will only trigger like one time. So we create one throttle copy and just use that. And that's now totally fine for the compiler because the use effect will happen later and won't happen in rendering time. So it's sure that the button ref won't be accessed. So if you run into this, always think about you're probably going to run into this like a lot, at least like an hour code basis happening with refs and then no one was really strict about not using them. Compile time. All right. So solvable. And if you do that in a lot of places in your code base, well, your dev tool is going to look like this. It's a lot more compiled. So that's lovely.

So next question you might ask, okay, well, let's compile it now. What does it actually mean? So let's do a quick compiler client. We're going to have a quick look. What's the compiler doing? Well, super simple example, React compiler. We have this, well, very simple component, just returned like a static dev. Hello world. Oh, well, it's more code now. That must be more complicated. So let's have a quick look.

First line is just saying, okay, dollar equals C1. No clue what's going on, but we're going to come back to that later. Then temporary variable. Ah, okay. So it's using the dollar to check for some cache sentinel. And then it's, oh, that's generating my component. Well, the inner component now. And then it's assigning that to the dollar sign. And if it's, so I mean like what's going on is pretty simple.

It's just a use memo in a slightly different way. We just check, and this is just like an array of things you might store in the component might want to use later. So we, in that list, we just check, okay, do we have like an empty value? And then we create the inner component. And then we returned the inner component. And if you already have the inner component there, we just return it from our cache there. And if you want to like, now might ask, okay, so what's like the C doing here? Well, React's open source. So we can just have a quick look into the React compiler runtime. One quick note there, you might have not known yet. The React compiler is actually TypeScript. So that didn't write it in flow, which I'm very happy about. But so it's TypeScript, so we can have a quick look. First thing we noticed if React.C is already present, you're like, okay, what's going on? I thought I can only use the compiler with React 19.

Well, it's actually not true. You can use the React compiler with 17 or 18 as long as you have runtime support for it. So nothing's stopping you from just going for the compiler already. And then, so it's just using that if that's present. If that's not present, oh, well, let's use memo again. And then you see, it's like initializing the array of the given size. So in our case, we would have gotten like an array of size one. And well, it's just putting the empty symbol in here to mark that as empty. And then it's doing something for the depth.

So I mean, like in the end, it's just just like a list of things that you might want to use later in the function. So let's do slightly more involved example for the compiler. But recommendation there is definitely check out the compiler playground. It's great. You can see like a lot, there's like 20 different steps the compiler can do. I don't have time to go into all of these. So you need to check out the playground. It's only one big issue. It doesn't have a dark color theme. Horrible. Sorry about that. But let's have a quick look at this.

Okay. This is our counting example from earlier before. And the first thing you will notice, oh, well, there's our error message again, because we are using the ref in the rendering cycle. So the React compiler will actually bail out of compiling this render count component. But it will compile like the application component on top. So what's going on here? We can just easily map or relatively easily map.

Okay. First thing is we see like the inner child here. So we are using a use memo here. And our case here, there's actually no more use memo because the compiler is removing all the use memos. And it's just saying, okay, similar as the example before, I'm just creating like this static child component, putting into the cache at slot zero. And I'm only going to do that one time. And then interesting thing happens because the compiler knows this is actually not going to change. I'm only going to initialize this once. I also only going to initialize the render count function once, because if this inner child never changes, I can also cache like this area here of the render count inner child render count. And we see this happening here. Where it's also just saying, okay, well, put the render count inner child in the cache at slot four and then return that. Okay.

Now you might say, okay, well, that's a bit boring. So what's happening when something's actually changing, we can have a look at the count stuff here because that's going to change. And we can actually also see what the compiler is doing for us because we see like the set count here. I'm like in a function, there's no use callback. I will be quite unhappy about that in production, but luckily the compiler is creating a reference to the set count function only once in this block. And then it's using that reference in the well, third area here. And there we also see like, okay, so if the count changed, I'm going to, because we store the count at slot two, if the count change, I'm going to create like a new button. And then in the different slots, I'm going to say like, which count did I use? And then the resulting component. And then if I'm rendering again, I'm going to check, okay. So what's my count at slot two? If it's similar, I'm just going to return the cache button. Okay. So I mean, it's all pretty simple. It still kind of looks like JavaScript. So the language doesn't really translate, but it also looks quite different, but I'm like, just stick around in the playground. You'll get to it.

Okay. So next question. I might have a solution here. So what can we do about the render count? Well, simple solution. You put your unsafe stuff in a hook called privateer because then the render count function can nicely compile and you just have the other stuff somewhere else and just this won't be optimized. And then you see render count is compiled as well. Cool.

All right. I mean, we reached production mountain. Okay. What are my experiences from putting React 19 live, at least at Sizzle? First thing is your dev server startup might be slightly slower because we didn't use Babel anywhere. Now we're using Babel through the React compiler and there's obviously some overhead, which is a bit sad, but it's the way it is now, but it's worth it because we get granular reactivity. That means I'm usually, I love putting news memo everywhere, but I'm also a bit lazy. So I might put too much stuff in one news memo just to have it somewhat memorized.

But that means if I calculate three different values, only two of them should update. The third memo could be memorized differently and the compiler is doing that for me automatically. And it's doing noticeably less rendering, which our users love because the application feels quicker. And it absolutely works fine with React 18. We are doing that at Synthesia now. We're starting to put some of the source folders into React 18 with compilers. Also working quite well. So my opinion is just go for it really.

Okay. So last slide of the talk. Quick, quick shanty line. Who's knowing like this German shanty of 17 Mann auf des Toten Mannes Kiste, Jo, Ho, Ho, ne Buddel voll rumm? Well, you don't need to do that because that's not where we react to you, but let's rewrite this. And this, all right. Now I need some support. I'm going to do it once on my own and then I'll ask for your support. I mean, like you don't have to do it, but then it looks stupid.

Okay. 19 Mann auf der React-Versions-Liste, Jo, Me, Mo, ne Buddel voll rumm? Well, at least the Germans.

Okay. So let's do it. 19 Mann auf der React-Versions-Liste, Jo, Me, Mo, ne Buddel voll rumm? Lovely. That's it.

First of all, I love the fact that you had a C shanty at the end as well. I, unfortunately, because I don't speak German, I can't, I couldn't join along, but what I will do is maybe I'll grab your slides and translate it and then probably sing it next time. Next time you do it. I'm like, we should do a line at the after party. At the after party? Okay. We'll see. We'll see. We'll see. I'm not going to make any promises. I'm not going to make any promises.

We've got a couple of questions that have come in. Remember, think about which one's your favorite as well, because that person will get a prize, but I'm just going to jump straight into the most upvoted question, which is about performance. And it's from Flip. Do you find a measurable difference in app performance after introducing the compiler into production? Or into... I'm not... Is it in production at Sizzle you said?

It is in production at Sizzle. That was a quick turnaround to get React 19 into production, right? Well, we just put the beta version in production. A beta version in production? You are brave. I mean, the gaming world is moving quickly. Fair enough. Fair enough. But, yeah, but the point... I mean, you can turn on the DevTools.

I mean, you can turn on the DevTools. You will see... And you put on the flickering mode and you will see less blue flashes. So it's great. Also, surprisingly with React 19, the load times between pages got better. So there's less rendering going on noticeably. I can't really share stats, sorry about that, but it's working so far.

Okay. And I'm pretty sure that if they can find you in the Q&A, you can speak to maybe some of the specific places where you saw the performance increases. Yeah, absolutely. As well.

We've got another question coming in from someone, which is asking about it being safe to use React compiler in an application that uses heavy React libraries, maybe like an AG Grid and MUI. Or do you have to do quite a bit of research into compatibility? Well, very good question. And I think the answer needs multiple layers. So first thing is the compiler is not looking into the library code yet because it will only compile your application logic on top of it. So if you want the compiled version of the library, you either need to build it from source and enable the compiler on top of it or you need to wait for upstream to do it. And then the thing is, as long as they follow the rules of React, everything is going to be fine because that's what the rule compiler is built up in. This agreement that we all follow the rules of React. We don't do weird optimizations because we think we can do better. And I think this is also one of the reasons sometimes people don't really want to use callback or use memo everywhere. They're thinking, well, I know the code I'm using here. I know it's going to be better this way. Yes, but does your future self in three weeks know that you optimized this area? Probably not. Does your coworker in two years know that you have a weird performance optimization there? Probably also not. So we need to have this agreement of always following the rules. And so we have conventions we can build on. And if you don't break the conventions, the compiler will generally be fine. It's still officially a beta version. So depending on your customer base, you maybe don't want to do it. The one area where you might run into trouble, really, is if you're doing weird stuff with references.

If you're doing weird stuff with your own custom hooks and just not really following the standard lifecycle, then you really need more testing. The good thing is, you can also opt out single functions from the compiler. You can just add a directive, use no memo on top of the component, and it won't be compiled.

That makes sense. That makes sense. Also, just hoping that everyone follows the rules. That's a bit of wishful thinking, to be honest. Well, I'm a German. No, for sure.

And the next question is asking, so about use memo and using callbacks. Does that make them pretty much useless? Well, I mean, it does make them useless in the code. That's compiled, yes. So you can be happy to not think about that anymore. And how does using the compiler, this is from Alex, affect build time? So did it speed it up? Did it slow it down? No, I mean, like, as I mentioned on the slide, no, build time is definitely going up. Probably more so if you're not using Babel yet, because that means you trigger all the Babel parsing and whatever. How much by just like kind of ballpark figure? So startup time, which is like compiling most of the files in our case, is like by 40%, just like the Babel overhead. But that means if I start my application locally, it now takes me nine seconds instead of five. So well, no, it's more, well, it's more per set than that, but something around that. No, for sure.

And the next question is from Ricardo. And so you've just upgraded to React 19. Were there any unexpected messes or anything, especially it's still in beta, any things you ran into that maybe someone who is about to try out React 19 should watch out for? Yeah, I think one slightly unexpected mess is the removal of the global JSX namespace. Because previously, if you install the React types into your application, you will have the JSX globally available. But now React is namespacing the JSX namespace below the React namespace. So in any places your application is referenced during JSX, you either need to prefix the React or it might not work. And one issue we had at Synthesia at the moment is we are using Emotion. And Emotion didn't update to React 19 yet because it's changing a bit with the types. And I mean, like if you're doing all the styled wrappers, they're wrapping over the JSX namespace in the TypeScript types and that doesn't work anymore. You can do some hackery by like re-exporting the JSX namespace globally with like a TypeScript definition file. But we should be further in the rules.

Exactly. No, for sure. Das, thank you very much.

And we have time for one more question. This one's from Marvin and this is about debugging. So in for example, Chrome, is their source mapping, are the debugging tools doing pretty good? I really liked the debugging tools where you could see where use memo was auto, was put in automatically by the compiler. Yeah, no, I mean like the source mapping works fine. And the good thing also is, at least in my opinion, it's still like JavaScript. So I mean, like if you did see the compiler output, you can still like read that and it's a bit convoluted. You need to get used to that style, but then it's also relatively easy to just like look in the straight compiler output and see what's going on. So yeah, no issue there.

Awesome. And last one, this one, I also agree with this person. Can you translate the C chant right before we go? Absolutely. So like the updated version, well, it's saying like 19 men on the react. As it says, okay, well, I slightly changed the song. Like in the original German meaning, it's 19 men on the dead man's chest. There's also an English version. You are in a bottle of rum. Yeah, exactly. So that's the same. But the updated German is like doing the exclamation mark. So it's saying 19. Yeah, on the react version list, because you can use man in different ways in German. And the second one, well, I mean, like you get that, I think.

Awesome. All right. Now out of those questions that we just had, anyone that stuck out to you will give the person who asked the question a wonderful react day. I mean, like I love the question about the chantees. Now, you love the question. Oh, it wasn't mine. It wasn't actually mine. It was anonymous. So anonymous, please head to the front of the stage. Actually, I'm going to give you the mug and then at the Q&A room, anonymous go and grab your cup for your question. So thank you very much, Johannes. Once again, it's so great to have you on our stage. Let's give him a round of applause.