Panel Discussion: Future of React

Hi, everyone. We're going to be doing a future of React panel discussions. There are going to be some sweet questions and some spicy questions.

So let's start off with this sweet question, which is please introduce yourself. I'll start off. Hi, everyone. My name is Shruti Kapoor. I'm a software engineer at Slack. I use React all the time. And I'm super excited for this panel discussion because we're going to be talking about React 19, what's coming up, what we hate, and things about React that we wish we could change.

I will pass it on the mic to you. I'm Eli White. I'm one of the software engineers on the React team at Meta. Hi. I'm Mofey. I'm a software engineer on the React team at Meta. I'm Kent C. Dodds. And I teach people how to make quality web applications. Hi. I'm Theo. And I teach people how to make terrible web applications. I'm Mark. My day job is a time travel debugger at Replay. And my second unpaid job is maintaining Redux. I'm Tom. I helped create React. And now I'm the chief product officer at Vercel. Cool. What a cool panel.

I love you all.

All right. So let's start off with a spicy question. React 19 is in RC stage. We're so excited to hear when is it going to be in stable stage? You're looking at me. I'm looking at you. React 19 has been really cool, because we've really taken a lot of the feedback that we've gotten from people, especially around the suspense changes, if you've seen that. I really want to do a shout out to Andrew from Vercel, who's worked very tirelessly to make sure that bug gets fixed and we address the needs of the community, make sure React 19 is good for people. That has been incredibly complicated of a change to make. And as we've rolled it out, I think, this week, people have started sharing feedback. They're like, oh, this is actually what it should have been all along. This is incredible. There's a couple more bugs that we're working through. And then we hope to get it to be stable.

I'll have a quick point on this. I regularly am surprised at how many people feel like React is breaking all the time, because the delays with React 19 are a beautiful example of the opposite. They had an RC. It was gold. It was ready to go. A very, very, very small subset of apps that used client-side suspense in a very, very, very specific way had performance regressions. And rather than ship it and tell them to deal with it, they have now taken a long time to make sure nobody's code breaks or even performs worse than it used to as a result of the changes. And I personally think we should take a second to applaud the team for continuing to keep our apps working 10-plus years into these code bases. I love that. I love that shoutout.

Actually, you mentioned there are some challenges that you're dealing with. I would actually love to know what has been sort of the most common bug that people have raised about React 19. That's a good question. Mofey, do you have any ideas here? We've been hearing a lot of compiler questions. I don't know. I think the compilers opt-in only.

We're in beta right now. We're hoping to get a stable release out. So hopefully we'd love more feedback on the compiler if that's breaking anything for you.

That's actually a nice segue to my next question, which is gonna be tell us a little bit about React compiler and what would you like people to know?

Somebody who's been maintaining React compiler for the last two years. Yeah. We're super excited to release it. We released earlier this year and recently released to beta. We would love you to try out React compiler on your app or your library and report to us if it works flawlessly, if you encounter issues. We have a debugging guide online. We have an adoption guide. Please try it out. We've been using React compiler at meta for meta's biggest web apps, Facebook.com, Instagram.com, Threads.net. It's out for... We've enabled the compiler on almost every single React component and hook on Facebook.com, which is really, really cool. We didn't need to do a lot of custom debugging. We turned it on and it mostly just worked. We had a couple of intent test breakages that we debugged and we were able to fix within a couple of hours. We think that React compiler is really ready for the world. We also believe that React compiler is here to stay as not just an auto memoization feature, but a core part of React. Part of this is we think that the future of developer experience and developer tooling will be using the compiler. We'll start by merging the existing ESLint for React with the compiler-powered one that will give you more powerful violations. We also expect to be working on a React IDE that's powered by the compiler. You get more than just Lint. You get educational tool tips for things that power users might want. It's really exciting. I know Kent Sendy doesn't like magic, but we've been doing a lot of data science at Meta around the compiler and the rollout. We've seen pretty incredible performance wins and top-line engagement wins for a lot of our products across Facebook and Instagram, but also developer efficiency wins. It's been really incredible for our engineers.

We've seen pretty incredible performance wins and top-line engagement wins for a lot of our products across Facebook and Instagram, but also developer efficiency wins. It's been really incredible for our engineers.

I think that's very exciting. You're right. I do not like magic, so I'm cautiously optimistic about the compiler. I hope that it can continue to be a core part of React, but if React can continue to work without a compiler, then I will be satisfied. I'll probably use the compiler, but as long as I can still write the vanilla, then I feel like that changes the design or constrains your design decisions in a positive way. That's why I care.

I also wanted to say, did we just get a new editor announcement here at the conference? That's awesome. Very early. Very experimental. Man, those editors are coming out like crazy. Is it a VS Code fork? No comment. I think we're thinking more like an extension, right? Yeah. Like a VS Code extension. Tom, you wanted to add something? In Kent's talk this morning, he was using create element directly without JSX. With RSCs. No compiler needed with RSCs, the latest features of React. So I think the team is committed to making sure that it will continue to work the way that it does. Thank you, yeah. Did you try a class component though?

I should have. One question I'm seeing asked a lot is, when can we possibly expect a compiler interface layer that is not powered by Babel? Something Rust related, SWC, something that does not require adding the Babel loader to Webpack. Yeah, we're working on that plan for the next couple of months. We're planning to start working on that. I wanted to call out something that you mentioned. When you added the compiler to Facebook.com, a couple of end to end tests passed. I just want to say, you should probably have some end to end tests in place when you put on the compiler. Because, yeah, testing matters. Sorry, Theo.

Sorry, Theo. Any library we can use, Kent? I test my code. I have a hand. I can click. All right, moving on.

You mentioned about the IDE, which I actually saw yesterday. I was pretty excited about it. But I want to ask this question to the rest of the group, which is, are there any features about of React 19 that you are pretty excited to see?

Yes. Which ones? Oh, I guess I will go. Because I don't use Next.js, I haven't been using RSCs for the last year and a half or however long. So, I'm very excited about RSCs being officially stable and a stable release of React. And, of course, server functions and all of that entails. I think there's a lot of really, really interesting patterns that we can get. What I really love about what React is doing is it's going to consolidate the framework. So, I use Remix. Theo uses Next. I think that in the future, our product code is going to look very similar. Almost you could just use them in either framework. And I really love that. React is bringing us back together. Thank you. I'll pass it on to Theo.

Same question. I mean, this is my whole life. You can go to my YouTube channel, and I've done a deep dive on every cool thing about all of them. But, I think the one that I've had the longest journey with has been streaming. Going from seeing the benefit before understanding how it worked at all, to deeply understanding it, to reverse engineering it, and implementing it myself, to then seeing the final form of it now. It's been really cool to watch how we've went through this journey of how do we stream HTML over the wire in a way that allows the user to have a good experience. It's cool to see that puzzle finally cracked in a way that isn't just benefiting React, but not only will it benefit other frameworks on the web. It'll benefit other non-web frameworks and ecosystems, too.

I've been helping some teams in the Elixir world get this working in Phoenix and Liveview as well. That's why you always bet on React, because we get it first. Somehow still. How old is React and we're still the first to so many things? It's amazing.

One of my favorite Theo quotes is, nobody shits on React better than the React team. Just even thinking about this is pretty cool, because React has been around for so long, and it's changed so much, but your product code can still be so similar to what it is. That really speaks to the ability to add things to it and add these capabilities, add streaming. It's still just React. It's what you're used to using. That's because we see all the flaws, some that you don't see, and constantly are working to improve that.

I even went out of my way when AppRouter and React 18, I believe, dropped to take the oldest example of a component I could find on the React blog. I had to bring in the new class helper, like Polyfill that you guys made, but I could get code from 2013 or 14 running in a brand new 2024 Next.js app with a single package you guys built for this purpose. You can run really old code and really new code and not just have them both in the same project, but mounting each other and interoperating between code that's ten years old and code that you wrote in the way that we're going to next year, and have it all just work together. There is no technology I know of that has maintained that level of interoperability with different generational ways of writing it as React has. Browsers are incredible. But none of the things interrupt, they all just break. You're composing code from 2013 to 2024. That's insane. It's so good.

Mark, what do you think? My head is in a weird space around a lot of this stuff. I deeply follow what's going on inside of React at the team level and the PR level and even the code level. I've been thinking about things like concurrent rendering and how that interacts with external libraries like Redux for years. On the day job, I don't spend a lot of time building UIs myself. My own React usage tends to be the bread and butter, fetch some data, render a list, whatever. So while I understand a lot of the mechanics, I have still not entirely wrapped my head around some of the newer things from 18, like transitions or use deferred value. I think Brian Vaughan tried to explain that to me a half dozen times and I still only half get it. It's the hardest hook for sure. On the one hand, sometimes it feels like client-side React was already complete. And so we're getting some things like I guess there's new stuff, but what is this? But at the same time, even some of the new stuff in 19 around forms. How many times have we written a use state hook to track the loading state of a request? Too many.

Yeah. So having things actually built into React for that are clearly something that is going to help the community. Yeah, I think you're right. Forms especially has been so ignored for a long time. It's finally very nice to see that they get the respect that they deserve and the work that we put in forms is now actually going to be automatically done by React so we don't have to track all these manual things.

I agree. Tom, anything you want to add? Yeah, just over the years there's been this pattern of the React team saying, okay, we don't have an opinion about this specific thing. Letting the community explore for a very long time, zero in on a set of patterns and solutions, and then bringing those into the framework and codifying them so that everything built on top can be a little bit simpler. That's what I'm excited about with React 19. I think it continues to do that and it did it with this time with the form stuff. But I think the commitment to the economic value associated with React is not the framework itself. It's all the stuff we've built over the past decade. So bringing those patterns into the framework and keeping it fresh and keeping things moving forward, that's what I'm most excited about.

You heard it here first. Taylen's going to be part of React 20. I was thinking animations would be really good. Are we centralized on an animation solution? I just really appreciate that aspect of React is that we're not going to make an opinion on something until we are solid that this opinion will go for a decade or more. That honestly was one of the things that really attracted me to React, was the commitment to letting the community just work through a bunch of different solutions. When Flux was presented at Facebook, we just went through so many different iterations. The Flux wars. Yeah, the Flux wars. There have just been a lot of examples of this where React is like, yeah, we're just not sure what the right direction is. We're going to let the community innovate. Honestly, I think that's one of the reasons why React leads in so much, is because you don't just have the team at Meta and Vercel working on it. You have the entire community trying to solve these problems, and then we iterate to something that is really, really good. Thank you to all of you for iterating on that. Yeah. Yeah. Clap for yourself. Something I'll say as an outsider is I was surprised at how open the React team is to having these conversations.

That's not just because I'm a YouTuber, they have to listen to me, although that is true. We're looking for this feedback. Random events that Eli shows up to, he'll just talk to anybody about this. If you've had a problem with React, you're getting frustrated with the framework, I'm amazed at how quickly a conversation with pretty much anyone on the team can show you how much they do get it and care. I can't count the number of times I've had a conversation where I raised a concern about a design decision or an API I didn't think was going to work, and Sebastian would just rewire my brain in two sentences. These guys get it. They've been thinking about these things for so long. The React team doesn't show us what the plan is until they've... As Eli said, I said before, they have been their harshest critic about it for years beforehand. Yeah. Speaking of feedback, let's hear it. What are some features of React that you feel are kind of confusing or unused or you would like to see them removed from the future versions of React? Ignoring the last part, every hook that was introduced in 18 and 19... One of the things we used to do as a core team was every time the team wanted to introduce a new feature, I would ask, somewhat jokingly, what are the three features you're removing in order to add this one new API? I didn't know you worked on Preact. Yeah. I had in my past life. One of the good examples of this was get derived state from props. I remember the meeting, I was joking with the team, I was like, all right, what three APIs are we removing in order to introduce this one? It turned out that in the Facebook massive code base, we removed most use of three APIs. It was like should component update and component will receive props. I hope that there's always a sort of refinement that's happening while we're introducing new things that reduces what I describe as the barrier to entry. How many APIs do you really need to learn in order to get up and running? I don't have any specifics I'd call out that I wish they would remove, but there's a lot of legacy stuff we probably don't need. I think both they and the compiler team have helped, you know, pay some of those bills for us. Absolutely. I'd love to never call use memo again, use callback. Let's let the machine do what the machine does better than me. Anybody else who wants to add? React is perfect. No. I was just thinking about when create class got pulled away, you managed to still let us use that by having another package. As things get kind of shifted around and we kind of evolve as a community over time, this is one of the beautiful things about React is that it continues to evolve. It's not stagnant. It's always innovating.

Yeah, old things are going to go away. I would love to still be able to use 2013, 2017 React code in whatever the future is, and I have confidence that the React team isn't going to abandon us or the rest of the community as we continue to innovate and move in different directions. So, while it can be frustrating, like, oh, man, they came out with classes. Now they came out with hooks. I'm just constantly rewriting React code. But no, you don't have to rewrite it. You probably want to. There's a motivation to get there. I just appreciate that the React team cares so much about that migration. It's not quite things I would remove, but some examples of things I've seen people ask for that sort of relate to this. Some people have said we don't have any class components in our code base. Could I somehow have a version of React that omits class component support entirely? I've seen people say, like, why can't I tree shake React and somehow leave out the bits of the core functionality that we're not using? A lot of people have asked for proper ESM publishing. Yes, please. Please! And these things all actually relate, because, like, the core logic of React is very intertwined. You can't really separate out the logic for updating a class component. It's in its own source file, but the published version, it's all together. So there is no single answer, and I'm not sitting here begging for this to be removed. But these are the kinds of things people think they're asking for, even if they don't understand what it would take to accomplish it or realize it's not necessarily saving them. But I will ask for the ESM support. ESM we definitely want.

So I also have a feature I kind of want to remove. I'm hoping to kill use memo and use callback. Hopefully already now. But there's another feature that, like, I don't know, just looking at the code, it feels a little redundant. And that's the deps array for use effect. So now that you have a compiler that can understand, like, oh, what are you using inside of your effect? It's the same logic for understanding what you're using inside of your normal React render code, right? Or like your use callback code. Maybe we can just use that compiler and not have to worry about effect dependencies.

So there will finally be a use case for a use effect call that doesn't have a second argument? Yes. Because right now it is just a foot gun. I was telling Theo the story the other day of where that array came from in the very beginning, and it was like hand wave many years ago. It was like, well, don't worry. A compiler will just do this someday. Yeah, I remember that. And five years later... And here we're in a room full of compilers. We've finally done it. And Kent will be able to still write the deps array. I can still do it.

Okay, yeah. That's good. I do think this brings up an interesting question around the education side of things. And this actually very much relates to what I've gone through with Redux. Redux was taught very early on as you're writing all this code by hand, object spreads and action type constants and everything. We created Redux toolkit as an abstraction layer. You're writing less code. It's using emmer for easier immutable updates. It's generating the action creators for you. But you still ultimately have to understand the principles of immutable updates so that you realize, like, I can mutate inside the create slice call, but not outside. There's magic happening there.

There's magic happening there. And so we start to get into the same thing in terms of the compiler or something. If someone comes into a codebase three, four years from now that has been React compilered for a long time, and they see a use effect with no deps array, they might not realize that the compiler is actually doing a lot of work for you. So from the education side, there's still a need to kind of teach some of the underlying concepts and understand that in this codebase, there is some magic happening that is saving me time and effort.

I don't have an immediate answer for that. I don't know necessarily the best way to, say, like, organize the React docs. For the Redux docs, what I ended up doing was the primary tutorial teaches Redux toolkit and says there are some bits of magic you need to know as we go through, and then there's a separate fundamentals tutorial that teaches the underlying concepts with no abstractions. Maybe some of that needs to be integrated in the React docs. Not sure. But it is a concern.

Sounds like you're well employed for a while, Kent. I was just going to say. I would love the React docs to have that. That is my modus operandi for how I teach React, is let's strip away all the tools. What is the core of it? And then, all right. Now you're a professional. Let's add some of the magic to make this work efficiently. It's not quite the same education that you're talking about, but I think we also think about how do we teach these new AIs and LLMs the new patterns? As we make changes, as we want to remove useMemo and useCallback, how do we get the LLMs to stop prompting those things? I have no idea. But that's going to be something we need to figure out.

It's not quite the same education that you're talking about, but I think we also think about how do we teach these new AIs and LLMs the new patterns? As we make changes, as we want to remove useMemo and useCallback, how do we get the LLMs to stop prompting those things? I have no idea. But that's going to be something we need to figure out. I think we have to drink a shot because we just said AI. We made it so long without. I'm proud of us. Exactly. Actually, speaking of... Oh, okay. We're drinking a shot. Yeah, we are. This is non-alcoholic, I promise.

I do have a somewhat hot take. I actually don't want most people that get started with React today to ever have to learn useMemo or useCallback. I believe there's a short transitionary period where from now to next, you need to learn from here to there. But after that, I hope that we've established a new baseline that doesn't require it. I would actually invert the docs. I would say don't teach it by default and then disclose it progressively if somebody happens upon it. But heard about the, if I enter a code base that's relying on behavior associated with the tooling, it could be confusing. But yeah, I think the whole goal is to make it so that we introduce concepts to get us from point A to point B, but eventually point B is the new starting point.

This is one of the things I've seen a lot with React that's really interesting is like a community management problem where React is allowing us to build things that are so complex that you can have a full life of a career all in building React and learning all these complexities and details. And an update comes out that doesn't get rid of those things, but allows you to not need them anywhere near as much and to work with more pieces, but the puzzle that you build with it is much simpler. That said, when you're so used to living in that specific complexity and something else gets added, it just feels like more complexity and it can be really stressful as a person who's dedicated their lives to creating materials, documentation, frameworks, libraries, and all of these things around the way React works today, that when we look at React of tomorrow and it's different, it's hard to map the mental model.

Something I've found interesting with server components is they've been easier for me to teach to non-React devs than long career React devs, because when they see JSX, they assume that's a client component that is re-rendering all of the time and all of these things, but if you're treating it just like HTML and you're not that deep in the React brain, it's easier to learn these new ways of using it. And one of the concerns I have with the compiler is that the people who are so deep that they know exactly where and how to use their callbacks and memos are going to be thinking too much about what the compiler is doing and not just trusting it to do the right thing. React IDE. Yeah. I just want to say both of those takes super good. I hope you were listening. We had the same thing with Hooks. I remember before Hooks, I spent the first half of my workshop teaching people how classes work in JavaScript.

And then I would teach... Teach me. Yeah. Thanks. I don't know if I can do that anymore. But yeah, then we got Hooks, and everybody who had been doing class components had to unlearn all of that stuff, whereas brand new people just picked it up a lot faster. And yeah, it makes tons of sense. I got in as Hooks were happening, and I think it's a huge part of why I got into React as quick as I did, because I didn't have the baggage of the old way of doing things. I could just learn the new one. My first one of those moments was server components, and I did not like them initially.

I did actually have a follow-up question for you, which is you've been teaching React for a long time, and I'm curious, what are some things that you've seen people strip over the years that you would like to change? Yeah, it's been almost a decade now. And it's evolved, of course. I used to have to teach people classes, and now I don't have to. So the question is, what I hope I don't have to teach them in the future? What are some things that people get tripped on in React? Tripped on. And of course infinitely running effects, calling setState inside of the callback. That doesn't happen a ton in my instruction anymore, but there are definitely some places, because React has gotten so good, and Epic React 2.0 is all React 19, so we're not using useEffect a lot, which is, whoo, awesome. But yeah, memoization is something that's confusing, useDeferredValue is a really... It's a hook that's not for a specific use case. It can do so many things, and so it's hard to really... I've got examples, and here are all the really good places where you use this, but it's still kind of a hard one to communicate, and that, I think, trips me on. I confused Ryan Florence on a card drive with useDeferredValue, so I don't know. I did my best. But yeah, I think a lot of the challenges that people are having are morphing their brain into the new way that things are. People who are learning it now, like we said earlier, are getting it better. Sorry!

So, I have a question for Kent, too. So, Kent, you say you don't like the idea of magic, but what do you think about having an IDE that could show you, like, hey, this is another way that you could write this feature. This useMemo, it's not really necessary, because it's already being memoized in the same way that you want it to be, or maybe even better. To me, that's good kind of magic. Yeah, I like that a lot, because it's instructional, and I think that we all depend on a lot of magic. I don't know how my computer actually works.

You know, I have, like, some ideas about transistors and whatnot, but, like, we're building on top of abstractions, and so at some level, there's some magic we're depending on. That's fine. And I think that the compiler can just be that next level, and then we're all just operating at this utopia level. And when you really want to understand things better, you go down to level up, and that's one of the epic programming principles that I'm going to be talking about.

But, yeah, so I'm cautiously optimistic about the compiler. I think there will be a transition period where we're just trying to figure out, okay, where is that magic level now? But I think that I'm really excited about the IDE. I think that'll be a sweet extension. Mark, you wanted to say something? Yeah, something that ties into both the thing that confuses people and, like, the education moving forward side of things.

The number one mistake I see people have with, like, the React mental model is not realizing that when React renders a component, it will recursively re-render every child component inside that by default. It's how React has always worked. And a lot of people have assumed over the years that, oh, my child component only re-renders when its props have actually changed. My most useful, like, blog post is a 12,000 word article on React rendering behavior. And a lot of it was just I keep seeing people ask these same questions or make these mistakes over and over. And so the thing about the React compiler is it does actually flip that default behavior on its head.

And for the first time, React will truly only re-render your child component when its behavior changed or when its props actually changed. And so like Theo was saying, those of us who have been using React for a long time do actually kind of need to flip our understanding of the system. Yeah, I agree. Just a very brief addition. Magic is only magic when it works 99.9% of the time. When it works 100% of the time, that's just the way things work. We don't think about the fact that the light that's shining us right now is magic. Absolute magic. And the first time anybody saw it, it was magic. But yeah, I think once we get to the place where the only thing you have to learn is the way that things are intended to work, then you can eventually progressive disclose. You can go down to go up, et cetera. But I think it will feel like magic for a little while, and then we will take it for granted in the best way possible. I just had this in my talk. I should have prefaced my talk about streaming with, by the way, I'm going to go into all the nitty gritty details on how this works. You don't need to know any of this. You shouldn't have to know any of this.

And I forgot to say that. I ended up getting a bunch of questions on how to debug these specific behaviors. You don't have to. It does actually just work, as crazy as that sounds. And accepting that and trying it and not worrying until you hit that bug that makes no sense can make a lot of these things much more approachable.

I have a spicy question, which I'll start off with Mark, just for a safe bet. He's the safest one to answer a spicy question. Yes, at least this one. Not Tom. Okay. Here it is. React has become dependent on frameworks like Next.js for some of its recent features. What do you think about that? What is your opinion on that? How do you feel about React featuring or favoring some of these frameworks?

It's less about me having opinions on it as me being just inside sort of the not quite inner circle enough to see what's been going on. So I'm going to sort of put my I'm not a Facebook employee, but I'm cosplaying one hat on. The React team was always able to alpha and beta test features using Facebook meta's own internal infrastructure. So since Facebook has their own server infrastructure, server components were the first feature where they really couldn't do that. So between maybe like trying to spread some of the React knowledge and ownership outside of the one company, as well as Vercell wanting to, you know, like the React team convinced Vercell to buy into their vision, but also Vercell was willing to put their money where their mouth was and pay the employees and rebuild Next, et cetera. So I understand some of the community concerns and complaints about, you know, Vercell's trying to sell servers or whatever, but I also understand that it made sense from a development perspective, from a, you know, like company progress kind of perspective, and ultimately they needed to be able to build these things and try them out.

Can I give the spicier version? Of course. Next was the first framework to go all in on RSCs, because Next was the framework with the by far worst ergonomics around routing, layouts, and data fetching by like 10 miles. It was so bad. And it needed server components to work for it, to be able to exist in the next generation, much less compete in it. The other frameworks tried. Hydrogen tried real early, too early, and suffered a lot because of it. Remix tried, was unsure, and had like back and forth about it. Now they're going in. Next was the one that needed it the most and was also the most willing. And I think that's why they got picked. More so than they spent the money or whatnot. And I would say that they picked themselves.

So it wasn't like the React team said, okay, we're gonna pick Next. It was more, hey, frameworks, we need some help trying this stuff out. And Next was the one that had the resources to do that, and also, I suppose, the motivation as well. I was on the Remix team at the time, and Ryan and Michael and I, mostly Ryan, put together a demo of what Remix can do now and what RSCs with Remix can do now, and it wasn't there yet. And with such a small team, we didn't have the resources to dedicate to getting it there, and Remix was pretty good at the time. It still is. So yeah, I think that's kind of what factored in. But I'm super stoked to get RSCs in React, Revit, V7, and Remix. Yeah, I think one of the things we realized working on React at Meta, we reached the end of what we could do with a client-only architecture. We really needed to bring the server into the picture. And Facebook benefits from having control of both the client and the server. You can send different payloads down, you can invent a new serialization scheme that can magically serialize promises over the wire, which is just insane. But you have to have control or influence over the server infrastructure and the client to be able to do it. And the bundling as well. That's right. So I think Vercel, the idea that you could have managed infrastructure that you end up building in tandem. So you have very high cohesion between the managed infrastructure and the framework. I think positioned it uniquely to be able to chart the course a little bit here. But the ideal is that that highly cohesive managed infrastructure and framework is loosely coupled. So other frameworks work really well on Vercel. And the managed infrastructure can be used to power anything from Python to PHP to any JavaScript you can bring out. But I do think that you need to have influence over both the server and the client to achieve the next milestones we're trying to achieve.

Can I just throw one thing in there? Because Dan has always asked me to say this. You don't have to use a server at runtime for RSCs. So it's fine, but you probably should. Moffy, did you want to add something? I'm good. Okay. Awesome.

Final question, just before we wrap up, is for anybody who's new to React, what tips and suggestions would you give them to get started with React? Go read the official docs tutorial. Yeah. Plus one. It's so good. And just build things. Don't get too lost in all of these details. Don't try to learn how all of these new features work in entirety. Most of us, the people here who work on React don't fully understand these features. You don't need to learn all of React to be a React dev. You need to build things with React to be a React dev. Anybody going to plug epic React? Dang it. Yeah. Moffy, Ellie? I mean, I'm supportive of our docs, so... Docs are great. Cool. All right, folks.

Any final thoughts? I love these guys. Sam? Where do I go to get more information about React IDE? I believe I've been not included in some meetings recently. I want to say thank you to the community. This is something that's pretty unique for React. Thinking about our partnership with Vercel, and other companies, like Microsoft... React is so much bigger than the constraints that we have. This would not be the community that would be here, the events that would be here, if we weren't all working together to push these things forward. You don't want the constraints of meta.

You don't want us to make you all use PHP for server components. So we need to work with a community, we need the extra constraints, and this makes React better for everybody. Education, influencing on YouTube, all of this is what makes the community the community. Thank you for your contributions to all of that.

Well said. And thank you to Eli for continuing to push this. I know it hasn't always been the easiest at a big company to be like... Yeah, we need to bet on this open source thing and this community and have these events and do all this stuff. Fang doesn't love that, and you're pushing really hard, and we do recognize it. So obviously, round of applause for the community, but more importantly, to Eli and to the whole team for making all of this possible.

On that beautiful note, thank you so much for joining this panel and for your spicy and sweet takes. And thank you, folks, for joining us and being part of the audience. Thank you. Thanks.