React Compiler with Sathya Gunasekaran and the React Team === Paige: [00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams to improve user experience with session replay, error tracking, and product analytics. Try it for free at logrocket. com. Hello everyone. I am Paige Niederinghaus and I will be your host today. And we have Satya and Joe Savona from the React team joining us here to talk about React Compiler. Welcome back to the show, you two. Joe: Thanks. Great to be here. Sathya: Yeah. Great to be here. Paige: So you have actually been on the show last year, I believe, talking to me about react compiler and react forget at that point. So for people who have not listened to that previous episode, tell us a little bit about react compiler and where it is today. Sathya: Sure. Yeah. ~Um, ~so ~the, ~the main idea behind the compiler ~is, ~is that we have this problem in react, which is,~ um,~ it can sometimes be overreactive,~ um, ~when you have,~ uh, ~some computations. ~Um, ~we don't want to rerun computations unless the dependencies of [00:01:00] the computation changes. ~Um. ~And the computer science way to do this is to memoize it. And React provides a hook called useMemo ~to do, ~to cache these map computations. And also use callback to do the same for callback. And it works great. But there's this trade off where developers have to think about monetization, which takes away time from actually building the UI and building the product. So when we started the project, we were like, what if we could automatically memorize your component code? ~Um, ~and so that developers don't have to worry about this. ~Uh, ~the compiler can come in automatically memorize,~ um, ~all your computations. ~That's, that, ~that was the thesis behind the compiler. ~Um, ~so it's mostly as a DX benefit. ~Um, ~but as we built the compiler and we started,~ uh, ~running the compiler. We started saying,~ um,~ the compiler actually improves the ceiling of the react,~ uh, ~apps,~ uh, ~because the compiler can actually memorize more than a developer [00:02:00] can because the compiler actually doesn't,~ um, ~output use memo, it outputs something more lower level. ~Um, ~so it doesn't have to follow the rules,~ uh, ~of hooks, for example. So it can memorize within a conditional,~ um, ~so it can memorize more than a developer. Okay. And then the other thing we noticed is that humans sometimes forget,~ uh, ~to memorize one particular value,~ uh, ~and that cascades down prop, causing all of the children to re render and with a compiler that just goes away. ~Um, ~so it started out as a DX,~ uh,~ project. ~Uh, ~we saw huge performance wins and also performance wins so great that we actually saw product engagement win,~ uh,~ from running the compiler. So ~that's, ~that's kind of how our journey has been in~ in the last,~ since we spoke,~ uh,~ I think a little before. Okay. Joe: Yep. Paige: Is there anything that you want to add to that, Joe, ~or did~ Joe: ~It's a great summary. Yeah, no, ~it's a great summary. Yeah. I think ~that, ~that about covers it. Yeah. ~Um, yeah, I think it just, just. Uh, ~I think we all ~kind of ~think of, ~you know, if you're, ~if you're used to using use memo and use callback, you might think ~like, ~Oh, I'm really good at memoizing,~ uh,~ and that's probably true. And yet the compiler can memoize [00:03:00] far more than you would ever think to,~ uh,~ like an example of things that people often,~ uh,~ don't think to memoize is the actual JSX elements at the end of their component. So you might have used memos and use callbacks for kind of the intermediate values that you're producing. ~Uh, ~and then you return some JSX,~ uh,~ and it turns out that actually memoizing those JSX elements allows react to,~ uh,~ to ~kind of ~diff and reconcile more quickly. ~Right. ~And that's something that the compiler just does as well. ~Um, ~and that, that can actually matter with things like,~ uh, if you, ~if you don't memorize children, that becomes a prop into a component and stack and kind of break memorization there. ~Uh, ~and so, yeah, ~it's just, uh, ~there's actually a lot more that you don't, you don't always think about that. ~Think about ~it can do. Yeah. Paige: So I think that's a really good understanding of react and how hooks work and, ~you know, ~just memoization and caching in general to be able to take advantage of all of those things. But if you have the compiler, you don't have to think about it. That's the best part is you don't have to have that deep level of understanding. It just does it for you, which is the best in my opinion. Joe: Yeah, [00:04:00] exactly. ~Yeah.~ Paige: All right. So one of the things that you talked about in the most recent react conf was the decision to open source the compiler. ~So. ~What kind of motivated ~that, ~that decision to take it open stage open when it's still a little bit experimental. It's not completely stable yet. ~Mm~ Sathya: ~uh, ~Joe, can you correct me if I'm wrong, it's make it right. Make it fast, but that's the last two, right? What's the first one? Joe: That's ~kind of ~the last one. ~Uh, ~it's, ~I mean, well, I guess the way, the way I think with the playbook is it's kind of different. Yeah. It's kind of, um, like what we, well,~ I think what you're talking about is ~like, we, ~we ~kind of ~talked about what this project,~ um, kind of, Uh, ~there's make it correct and to make it work for a subset of cases, expand that to cover more and more types of code. So for example, initially we only supported like if else for loops, let const, ~you know, ~and with ~like ~a small subset of syntax, right. Um, and over time, so we kind of ~build like ~expanded that to support more and more of the JavaScript syntax.~ Um, you know, but, ~but ~like, ~so ~focus, ~focus on correctness, then focus on increasing coverage,~ uh,~ and then focus on increasing performance. And so where we're at now is, ~you know, uh, ~there's actually a blog post of somebody who tried out the compiler and kind of noticed, Oh, like ~these, ~these, ~you know, ~[00:05:00] these cases aren't optimized yet. It's like, yeah, yeah, yeah. ~Uh, ~that's great. We love seeing a post like that because the funny thing is ~like, ~my favorite part of that post was like one, one sentence where ~like, ~I just, I dropped it into a bunch of my projects and it just worked and then they started looking at Oh, does it actually optimize? And we're like, yeah, yeah, yeah. But all, most of the time we've spent was on getting it like on making that first sentence true that you just applied it to your project and it just worked. Now that we have that foundation, now we can start doing all the performance optimizations, right? Paige: Yeah. ~Yeah.~ Joe: In terms of like, why open source now it's really, we need that ~like ~expanded set of feedback from the whole, ~you know, ~the whole community. What are all the edge cases that we haven't considered? ~Um, you know, ~what are all the libraries that people are using that might need ~like, ~that maybe they,~ like,~ those libraries might be subtly, ~you know, ~like doing, ~you know, ~doing something a bit different that we're expecting and we have to think about ~like, does ~should the library change? Should the compiler change,~ uh,~ how do we handle that situation? We need that kind of ex ~uh, ~extensive feedback now. Sathya: Yeah, we have a working group now to get feedback from,~ uh,~ people using the compiler and library maintainers. ~Um, yeah, I think, ~I think ~the, ~this is the part of the [00:06:00] project where ~like, ~we ~know it I ~want to make sure it works for everyone, not just Meta. Paige: Yeah, you have plenty of use cases within Meta, but you now need all the other use cases that ~you never, you know, ~Meta never had to consider that all the other weird little web apps that are out there too. Joe: Yeah. ~And, ~and that speaks to our goal with the project, which is, ~you know, ~we don't want this to be something that we just use at meta or that a small number of people use, we really want to make sure the compiler is something that the entire react community can adopt,~ um,~ so that we can then use it as a platform for building future innovations that again, the entire ecosystem can take advantage of. ~So, ~yeah, so really have to make sure it works for everyone. Get that feedback. Paige: that's fantastic. So you've talked a little bit about how ~it, ~it can optimize at a lower level than, Developers potentially could with use memo and use callback and how it takes ~the, ~the burden of them having to think about it or decide, does this value need to be cashed or not? ~What, uh, ~what functionality and role does the ES lint plugin react compiler play in this? How does it help make this [00:07:00] easier or better? Sathya: Yeah,~ so, um, the, ~the React compiler works by understanding the rules of React. So ~the ~React has some rules, right? ~Like, ~can't modify props. Should modify state that actually, ~you know, ~use the setter function. ~Um, ~there are like a bunch of roles that basically follow from keep components PR and the compiler assumes that and optimizes the code based on that. But it's not always possible to follow the rules. You like, ~that was, ~may have made a mistake or they may have had to like,~ um,~ not follow the rules for that instance. And we want to make sure that we don't incorrectly compile the code. ~Right. ~In that case, so we have a lot of validations in the compiler built in. ~Um, ~and we bail out from compiling that component. ~Um, ~so the compiler just leaves it as such, like we don't know what's happening. We don't want to mess with your code, but then we also want to give feedback to the developer that, Hey, we've found some mistake. ~Uh, ~you're not following the rules of react. And that's where the ESLint plugin comes in. ~Um, ~the ESLint plugin will surface these sort of,~ um,~ issues that, ~you know, Uh, ~the code has [00:08:00] with all intervals react. ~Um, ~so if you're a developer,~ um,~ and you want to use the compiler, we recommend that you turn on the ESN plugin first and then go through,~ um,~ any issues and try to fix that so that the compiler can compile more code. ~We, ~we use the ESN extensively here at Meta, for example. Paige: Got it. Very good. And I'm sure, ~I mean, ~I've used ~the, ~the react plugins for ESLint up to this day, and it's always been super helpful in identifying code that was written poorly. Or dependencies that I forgot to include in use effect or things like that. So I'm sure that having this to ~kind of ~help people write better code ~is, ~is only going to be a benefit for all of them. Joe: Yeah. ~And, ~and it can take advantage of the more precise analysis that the compiler is doing. ~Right. So, um, you know, ~Detecting modifications to props, which is something that the existing ESLint rule doesn't detect. ~Uh, ~detecting patterns ~like, um, uh, ~like unconditional set state in render. So it's possible that I ~kind of ~write code that can cause an infinite loop. ~Um, ~and so ~we, like, you know, ~the compiler can detect that,~ uh, ~and a couple other patterns,~ uh, ~accessing refs during render, that's something we're still improving our [00:09:00] validation for. ~Uh, ~but yeah, ~so ~the compiler has, ~you know, ~much more detailed understanding ~of the, ~of your code. ~Um, ~And so it ~can, you know, ~can produce,~ um, more, ~more precise,~ uh, ~warnings. And so there's also ~kind of ~like part of how we think about this is ~like, ~it's not just about detecting problems. It's also about teaching the user. So if you're just starting out with react, and if you were to use this, ~you know, that ~it can be a learning opportunity for, Oh, ~I'm not supposed to, you know, ~I'm not supposed to modify props or I'm not supposed to modify state, and then we can link you to an article, right? ~Uh, so. ~ Paige: I remember when I started using,~ uh,~ ESLint a few years ago, ~that was,~ I actually wrote a blog post about how it made me a better developer and it's exactly for those kinds of things. It links to the TypeScript errors, it links to the warnings, it shows you better ways to write good code and ~it, ~it is, it's a great learning tool. Sathya: Yeah,~ um,~ I think one of the things that I learned when I joined the team is the rules exist to help you build,~ uh,~ like complex and scalable UIs. It's to enable UIs and it's just the compiler gets to take advantage of it. ~Sound like work. ~Like we weren't adding these rules to make the compiler happen. It was like the rules exist to help all DUIs, right? ~Like ~that was like the fundamental [00:10:00] reason for the rules. So that,~ um,~ you can reason about components in isolation. It's just, it's so good that the compiler can actually benefit from that. Which is interesting for me because I actually hadn't done a lot of React before I joined the team and I come from like a compiler background. I was like, Oh wow, this programming model is so good. ~Um, ~that was really interesting for me. Paige: That's very cool. So we've talked a little bit about what the compiler is, how it works. What do you actually need to be able to use it? What are some of the prerequisites for getting it? ~I, ~I know that react 19 RC is necessary, ~but you know, ~what else do we have to turn on to be able to take advantage of it? Sathya: ~Um, ~right now, the compiler ships as a Babel plugin. ~Um, ~so there's a hard dependency on Babel for now. ~Um, ~and then, as you said, there's a hook that the compiler,~ uh,~ needs, which is shipped as part of the React 19 RC.~ Um, ~yeah, I think that those are the two main things. ~Uh, ~we're also getting feedback from early adopters on,~ um,~ [00:11:00] whether to ship the hook as a separate plugin. package potentially,~ um,~ that's still, we're still getting feedback on that from the working group. Joe: Yeah, just to add, ~we've~ a bunch of ~like, kind of ~libraries and frameworks have added instructions. ~Um, ~For,~ uh, how to, ~how to adopt the compiler. So it's pretty easy. ~Like if, ~for example, like ~in, ~in next, and I saw ~over like ~a couple of days ago, Expo added it and ~I know a few, ~I think a few other libraries, ~I think, ~I think remix also supports, ~I'm, ~I just can't remember that we actually had ~like ~a bunch of libraries and frameworks add, make it really easy to try out. So I cannot remember all of them, but ~it's on, it's on the, ~it's on the learn page on the react. dev site. ~Um, ~So that's pretty easy to adopt there. ~So ~for example, even like next JS is ~like ~primarily using,~ uh, like ~an SWC based bill, they've added an option where it just, ~you know, ~invokes ~a ~Babel, ~right. ~For the compiler step. ~Um, ~So that works pretty well. And then,~ um,~ yeah, in terms of that, like the 19 dependency,~ uh,~ that's something that ~right, yeah, ~right now it kind of does depend upon this hook, but we have an option that lets you use it in older versions, the thing that we are still trying to figure out is ~kind of. Yeah. Uh, ~so for ~like ~adopting it ~in a, ~in a project, like in an application,~ uh, ~pretty easy to adopt right now, where it's a bit trickier right now is if you are a library [00:12:00] and want to use it, because you have to think about ~kind of ~working with different versions of react. And so that's a piece that we're still working through is how do we make it so that, you know, Kind of makes sense for libraries to compile their own code. Cause they're the ones who know, like they can actually test their code with the compiler and make sure it works correctly. ~Like I shouldn't be like, you know, if I, if, if, if, ~if a product chooses to compile their dependencies,~ well,~ like now they might be breaking the dependency and that's not great. ~So, um, ~so it ~kind of ~makes sense for libraries to publish compiled code, but then how do they work with different versions of react? That's something we're still trying to figure out and, ~you know, ~over the coming months. Yeah. Paige: ~Mm hmm.~ Joe: But for applications, it's easy to try out today. ~Yeah.~ Paige: So there are actually some alternatives if you want to try it out, but you don't necessarily have the ability to upgrade to React 19 right away. Joe: Yeah, exactly. You can ~kind of ~basically polyfill this, ~the hook, ~the runtime hook that it's using. Paige: Nice. Alright, so you talked about using it with Babel. Are there any ways to use it with Vite or with Webpack or any other compiler tools right now? ~Mm~ Sathya: ~Um, ~that works. I think it mostly works with all of ~the, the, the dual, ~the [00:13:00] main,~ uh,~ frameworks,~ uh,~ that Joe just mentioned. ~Um, ~yeah, I think it just works out of the box with most of them. Paige: And that's fantastic. That's what you want to hear is it just works. I just change a name or I update a package and I don't have to worry about it beyond that. Sathya: Yeah, Paige: ~All right.~ Sathya: we had a lot of feedback from folks who just didn't know the compiler was running because it was just so easy to like run it. How do I know it's working because I didn't have to do ~like, ~yeah, there's no edit. There's nothing going wrong. Joe: Yeah. ~So, ~and to answer the question,~ uh,~ DevTools, ~if you do, ~if you use DevTools,~ uh,~ you'll actually see ~that a component, like ~which components got memoized. ~There's like a~ Paige: ~Mm~ Joe: ~uh, like, uh, ~sparkles, like memo with some sparkles on it, and,~ uh,~ it'll show you,~ um,~ the components that got memoized. So that's,~ uh,~ that's one way to check. You can also look at, of course, the compiled source code,~ uh,~ as well, but just looking at the DevTools will show you, Paige: Oh, nice. ~That's, ~that's a really good tip.~ So, ~one of the things that we were curious about is what does the health check script do? ~How, ~how can it help developers to prep their code bases for React Compiler? Sathya: ~Um, ~yeah, ~the, um,~ we ~kind of ~wanted to,~ um, ~ set the [00:14:00] expectations for,~ uh, ~folks adopting the compiler on how effective the compiler would be. That was one of the main motivations, it's to ~like, ~give them an overview of ~like ~how many components the compiler can compile. What are the ones that aren't compiled, if there's any,~ um, ~packages that they use that don't work with the compiler. ~Um, ~and then, like I talked about the rules of React,~ um, ~the compiler strictly,~ like, ~models that. So if you violate that, then it could be a problem. So we use,~ um, the, ~the percents of,~ like, ~strict mode as a proxy for,~ like,~ hey, you're probably following the rules of React. So that's,~ like, ~another signal for us that the compiler might just work out of the box. ~Um, ~so it's mostly to,~ like, ~set expectations and,~ um, ~ For developers to understand how effective the compiler would be on their codebase. Paige: ~cool. Got it. ~All right. ~Um, ~so if a developer does upgrade and start using the react compiler, are there common issues that they might face when they first start ~if it, ~if it doesn't just work out of the box? And do you have any suggestions for how they can go about debugging them or addressing them? Sathya: ~We, ~we have a bunch of,~ uh, um, ~docs, like [00:15:00] we have,~ uh, ~troubleshooting questions on them, like for the common issues. ~Um, ~I think ~that's, ~those should cover ~like ~some of the common ones that were the configuration doesn't really work. ~Um, ~or if there's ~like ~a one time issue,~ um, Um, ~I think one of the things that I actually want to talk about that ~I, ~I was ~like ~react summit last week and this question came up several times. Um, and one of the questions like the bundle size does increase with,~ uh, ~forget, and everyone's like, people are worried about that. ~Um, and ~what we've seen at Facebook is even though the bundle size does increase the overall,~ um, ~visual completeness metric does decrease. ~Um, so ~it turns out that,~ um,~ To ~like ~finish a single render or ~like finish, uh, ~the initial load of a page, React does multiple renders. ~Um, and ~even though we might ship slightly more JS, the multiple renders that happen as part of initial load, Paige: ~Mm hmm.~ Sathya: they're like way shorter now, so it pays off. Paige: Yeah. ~Yeah. Yeah.~ Sathya: I think ~that's, ~that's the main question I got,~ uh, ~which I want to make sure that people hear. ~Yeah.~ Joe: ~Yeah, ~yeah, definitely. ~It's, ~it's about like the ~overall ~overall performance, right? That's actually, it goes back to ~when, um, You know, ~when we started out with the project, we were ~kind of ~trying to figure out, okay, ~like, ~how can we get a sense for that? This is going to [00:16:00] be, ~you know, ~good or not. ~Um, ~and ~like one, ~one idea that we like bounce around, it's like, okay, what can we ~count, like the number of measures, uh, or, or, I'm sorry, ~count the number of,~ uh, of re ~renders ~of, of like, of, ~of components. ~Um, ~but we kept on focusing on is no. And that's, it's all just like a proxy metric bundle size. All these other things are proxy metrics for what really matters, which is actual performance at the end of the day. And so we kind of get them pushing through. And so the other thing is,~ uh, ~on ~the, ~the bundle size question. ~Um, so. Well, ~everything that Satya said is true. Like we've definitely seen that overall,~ uh, tends, ~tends to kind of net out ~at a, at a, ~at a loading time when, despite having, uh, you know, being a bundle size, a small, you know, it's like a small percentage, at least from what we've seen, uh, bundle size regression, especially ~after you get, like, ~after you get through like, you know, gzip and everything, ~uh,~ modification. Um, but we're also looking at, ~you know, ~optimizations like,~ uh, in, ~in some cases the compiler is ~kind of ~producing more code ~than it, ~than it strictly needs to, and we can add optimizations that will ~kind of ~compact that code without regressing any of the memorization. This kind of speaks to the earlier point around, ~you know, ~first we focus on getting it to be correct, then increasing the coverage. And now we're really focused on ~like, actually it's really getting into like the, the optim, ~the optimizations. ~Um, ~and just in the last couple weeks we've already landed a few things that kind of,~ uh, ~shrink the output and we've got more stuff planned there as well. ~So, ~yeah. Paige: ~Very, ~very nice, and [00:17:00] I think ~you, ~you hit the nail on the head, Joe, is people have long used bundle size as ~kind of ~an indicator of this may affect ~my, ~my site's performance negatively, but it doesn't always, ~and. You know, ~it sounds like we just ~kind of ~need to detach ourselves from that being the one metric that we all focus on and ~kind of ~look more towards the overall experience or performance. Joe: Yeah, Paige: All right. Very cool. So there is one,~ uh,~ directive that I'd like to hear more about, which is the use no memo directive. So maybe you could talk a little bit about how that works and what kind of scenarios it would be used for. Sathya: ~So do you want to~ Joe: ~yeah, sure. Um, well we, ~we love directives. ~Um, ~and so we couldn't resist the opportunity to add another one. ~Uh, ~Yeah. ~Um, yeah, ~we thought about adding more,~ um, ~and that was ~really, ~really tempting, but we decided not to,~ um, we, ~we know that people have thoughts about use client and use server. ~Um, ~and so we were ~very, ~very, ~you know, uh, you know, ~careful in ~considering and ~considering this. ~Um, we definitely don't, you know, ~as we mentioned earlier, like ~we, ~we really want the compiler to just work out of the box and in general, you shouldn't have to think about it. ~Um, ~there can be cases though, where,~ uh, ~you might be, ~you know, Breaking, kind of ~breaking a rule of react or doing something a bit, you know, a bit outside ~the, the, ~the bounds, ~you know, um, ~in a [00:18:00] way that the compiler can't detect yet. And so use no memo is a way to say. You know what, just don't compile this component. ~Um, the compiler, you know, um, ~you might also be doing something that's perfectly valid and the compiler misidentified and thinks it's a component when it's not little things like that, or like thinks it's a hook and it's not ~right.~ And so this is just ~a, a, a kind of an, um, ~for edge cases where you just want to say, no, don't compile this. ~Uh, ~but ~the, ~the idea is that over time that really shouldn't be necessary that the compiler should just be correct. You know, as much as possible, always correctly identify components and hooks, not have false positives there. ~Um, ~Always know when it's unsafe to bail out and do that automatically. ~Um, the, the, the, the, in, ~in reality, we'll probably never get to a hundred percent there, right? And so you might, the directive will probably stick around, but it should be something that you have to use only very infrequently just to say, you know what? ~Just, ~just skip this component. Paige: so it's a very explicit way of saying ~don't, ~don't worry about this code. ~You know, ~it may. It may just not work for you, but I know it's doing what I needed to do ~in the, ~in the app. All right. So we talked a little bit about the, ~you know, ~developers are giving feedback. They're trying out the experimental things. There's some [00:19:00] FAQs if they have questions. ~Are there, ~are there any other ways that they can either get in touch with your team to give you feedback or how would they file bug reports or issues? What's the best way to ~kind of ~reach out and say that they're having problems or ~they, ~they could use some guidance. Joe: File a GitHub issue, absolute best way. File a GitHub issue. We have a ~playground, ~playground. react. dev. ~Um, so ~you can ~kind of try to, ~try to create a working,~ uh, you know, a ~repro there. ~Uh, ~we've also had a bunch of people,~ um, do, you know, ~create a small,~ uh, small like repository, like GitHub repository, uh, ~GitHub repo that demonstrates the issue. ~Um, ~that's also good as much as possible. They're like, like a playground, you know, repro. Filed in a GitHub issue is the absolute best thing for us. Cause then it's very easy for us to repro it and diagnose. We've had a whole number of people do that already file a bunch of bugs, which we've been able to fix. That's been great. So definitely do that. ~Um, You know, ~I think blog posts, ~you know, ~work too, ~but, uh, ~but the thing is there. I think what can happen is people ~kind of ~can misunderstand the context and it's really great if we have a chance to just, ~you know, if, if you're gonna, ~if you're gonna take the time to figure it out, ~like ~file a GitHub issue so we can just see it and address it, ~you know?~ So definitely appreciate that. Sathya: If you tweet with the words react compiler, the team will show [00:20:00] up. Joe: It's a magic Paige: that at all times. Joe: ~Yeah. ~Yeah. ~It's,~ Sathya: Maybe. ~Please,~ Joe: unfortunately Sathya: don't Joe: true. ~Yeah.~ Sathya: Please file ~GitHub issues.~ Joe: Yeah. If I'll get to have issues, it's definitely the best thing for us. ~Um, ~yeah, it's,~ uh,~ there's just so much to keep track of these days. ~Right. Like ~so many different forums. ~Right. Um, ~so yeah,~ we, we know that ~we know that ~we're like, ~we can't possibly ~like kind of ~keep an eye on everything. And so we get to have issues are definitely the best way. Also, it's really early too. ~So, you know, ~a lot of these things are ~like, it's ~experimental. We know there's going to be bugs, ~you know,~ Paige: ~Mm hmm.~ Joe: ~so~ Paige: ~So knowing that it is, knowing that it is, ~knowing that it is experimental,~ uh, ~what's the roadmap for the continued development of it and the stable release? Do you guys have any idea when that might be or is it very much still based on community feedback? Sathya: Yeah, I think it's still based on the feedback. I think we're in the early stages of getting feedback. ~Um, ~with the working group, I think as the working group progresses, we'll have a better idea of like how stable it is in the ecosystem.~ Um,~ Joe: ~Yeah,~ Sathya: and then, yeah. Think about stable. Joe: ~yeah, ~yeah, I think about it is,~ um,~ this kind of early stage as we talked about earlier is about,~ uh, kind of ~having applications, try it out,~ um,~ give us feedback. ~Uh, ~we still need to figure out [00:21:00] what the kind of plan is for how libraries could adopt the compiler and deal with kind of the multiple versioning so ~that ~that has to get figured out before we can go stable. ~Um, You know, ~I think we definitely have a bunch of options, like improvements and optimizations planned,~ um,~ that we ~kind of ~want to land those,~ uh,~ and a few other kinds of pieces that have just things that we're looking at with, in terms of how this fits into the overall, like direction of react and ~like, you know, ~future we're like, cause we're continuing to evolve the runtime APIs and ~kind of ~lining this up. And so we've got to make sure,~ uh,~ part of how we think about releases is it's not just releasing like individual features, but ~kind of ~having a cohesive story for how that release really adds up. And so ~kind of like, you know, ~think about that in terms of where do we go from 19? So it's experimental now, maybe this lines up with 20, maybe it's 21. We'll see,~ uh,~ again, it really ~kind of ~depends upon how the, how all these pieces,~ uh, how, ~how long they take just, but yeah, what matters to us is that this be. ~You know, ~really something that developers can rely on. ~Uh, and so, and, ~and that it can be a foundation for us to build upon. So ~the, ~the kind of auto memoization piece that we've talked about, we've been ~kind of ~talking about React compiler and auto memoization is almost synonymous, but really it's,~ um,~ it's ~like, we, we, ~we already talked about another piece of it, which is ~the, ~the linting, right? So the compiler is actually providing auto [00:22:00] memoization. It's providing these linting. ~Um, ~and we've got ~like ~more ideas planned ~for, ~for what we can use the compiler for. ~Um, An obvious kind of ~an obvious one is,~ um, ~ so for server side rendering,~ uh, you know, ~effects don't run. ~Uh, ~so what if we could produce an optimized SSR build that can strip out the effects,~ uh, ~or like inline use state and just use the initial value,~ uh, ~and then that could let you ~then ~do some,~ um, Uh, ~dead code elimination by like removing the imports that are only used inside the effect, for example. And now you can load up less code when you're doing SSR. So that's an obvious other area that we could begin to explore now that we have a really good knowledge of your code and understand what are the effects? What are the states? What are the things we can actually prune? Paige: Okay. ~Okay.~ Joe: So yeah, there's other pieces like that, that like we want to be able to build too, and so it really matters to us to take the time and get that foundation really right. Paige: ~Mm hmm. ~That makes perfect sense. Is there anything more that you could share about how React Compiler is being used in production environments at Meta? I know you said you had some good initial feedback from it, but ~could you, ~could you talk any more about ~like ~what components, ~like~ you used it with and how it [00:23:00] improved them? ~Mm~ Joe: of everything, although like the most recent stuff at the conference. ~Um, so, um, ~so yeah, ~you know, ~we've used it on IG web. ~Um, ~we're on Oculus, ~the quest, ~the quest store. ~Um, ~and then a few other places. ~Um, ~Yeah. Just basically continuing to roll out ~on, on, ~on more and more services. ~Uh, and, and, ~and as Satya mentioned, like in general, ~kind of ~seeing,~ um, uh, you know, the, ~the startup time wins ~are kind of,~ kind of depend, right? ~If you have, ~if you happen to have a case that just has a single render,~ well,~ then if there's no re rendering, then memoization can't help you. So, uh, it kind of depends upon ~the, ~the surface to surface, ~whether we see, ~whether we see a startup time wins. ~Um, Um, ~but,~ uh, ~certainly like interaction,~ right,~ is where interaction performance is where we ~kind of ~tend to see more of ~the, ~the wins. ~Um, ~so yeah, ~for the, ~for the exact numbers, I definitely just refer people back to the talk. ~Um, I don't, ~I don't have, I just, I don't have them at hand. ~So, uh, I can't, ~I can't share it, but definitely, ~you know, ~wins across those types of metrics. Yeah. Paige: Yeah No, that's totally valid. ~Um, so, ~what kind of advice would you give for developers who are a little bit on the fence about adopting React Compiler? Should they go ahead and just start trying it now, knowing that it's still experimental? Or should they wait a little bit before going for a more stable [00:24:00] version of it in the future? ~Mm~ Sathya: think it's good to try it. I wouldn't recommend shipping to production right now,~ uh,~ waiting for stable,~ uh,~ although they ship to production, but definitely run the health ~script. ~script and the ESN plugin,~ uh,~ so you can prepare for,~ uh,~ the compiler. I think we've seen with folks adopting the ESN plugin that other people on the team start fixing issues as they see. ~Uh, ~so ~it's, ~it really,~ uh,~ prepares the code for the compiler when it becomes stable. So we'd recommend adopting the ESN plugin now. ~Um, ~[00:25:00] Yeah. Joe: And ~so, uh, ~definitely want to be cautious there. So yeah, just testing it, but not necessarily using it in prod. Paige: Yeah, that's great advice. Is there anything else about React Compiler that we haven't touched on yet that you'd like to make clear or make certain that people know about? I will take your silence as no, we have covered everything there is. Joe: that's, I think ~that's the, ~that's the key things like, ~right. Like, I mean, it's, ~it's always fun to talk about how it works. ~Uh, you know, uh, that, which, which, ~which helps answer the question of whether it's a compiler or transpiler once you understand how it works, ~right.~ But,~ um, But, uh, ~I think what really matters like for users is that you don't have to understand how it works. The idea is that it's ~just, it is ~just drop in. ~Um, and so, yeah. Um, you know, ~give it a shot,~ uh, ~definitely adopt ~the, ~the excellent plugin,~ um, and, ~and give us feedback on GitHub. ~Yeah.~ Paige: ~Well, that is, ~that is great advice.~ Is there, or I guess,~ where would users go if they wanted to either learn more about using react compiler or talk to you, talk to the team, get in touch. ~What's the, ~what's the best place ~to, to keep, ~to go forward from here. Sathya: ~Um, ~we have a docs page on the react. dev site,~ uh, I'm trying to~ Joe: ~React dot devs. Yeah. ~React dot dev slash learn slash react dash compiler. Sathya: You go Paige: Perfect. ~We will make~ Sathya: that has all the Paige: link to that. Sathya: Yeah. [00:26:00] That has all the instructions ~on, uh, ~on how to install the compiler and ~like ~debugging some of the more frequent issues. ~Um, ~and then if they have any ~Yeah. ~Compiler, bugs or ~like ~any other issues, file an issue on GitHub.~ Um, ~yeah, don't. Paige: Don't Sathya: joking about that. Joe: ~Yeah, ~yeah. And ~the, ~the page has,~ uh, ~just to ~like ~expand on our earlier answer that, ~you know, ~the page we've got instructions for ~using, ~using it with Babel, Vite, Next. js, Remix, Webpack, Expo,~ uh, ~and Metro for React Native. So yeah, lots of integrations that are already really easy to get going with. Paige: Oh, fantastic. ~Check. Well, ~Satya and Joe, thank you both for coming on the show. It has been a pleasure having you talk to us today about React Compiler. Sathya: Yeah, for sure. Thanks for having us. It was great chatting with you. Joe: Yeah. Thank you so much, Paige. Really appreciate it. Paige: All right. We will see you on the next episode of PodRocket.