Panel Discussion: The State of React

Yeah, I'm Evan Bacon, I'm the creator of Exporouter, I work on Expo, React Native, mobile development, React Native Web, bundling. I'm Tanner Linsley, I spoke an hour ago. I made TanStack. I'm Sascha Grief, I run developer surveys, including the state of React about the React community. I'm Shruti Kapoor, I also gave a talk a few minutes ago. I'm a full-time content creator, I talk about React and AI. Hi, I'm Naman, I made Stylex, I did some work on React. I spoke, I made a React alternative for my talk. My name's Jarrod, I work on Bun.

Okay, great. So I think it's safe to say that one topic that's been recurring about React today, even yesterday in our discussions, is RSCs. And Mark, you've already talked about them a lot. Tanner, they were also part of your talk a little bit. And I'm wondering if there's other panelists who have things to add about RSCs.

One thing I've been curious about is, first of all, who has actually used them in production? By a show of hands. So does a personal website count? Production? I guess. Let's see, like for your actual day job for a company in production? No. Okay. Production. So that's already an interesting data point, I think. I like to run surveys, so that was a small survey. A good impromptu survey right there. But okay. So even if you haven't used them in production, does anybody have something they want to add on that topic? So I have like a couple of small thoughts. So one is, there's a few other frameworks that have RSCs implemented already and people don't seem to talk about them. The people who have used Waku say it's really nice and really fun and more loose, because Next.js is a more framework-y framework and has an architecture and Waku is like do whatever you want. And nobody talks about that one. There's Redwood, like rwsdk just shipped with it. Nobody's talking about that. And maybe we just need more people to try out those things to expand what people think of RSCs.

More variety, would you say? More variety, yeah. So I think it was one of the questions we had before, but what's been preventing adoption of React components? Anybody want to take a shot? I'll start. So I actually led a panel at React. I'm going to blank out on the name. But in San Francisco, I led a panel there as well, and we talked about the same thing. What are RSCs and why adopt them? And I think since then, and up until now, I've seen the same common pattern, which is it is hard to first understand what RSCs are. But also once you understand them, to adopt them has been hard as well. And the sliver of slice where you can actually use RSCs and they have the right kind of advantage is small. So the adoption therefore has been very low. Like, for example, at Slack, we want to adopt RSCs. But we don't have Next.js. So how do we go down that route? I find it as one of the hardest things about adopting RSCs.

Yeah, well, we added server component support to Expo experimentally at the beginning of this year, and it's been pretty good so far. I mean, on native, there's, like, no data fetching. Like, there's so much variety for data fetching in the web, and we just have very little on native, so it's jarring to jump from nothing to this really comprehensive fine-grained granular system. And one of the benefits that we see from it is it's really, like, a universal primitive for SSR, SSG. Like, it's a system that you can apply to both native and web simultaneously. And when we look at, you know, people trying to code share, it's pretty straightforward to code share components, styles, maybe even interactions. But then, like, if you have to start forking at the router level or if you have to fork between platforms at the data fetching level, like, how authentication works, then it kind of all crumbles apart. It's just so foundational. And so with RSCs, we actually have an opportunity to build universal data fetching that works right at once and just runs pretty aggressively everywhere, which we find to be really nice on native. We can also do, like, little hacks where, you know, like, RSC payload, you need to stream that through, like, an HTML renderer on web. On native, you can just make the native runtime interpret RSC essentially as, like, native HTML. And so you get this more pure version of, like, sort of a React-first browser.

Do you think there's a cost in the fact that React wasn't born with RSCs and it's something that came in later compared to something like, I don't know, Astro has. It's not the same thing, but it was built from the start in that perspective of having the island architecture. Is there a future maybe some new framework that's going to integrate that concept right from the start? So, I mean, I think it's primarily an integration problem, which is, like, I saw very similar things even with Stylix where, like, once everything is set up, it's probably fun and nice to use, but setting it up is, like, such a hard thing that once you get stuck at the very, like, step one, you'll never use it. And I think just so far, like, Beats hasn't shipped integration and, like, Webpack was the only one, and even that integration wasn't, like, a super clean, easy, portable implementation. So I think it's just the tooling hasn't caught up yet. So in Bund, we actually this is not documented, and we haven't worked on it in, like, six months, but we actually have a React server components integration.

It's basically in a very incomplete state. You can sort of use it if you're adventurous enough. If you pass dash dash app to Bund build, it has a file system router, you can do the back end, like, templating with JSX the way you would expect it to work. This is something that we eventually want to do a much better job of, but honestly, right now, we have we're, like, very focused on node compatibility, so we can't really spend time on it, but it's something that I think from a runtime perspective, like, the overlap of the Bundler with the runtime makes it so that we can probably have a pretty good experience here. Really focused on making it simpler to do the server side rendering parts in a way that actually makes sense without having to do the hydration step. We're still, like, not there yet.

Yeah, so that's interesting, and at least speaking personally, I think one of the benefits of server components, at least the way it was initially presented, was simplifying some of your code. You can maybe make a database query right from your component, but when I actually implemented RSCs, I ran into a lot of edge cases, as you might expect, which meant that my code didn't really get simpler. More like the opposite. So I wonder if maybe React components weren't, like, sold the right way, and I still struggle to articulate the reason why you should even care about them and use them. I'm curious if anybody can actually make that case, like, assuming we get over all the issues with should you use a framework or not, assuming somebody wants to get on board and is open to that, how do you sell the idea of RSCs?

It's kind of a cheap answer, but the short answer is go read Dan Abramov's blog, because he's already written a dozen posts about this topic in more detail than any of us could do. He's been approaching it from the perspective of if you know REST APIs, here's how server components is different and better than REST APIs. If you're coming from a GraphQL background, if you're coming from a different mindset, here's how server components come there. He's repeating the same thing in different ways, but he's both making the comparisons so that you have a familiar background to start from, as well as showing, but if you do a REST API, you keep having to add in all these extra fields that the UI needs for its requests, or you could just use a server component and format the data and send it down. I think genuinely the best answer here is read Dan's blog. He's done those explanations, and now we don't have to. So you're saying we should invite Dan next year? Also that.

Clap if you want Dan! Hopefully someone can show him the video. One thing that I really like about server components is, just like when I came over to React, it's just incredible. Now there's so many composable frameworks, but at the time it was like... The composability was really unmatched in React on the client side, so it's really exciting to think of a world where you could have that same level of composability for your server level, your backend for frontend, where someone could build a product and express it entirely as a React component. Almost like how WordPress plugins were for a while. You could just... I could see a YC startup, there probably are some already, that are like, here's how you use our product, like npm install this component, drop it in, and that's like the whole SaaS. You drop in your environment variables, you're good to go. So that level of composability is very exciting, and just the opportunity there for people to bootstrap a really complex idea with the simplicity that you get with React. We're not there yet, by the way, but you know, one of these days.

I don't know if anybody has more to add about server components. I mean, one of the things that is not brought up, like when server components, when I first saw the concept of server components, this was still at Meta, it was not announced outside, it was like very specifically made for newsfeed on Facebook, because there are, I don't know, 26, 38, I forgot the count, but a huge number of possible post types that a newsfeed can have, and almost all of them are fairly static, with a few interactive bits, and it was an optimization to not ship all these different components that you may or may not need, and if you could just run it on the server. And so that optimization was the original goal, but it has evolved into something else by the time it actually shipped, where it's more of an architecture, it's more of a data fetching thing, and I think because of all of the evolution and what it has become, like, there's no pinned down one part of what server components is, so when we have discussions about it, people are talking about different things.

To some people it's just a serialization format which can be used just to return data from a loader, and to other people it's this whole architecture where you have like mutations and things like that, and I don't think we can have a productive conversation until we settle that debate of what is server components, what is next JS's architecture, and where's the line. Yeah, that makes sense. Before we move on from this topic, I kind of want to take a quick audience poll, so raise your hand if you had heard about server components before today. Okay. That's been the framework. Almost everybody. This guy over here hasn't heard of server components before today. What about people who have used them or tried them out, let's say? Yeah, that's okay. 30%. 30% maybe? Yeah. So who used them in production on a real product? Like 15 people, 10 people, yeah? So okay, I think that's representative of the ecosystem as a whole. They have a big mind share, but practical usage is still a bit slow. Okay. Okay, so let's move on from this, and one question that people suggested was concerning which features of React are maybe underused, or you want to highlight something that people maybe already are using, but there's some hidden aspect where you can bring us little tips maybe? I'll go with one, which is I think the best addition to React in a long time is the use function. It's not a hook, so I don't know if it's named well, but it's very flexible, you can use it in different places. Right now it's only for promises and context, but what I'm most looking forward to is when it can be used for more kinds of data, which is something the React team has talked about. Yeah, sorry, go ahead.

I'm going to say the compiler. I think it's highly underrated, and even though we're having our own little growing pains with it, with TanSac libraries, it's pretty impressive what it can do. Especially just for user code, and I'm really curious to see where it's going to go. I don't know why, I just have this feeling that it's just the beginning of a big long journey into much better performance and maybe even flexibility of how we use React in the future. I think it's a really hot area where we can use it today. I think it's in release candidate, and it's pretty dang good, and yet they're also iterating quickly on it and learning a whole bunch of new cool things while they're building it. For me, I'm almost, and being very client-side oriented as well, it's directly applicable to the things that I build, and it's like I see the React team, I guess they see me when they're building the compiler, and I like to be seen. That's why I'm excited about it.

I'm actually curious, we do the same polls for the compiler. How many of you have heard of the compiler before today? Okay, pretty good number. How many of you have at least tried it out in a toy application? Relatively few. How many of you are running the compiler in production? Like, bye. Okay, got it. The point of the compiler is both that it's supposed to improve re-rendering performance, as well as, like, okay, so I thought, one of the things people have always misunderstood about React is the way the rendering model works, and that's why I wrote a 12,000-word blog post on the topic. Components do not re-render if the props change. Components re-render any time the parent did, which means if you set, say, here, it just automatically ripples through all the children.

The compiler does actually turn that on its head, and so if you've got the compiler active in a codebase, for the first time, it truly is your component only re-renders if the props data did actually change. This does start to lead to some questions. If we get to a world where we assume the compiler is on by default in most codebases, how do we actually teach things like the rendering process? Because there's the default behaviour, but then there's the way the compiler modifies that behaviour. Great question. We're probably going to need labours where it's strict, and if the compiler—right now, it fails gracefully, but probably it should assert that the language—because I feel this too, like sometimes instead of a use effect or something, I'll just have some top-level animation start, which is totally bad practice, but it works in the compiler, but then you might run some unrelated code in the compiler which then breaks optimisation, and then it changes the—it cascades and has all these side effects, so in cases like that, I would rather just enforce it's either on, or I get an error, but it's a migration strategy. I have a lot of faith that the React team would add more strict options.

Yeah. I think, yeah, right now we just roll it out very loose so that we can try to get more people to enable it, but at some point that will have to flip and it will have to be strict by default. Because the last strict mode was great. Yeah, yeah, every strict mode has always worked out. Perfectly. Yeah. I mean, the thing that a lot of people miss is compiler can already be either default on or default off, and you can turn it on or off for a component, for a hook, and so I actually don't think there's any reason for anyone to not start using it. I think 100% of developers should be using compiler today, and you can just not turn it on globally and just turn it on for a component, and if it doesn't break, just keep turning it on more components and you just get magically faster thing with no work.

Where could people go to learn more about how to do that? So the React compiler documentation doesn't mention the options, so you have to dig around to see how to turn it on on the npm package, but it's there. If you look for it, you'll find it. Sorry, I had to. So moving on from features that we wanted to highlight to now features that are missing from React, or maybe upcoming features that we might want to look for. New features coming to React? Either new features that are actually coming or wish list feature that you wish would come. Oh, wish list of features. Oh, man. Yeah, just integrated AI builder, like, by default. Like, you can add a token or something.

I don't know. One thing that I like about React is that over time, it used to be really heavy-handed, and there was, like, before JSX, it was like React.create, and then JSX came out very quickly, and then you had, like, React.create class, and then that kind of went away in terms of classes and functions, and it just kind of started to, like, disappear more and more, and then it feels more like React is like the language around the JavaScript. It feels more pure to the JavaScript in a way, even though it's kind of, and compiler does this, too. If you look at, like, where you still see React in a component, you've got, like, use memo, use callback, use effect, use state, and so, like, if you use server components, then you can get rid of a lot of use effect and use states.

If you use compiler, you can get rid of a lot of use memo and use callback to disappear. And so, like, when you were using server components and compiler and then you look at the results, like, where do you still see the React where you have to kind of step outside of the JavaScript and do something that feels less natural? Because like async in a way feels way more natural than use effect and use state. You know what I would like to see? Built-in error boundary. Please. It's about time. Then we can get rid of class components forever. Yeah. I mean, I'll just repeat the use function again. I'm, like, waiting for use function to support, like, signals and async iterables or, like, a fixed use sync external store. Like, I think that one hook being broken is probably the biggest flaw in React today because every ecosystem library for data uses it. And none of them are, like, safe for concurrent learning.

There's two things I want React to support. One is data fetching without an external library. I don't want to go to anybody else. I just want to fetch my data in React without anybody yelling at me that don't use use effect. And second, I want to manage my state in React without with something besides use state. Something that does not make me jump towards Redux or Zojtan. So I want React to be able to take care of data fetching and state management so I don't have to go for the libraries. I know you guys are gonna hate me because it's, like, your work. But I want React to be able to fully support itself until and unless there's a really good use case for it not to. I think that goes back to, you know, the framework versus library debate where should you have an all-in-one approach or stick to your lane and do something very targeted?

I know that the React team has said that they are at least exploring the idea of some kind of built-in store object that would not be tied to a specific component. I think that's still just, like, very early explorations. Something that's related but a little different that's maybe further along. So right now, external libraries like Redux, etc., rely on a hook called use-sync-external-store which subscribes something like the Redux store. And when the store is updated, it triggers a React rerender and that's the built-in, official-approved way for external libraries to connect to React. But it does have a limitation which is if you're doing concurrent rendering with either a use transition or suspense or something else, if there is a store update while React is sort of paused in the middle, then it actually kind of has to throw away the work in progress and start over and do an old-style start-to-finish render that might take up some time. So that's just an inherent limitation because the point of concurrent rendering is that React owns the state and it can say, start to apply this, whoops, no, set it aside, do something else, come back, reapply, finish. And if the state is external, React doesn't own it. It can't reorder things.

It can't reorder things. The React team did put up a PR recently for something that they're calling, like, a concurrent compatible store. All we have right now is, like, one paragraph in the most recent labs blog post and then a draft PR with the tests. So we don't even know what it looks like in practice yet. But if I'm reading this correctly, it sounds like it's supposed to be a replacement for use sync external store that would allow us to be concurrent compatible in some way. I hope. Maybe. Please. I would use that ASAP.

Yeah. So, yeah. I saw these PRs and I got, like, my impression was it was more like a first party Zustand and not a replacement for use sync external store yet. But I could be wrong. Who knows? We'll find out. I would be happy with first party Zustand built inside React. Yeah. So I think I ask Joe Savona for this once a month. I say, give me use external store, and he says, why? And I just kind of lower my head and walk away. But it really would be pretty amazing to get that hook or, you know, that utility out of React.

At least right now in a lot of the libraries that we have at Tanstack, we have to make decisions whether we want to either support very fine-grained re-rendering and selectors, which is usually where we default because we want the best performance that we can get. But we can't have full transition and concurrency support with that. So that is a fork in the road for us. And something like use external store, where we would be able to allow React to version our external state as it needs to, would fundamentally be able to let us have both of those. And that would be a big game-changer.

So going back to your talk, one of the themes was this issue of how to communicate new features, how to interact with the community. And I think it's challenging for any project. Especially one of React's size and React's influence. So I'm wondering if you all have any ideas of how that could be improved? Is there anything the React team could do differently? Is there anything maybe the community should approach differently?

How many hours do we have? I have a laundry list of ideas but to keep a couple of them. One that I wish for that's probably not going to happen would be, like, a constantly updated public road map. Right now most of us just sort of have to either watch the React repository for an early PR, and then people get excited because this new feature is coming and then maybe it never shifts or it iterates through long. Ideally what I would like to see would be something kind of like the TC39 stages for JavaScript features, where they could say, this is stage one, we're not even committed to it, it's probably going to change, it's not final, but FYI, we're working on it. Just so we have some idea as a community where they think they're going.

In terms of communication, when React 18 came out, there was a public working group where they pulled in a lot of folks from the community. There was a public discussion forum where we could ask questions, we could forward questions that we saw externally, and then the React team would actually read those and answer them and there were some good explanations and discussions. I still think that was one of the best interactions that the React team has ever had with the community. I would love sort of like a permanent working group going forward, like when React App broke, after the release of React 19, I kind of whined about it a lot on Blue Sky because I didn't really have any other way to, I felt like I could communicate, and eventually that got fixed. But it would have been easier if there had been like a designated discussion forum where I could have said, hey, this is broken, FYI, and I would have known they were going to look at it and respond.

Yeah, I plus one the working group. I think as an educator, it was such a great way to ask all the questions but also start building resources for the community before the release even came out. So there was a lot more to read and learn from outside of just what the React 18 docs said. One of the best threads that I still remember from them, from that GitHub discussion was explain like I'm five and they were like all of these bunch of different concepts. It's still live, still there. I think it was an amazing initiative to create a working group, and what I would love to see is for that working group to keep continuing for every oncoming release, but also to have a place where the community can go and ask questions from the core maintainers itself, especially for new upcoming releases like compiler. I have hundreds of questions. Where do I ask this?

Okay, yeah, I think that's a great idea, like a working group and also that stages system. It's definitely useful, you know, as someone who also keeps up with JavaScript and CSS and many other languages and technologies, knowing whether a feature is, like you said, an early idea that might go away or actually something that's going to ship to browsers imminently, that's super valuable, because otherwise it can be really hard to distinguish between those. So I think we still have a little bit of time left. Is there any other topic you guys want to bring up? Common pitfalls? Common pitfalls, yeah. Also we did discuss this previously. Are there common pitfalls in React, common mistakes that people make, maybe beginners, especially things that should be avoided? I think I'll start with one.

So having reviewed a lot of PRs at Slack and Paypal, a lot of the times we miss to manage our dependencies correctly, and that can lead to a lot of re-renders. So use memo, use callback, use effects, the three common hooks that accept dependencies that a lot of people use in code. There are linter tools that can actually highlight that you're missing a dependency. So number one step, install a linter tool that can help you highlight that. Number two, even though linter will highlight that the dependency is added, it's still your job to figure out that the dependency is granular itself, so you're not adding a huge object if you're not using the object. And the problem with that is whenever dependency changes, it will re-render and your component re-renders, there's performance implications.

So the biggest pitfall that I would highlight is manage dependencies granularly. And just to clarify, you mean that dependency arrays for use effect and so on, not like the imports? Yes, yes, dependency array, thank you. On that I would actually say use the compiler, stop using use memo and use callback, and for use effect, don't try to write the dependencies yourself. Only make the yes lint rule write it. That's the only correct way. Every other way is wrong. The compiler will warn you also and will stop working if you don't write the exact dependencies that the yes lint rule writes. I think the only place where you have to make a decision is if you're reading a key off of an object, so like object.a, the yes lint rule might suggest object itself and you can put object.a, which is a little more granular, and that's usually better. That's it. Other than that, don't try to manage the dependencies yourself.

I agree that's the most common pitfall I see. Things break in very strange, subtle ways when the dependencies are off and there's no easy way to fix it because you start depending on that behavior over time and then you can never fix it. I mean, I saw earlier the stats about people, like there's some large percentage of people not using frameworks, so just make sure you're using the rules of React yes lint plugin and you've got the rules of hooks enabled, because that's basically the public interface for React to communicate with you, like the obvious issues in your project. And then don't, if you're on React 19, pull out all forward refs, it's therapeutic.

Another kind of subtle pitfall that I see is extra large components. It's fine to break up components. It's usually better for performance. Don't make mega components. With the new use API, I've been making my components extra large just so that I have places to use conditional calls. That's the thing, that's why I think it's a pitfall. It's very easy to make large components and then the larger they get, the worse the performance gets, and the more likely it is that you'll have some violation of the rules of React and the compiler will stop working. But if you have lots of small components, even if one or two don't work, if the rest of them are memorized, you get the performance benefits. It's great. Yeah. Yeah, people should definitely check out the use API and just all the new React context, because it does work, even though it just feels slightly different, the effects are profoundly different.

I can only imagine someone learning about React from 19 on and maybe not reaching for a different state management library. Because oh yeah, just create a context, super simple. Even deleting the dot provider makes it just feel a little bit closer to a modern state management library, and then being able to call it conditionally, doing context selectors almost feels fantastic. So, whole new world, even with just slight API changes. Yeah.

Anything? Okay, well, you know, I think we covered a lot of ground already, so this might be a good place to stop. Someone should definitely write a blog post to recap everything we said. I'm looking in your direction. You can add it to the list, I know you've... You've been nominated. I don't have enough time to write all the stuff I want to write anyway.

And one thing we should remember is the people here not only are great panellists, but you guys actually make the tools that we all use. So I think you all deserve a big round of applause. And thank you for today, and also don't forget the state of react survey which will come out sometime in, like, probably September. So stay tuned for that. Thanks, everyone. Thanks, Satchel. Thanks, everybody.