React 19 Panel Discussion

Let's give a massive applause for the person you've just heard, for Ryan. Also, coming in from Shopify, we have Brooks. Give it up for Brooks. We also have the wonderful, the amazing, Evan. Our wonderful unsung hero in the world, especially of Next, we have Tim. And last but definitely not least, we have Satya as well.

All right, now, I will speak for myself. Sometimes people's Twitter profiles or maybe sometimes what I've seen from them on GitHub, it's one thing and I know their names, but then I actually meet them in person and I find out what they actually do and I'm like, oh, my gosh, this person does so much more than I realized. And this is how I feel about a lot of the speakers today. So let me just quickly tell you a little about what some of them do. So we have Satya, who is a React core team member and specifically, which is really useful to this conversation, did a lot of work on React 19, sorry, on the React compiler for React 19. Really excited. We also have Tim from Vercel, who is the co-creator of Next.js. Personally I want to thank you because Next.js is the framework that I usually grab first whenever I'm building things. We also have Evan, who is the co-creator of Expo as well. Thank you so much. I've listened to so many of your talks. We've been at the conference circuit quite a lot. So I'm excited for what we're going to talk about today. And a DevRel manager of Remix. Remix stickers are some of my favorite stickers. So I would like to say thank you very much, Brooks. And I don't know if Ryan needs a third introduction, but we all know Ryan from Solid.js balancing out this panel so we can have a great conversation.

All right. So a lot of people on this stage are React super fans, and Ryan. I'm joking. But like, we're all here and we're all very passionate, excited about some of the highlights that are coming in with React 19. So let's just start with some of the big headlines from each of you. So what are the big things that maybe you're excited about or you think are going to grab a lot of people's attention from React 19? I'll start with you, Satya, and we'll work our way down. So this technically isn't part of the 19 release itself, but it is unlocked with the 19 release.

It's the React compiler. I'm biased, but that's what I'm excited about. Yeah. I know we're going to come back and dive into the React compiler, especially the history of it. But that's a big headline.

And yourself, Tim? What about yourself? Yeah. Not sure if it's working. Oh, yeah. This is better. Yeah. I really like pretty much all the new APIs, but especially transitions and suspense, like how they play together. And obviously, server components is stable now, so that's good as well. Awesome.

Yeah. So if you guys aren't familiar with Expo, it's a React Native universal framework, and I am super excited for server components coming to React Native because it enables all the fine-grained data fetching and rendering patterns that we've come to know and love from tools like Next.js and Remix, but universally. So on iOS, Android, Web, basically any platform, which there's never really been anything quite like that in the native development world. So extremely excited.

Personally, yeah, something I'm really excited about is all the head tags, like links and meta and all those things that they automatically get hoisted into the head. I think that's just a really nice API design. It allows Remix and Next and all of us just to kind of stop having to do that piece ourselves, and it all kind of puts it in just a React way versus more bifurcation and more ways to do the exact same thing. So I'm really appreciative of that API and all the work that the Next team I know did to make that happen, and the React team as well. Awesome. And anything that stands out to you from React 19 that's tickling your interest? Yeah, I mean, there's been a lot of ergonomic improvements, like small things that just make it nicer on the developer. I think that's really like, moving forward, ref. And it's also one of the reasons that I'm kind of excited about the React compiler, is because I like the prospect that idiomatic React code is the most performant React code. That split has always bugged me a little bit, and I think the compiler goes a long way there.

Well, I feel like this is a perfect segue to circle back into React compiler. So tell us a little bit about the history, kind of where the idea to build a React compiler started from, and then how you progressed through the design process, iterating it. I know you talked a little bit about yesterday in our private conversation about working with it inside meta before coming out and releasing it. Yeah, so we've thought about the compiler for a long time on the React team.

I actually saw a comment from 2015, talking about an optimizing compiler. So this is something that the team has been thinking about for a long time. Something we just thought of. And we've tried multiple times over the past six, seven years. There was an attempt from Dominic Galloway, who works on Svelte now. We tried that internally, we learned a lot of lessons from that. And then a couple of years ago, we tried again, which is now the React compiler. So there was two iterations of the React compiler that we just shipped recently. The first one actually didn't ship, we tried to ship it at meta, we ran into some issues, we learned a lot of lessons, and then we rewrote it again. And then we spent almost a year trying it out at Facebook, trying to see what were the issues and how to fix them. And we're at a place where we're happy to share with the community. So our thing has always been make it right, make it correct, and make it fast. So we're at this point where we're like, okay, it's time to share to the community, get feedback from the community, and then make it stable.

No, for sure. And I love how you've taken it, you've finished cooking it, let it bake before bringing it out. And you folks here, you are also, I would say, part of this community, big parts, you, I would say, lead or in some way, influential in massive sections of the React community. So what's been the kind of uptake of React compiler, or the way you think it's gonna change or influence things down your individual paths? I'll start, I guess. So one of the things that I really like about React compiler is that it allows you to write the React you always wanted to write. So just use functions as functions. You don't have to think about, like, use callback or use memo, that kind of thing. And then just let the compiler optimize that for you. And it's already showing that you can do more optimizations than just the thing that you would think about yourself, right? Like memorizing JSX calls and specific parts of JSX that never change and things like that. On top of that, it changes the rendering to be the way that you expect it as well. So it doesn't re-render parts of the tree that hadn't changed. Whereas if you use React normally and you're memorizing everything, you did everything right, you're still seeing more re-renders than you should be seeing, at least in the mental model that you have around how React renders. So it fixes like, one example is that, like, I showed this to a colleague, and this colleague was like, but this is how React always works. And I was like, yeah, no, it's actually not the way that you think it works. And now it actually is the way that you think it works. I love that whenever you take something and simplify it, so what I read or what I expect to happen is actually what happens as well, I know for sure. And yourselves, any things that stand out to you?

One thing that I really love about React's API design is over time, it has really folded itself away into the language and just felt more native to the runtime that you're running in. So instead of doing extend React component, you create a function, instead of doing create element, you have JSX. And with server components, you have this opportunity to write components which feel very ergonomic, where you're writing async in a way, and you're fetching data, and it just feels really a lot like JavaScript. But then that created this kind of asymmetry between server and client, where on the client you still have a ton of hooks to do things like use memo, and so you're writing components which just look very different. And now with React Compiler, you're able to fold a lot of those hooks away, and it makes it a little bit more symmetric across server and client, and it feels more native to the platform, even though compiler does make React feel more like its own programming language than previously. But I think that's great, because the hooks, they kind of sometimes break your mental model, and this leaning more into it makes it feel very native to what you're writing.

Yeah, following up with that, I'm curious to see if there's a bit of a sense of loss with like, oh, I learned all this knowledge of how to write, use memo correctly, and how to memoize all my stuff by hand. It's similar to me to all the state management libraries and stuff. I was very into that. And they're still very useful for a lot of things, but I way overused state management, and then once I started using Remix, and we just had a very simple loader component action kind of model, and it was pretty easy to do ephemeral mutations and all this kind of stuff. I just stopped caring about state, and it felt like a little bit of a loss, but then at the end I was really happy, and I kind of wonder if the compiler's going to do the same thing. It's like, oh no, but all my knowledge, and it's like, oh, I don't actually need that knowledge, and it's really nice that I don't need that. I can now fill my head with more useless knowledge. Yeah, it's interesting that you say that, because Satya saw me last night about handmade memoizations and how React Compiler is just far more performant. Yeah, so with the use memo hook, you can't call it conditionally. It needs to be at the statement level, but the compiler can compile values within a conditional, so it's more... I really don't want to say fine-grained, but... Careful. It is more fine-grained, less granular than a use memo, and it does... The other problem with manual memorization is it can be brittle if you're not careful, and you miss memorizing one value, that can cascade down all your components and cause re-rendering of everything. But with the React Compiler, the compiler is way better at making sure every single value is memorized, so your components are more stable, and they don't re-render more often. Yeah, at Facebook, for example, we have engineers who work on performance and have spent a lot of time thinking about optimizing product code with use memos. And when we wanted to ship the compiler, we thought it would be like a DX win, and the performance would be the same. But we actually saw better performance, and we also saw that the performance increased so much that it led to engagement wins on the product. So it is definitely a lot more than manual memorization, at least on a reasonably-sized app when you have multiple people working on it. I see lots of head nods on the stage, which is always a good thing to see as well. It's exciting. It's so exciting. Drop it in, and your app becomes more performant. Yeah.

Yeah. It's not so much the sense of loss. It's interesting. I think your React knowledge is still very valuable here, but the difference is now you've pushed it back, right? You can go so much further before you actually need to worry about that. And sometimes that distance is enough that for a lot of people, they don't ever hit certain categories of problems. The model hasn't really changed at all, which is the kind of amazing thing about this. You keep the idea that if your functions are basically pure, then everything else follows. No, for sure.

All right, let's talk about the impacts of React 19. Let's just go down some of the framework-specific and the kind of ecosystem of frameworks that exist. First of all, let's talk a little bit about some of the times taking functionality or things from React 19 and then implementing them or bringing them to the frameworks. I know you did a lot of work bringing server-side components to React Native. How has that been, and what's that journey been like? Yeah, fantastic. It's very difficult, but very rewarding as well. The kinds of things that server components enable on different platforms is mind-blowing. I'll be talking about this later today, so I highly recommend it because I'll have demos and I'm a visual learner. Humble plug, humble plug. Yes, I find it hard to learn from text. The experience bringing server components to React Native has... I think when I was talking with Tim yesterday, he said it was kind of vindicating because the design of server components is meant to be very universal, and it's meant to kind of exist in this React-first world, and being able to just lift so much of that and place it in the totally different runtimes and have it work almost verbatim. There's a lot of changes that need to be made, but many of the core ideas which weren't being run against native devices when they were being originally written just worked. Which is fantastic. Just worked with a little TM there at the end. So yeah, fantastic. Having streaming built in, you almost never see streaming built into a native app, and then having that just come together, streaming down into native views, I don't know. Just feels probably the most magic I've felt since I first used React and React Native, and I was mind blown coming from an objective C world and having things just be so fast and composable. And for the rest of you as well, when you're working with when new React comes out and all of the features come out, were there any things that stood out as having a big impact in your framework specifically, maybe like server-side components?

Yeah, it's definitely interesting to see that for Next.js, a lot of it was actually moving back all the pieces that Next.js had. So we had getServerSideProps, getStaticProps, getInitialProps, if you've been around long enough. And all of these went away, they're gone. They're gone in so far that page strider still supported, just want to mention that you don't have to migrate to App Writer, that kind of thing.

They're gone in the sense that you don't even have to think about it anymore, you just have components that can be async now and those components can do the data fetching, they can do caching, that kind of thing. For us, it was like a lot of working with the React team to actually bring all the things that Next.js does by default that we have implemented over the years. It could be script loading, for example, if you click on a link and you go to another page, Next.js would inject the script tag, Next.js would inject the styles, Next.js would fetch your data, that kind of thing. It would prefetch all of that. And all of those APIs are now part of React itself. So we were actually able to, in App Writer, we were able to remove around 10 kilobytes of gzipped Next.js-specific runtime code because all of that just moved into React instead. So we had to make the React DOM APIs that allow you to load extra JavaScript. Now the big difference there is that you no longer have to think about timing of things. What we have to do is we have to wait for the JavaScript loads, now we can actually render the React components or things like that. But especially CSS is a good example of that. If you type all of that into React itself, it can actually do all the scheduling and timing of renders as well. It can tie into suspend, showing loading state, it can tie into not rendering anything until your CSS is there. It's very important to avoid that flash of installed content because otherwise you start rendering the DOM nodes and you would see your title but the title is suddenly twice as large because the CSS loaded later, that kind of thing. And if React can do all of the scheduling, it can actually wait for that CSS to load before it starts rendering something to your screen. It can still render the virtual DOM but only apply it when everything is ready. So that was for us a really cool thing, and moving next head, providing an API in React to do the same thing where you can do link tags or title or things like that anywhere in the React tree and it will automatically figure out do dooping and injecting to head and things like that. Where you can use real React to render your head tags as well. Next head was kind of hacky because we tried to traverse the JSX tree to create a fake render of React. It's good to have a render component in next head for example because we don't know how to render components because we are not doing React and all of that is now part of React itself. So now we can just render a title tag and do data fetching or it can be a component that does data fetching and all of that just works. So a lot of that. And then you get a bunch of free optimizations on top of that, which is like streaming, out of order streaming, showing fallbacks and things like that that unlock newer features like partial pre-rendering. I feel like it's always nice when a new thing comes out that means you have to do this. Which is always the thing we would want as developers to be able to build the best while doing this.

Let's kind of just take a step back and maybe get a little bit less technical and talk about how the sausage is made. Because you folks all kind of work in this ecosystem, right? And you've been kind of having discussions. I know Next.js has a React team, Meta has a React team. What's it like working behind the scenes to make the versions of React come out in a way that is beneficial to all of these frameworks as well?

So if you've seen the latest release, there's a lot of inspiration not just from Next. I want to give a shout out to Remix as well. A lot of the form actions were inspired by Remix. And a lot of it was also inspired by Meta's internal stack. So the way we build React, at least on the Meta side, is we look at solving problems that we face on building Instagram or Facebook.com. And we try to solve that. And that's kind of how we think about solving problems. And then we collaborate really deeply with folks from Remix and Next and Expo. We have meetings with Expo as well. So it's not just the Next team and the React team. We care deeply about all of our Meta frameworks and also the libraries. I spent a lot of time yesterday talking to Dominic who works on React Query, talking about the data fetching changes. So we collaborate with... We have active collaborations with a lot of teams. And yeah, we have a lot of context shared with the Next.js team because they used to work at Meta on React. That's why we're more closely aligned on things we work on. No, for sure. Sorry. I didn't mean to exclusively put that between Next and Meta. I'll rephrase it. I meant the whole community. And it's also good because I know, like you spoke about when we were talking earlier about how you're really excited about form actions as well. And things like that. So what do you think about...? Yeah, I mean, it's a lot of what Tim said. It allows us to get rid of API. Right now, React Router and Remix, we kind of have the problem where we have a lot of API, and it's a problem we intentionally took on because a lot of that is for migration paths. We're really, really keen on having good migration paths to get to the next version.

So I don't know when we'll be able to necessarily get rid of all of our hooks necessarily or even rewrite them to use the fundamentals of React 19 because we do need backwards compatibility to 18 for at least a time. But it is exciting at least to be able to start stripping things away, like I said, with the meta tags and links and everything hoisting. So that's an entire API we can likely just get rid of, which is really exciting.

And then also, I'm really excited about the way we're approaching React Server Components, not necessarily because it's better or anything, but because it allows for an option that's much more opt-in of like, oh, I want to try React Server Components on this page or I want to try it for this feature. And for me, it was actually a really helpful paradigm because the way we're doing it, if you're unfamiliar, is you can send a React Server Component down through a loader. So as data was a really helpful concept for me because I didn't really understand RSC before I thought of it as, oh, okay, this is data. And I can do stuff with data. Before, my data was JSON. And then when I was in the client, I would run all this client-side JavaScript and run all this kind of stuff. And now I can just, oh, I can just send it down as data. That's really cool.

We are running out of time, but we have some more questions that I do want to talk about. And let's just step just a little bit further out and think about sort of the whole JavaScript ecosystem. We have React, but we also have a few other UI libraries. And I'm going to bring Ryan in here specifically. How do you think maybe React and React taking a step forward, shall we say, is going to just impact the whole ecosystem and UI libraries as a whole? Whenever React moves, people move. There's been so many examples of this over time. Stuff like out-of-order streaming, or async local storage. There were solutions doing this for years and couldn't get support on any platforms. No one wanted, no one cared. React does it, and then suddenly everyone's got async local storage within three months. Out-of-order streaming on AWS. I was waiting for it for three years. It showed up after React 18 within four months. So it has a profound impact when you kind of see these things. And when the new releases come out, I'm always excited, because in a lot of ways, I think the pieces of trajectory of the future are kind of obvious. They come in.

So it has a profound impact when you kind of see these things. And when the new releases come out, I'm always excited, because in a lot of ways, I think the pieces of trajectory of the future are kind of obvious. They come in. And sometimes smaller frameworks don't have to worry about having customers or people using them when they do that migration. So, you know, I'll just release something public that they will probably test internally for meta for the next two years. So I'm very excited about React 19, seeing stuff like suspense and transitions coming out and people actually using them. We released that back in 2019. And I mean, I'm sure already more people are using those in React than we have in the last five years. So, like, just understanding, being able to see the impact of these kind of decisions and, you know, is really cool to see. And it helps influence, you know, kind of like are we making the right decisions. I have no illusions where I sit in that kind of piece of the puzzle. So it's very helpful to see stuff making to React making a wider impact for everyone.

Cool. And before we wrap up, I'm going to set up some hot fire questions. We're going to do them quick. So I'm going to ask a question. We're going to go down this way. And then you just got to say it in like one sentence. So the first question is... Because we talked about lots of the things that are hype, lots of people are talking about React Compiler, about server components. All right. What's the underrated parts of React 19 that isn't necessarily getting a lot of fuss, but is really, really useful? So that will be sat here and we'll work our way down. For me, it's the use operator that was released in 19. Not a lot of people know about it. I think it's really cool. Nice. Optimistic state. So use optimistic and anything related to that.

Cool. I'm just realizing that it's the use operator, not the use hook. I was curious what we call an operator. Yeah, I mean, I've got to steal yours again. Forward ref is so good. We use that so much on native because there's so many imperative... I'm speaking too much. Yeah, at the very bottom, it mentioned that there's support for web components. That seems like no one's really talking about that, but that's cool. Yeah, I don't know. I guess all I got is... I've been actually excited about all of them, but the use operator and the potential there of selectors and more granular re-renders I think is a game changer. It might not be obvious up front, but I think over time, this is going to be a big thing.

That's awesome. Thank you so much. We don't have time, but there is so much more that I'd love to talk to you about and I'm sure a lot of the audience would love to talk to you about. So whenever people are going around, they can find you at the speaker's Q&A afterwards. Ryan's definitely going there. But let's give a massive round of applause to our wonderful panel. Thank you so much, folks.