Panel Discussion: The Future of React and Its Ecosystem

Howdy, folks. Welcome to our panel on the future of React and its ecosystem. Before we dive into our discussion topics, let's get familiar with the rest of our panel. So maybe we could start off with who you are and what you do. Sure. I am Shondae Person. Shondae pronounced like a day of the week. Friday, Saturday, Shondae. I am a senior software engineer at Netflix and focused on the UI of Netflix. Seth Webster. I work at Meta and I'm the head of React Foundation. I'm Nicholas Gallagher. I work at Meta and I work on cross-platform React. My name is Amy Dutton. I am a design engineer at G2I. My name is Mark Erickson. My day job is working at Replay. And outside of that, I am the primary maintainer for Redux. Fantastic. So let's dive right in. I think a good place for us to start is maybe talking about the React Foundation. What? Yeah. I've never heard of it. I'm putting you right on the spot. Thanks. So I think a lot of people are interested in how you see the React Foundation kind of influencing developers' day-to-day lives, like as React is evolving. Could you maybe talk a little bit about that? Sure. I think the main way I see things changing are gradually. I don't think that we're going to do any major rug pulls or overnight changes. I think the big thing to remember is that the foundation is sort of two parts.

There's the React governance as an entity, which is a business with 501c3. That's going to be us like raising money for putting on events like React Conf and merchandise and fundraising and all those things. And then there's the technical governance of React. And so we have to take those two parts separately. Up until now, it's all been housed under meta as one thing that nobody had any insight into or visibility into what we were doing. This is going to bring React much more into the open. And so from a governance perspective, you'll understand why we're making everything's going to be very transparent. You're gonna understand why we're making financial decisions and how we're allocating funds and so forth. And then on the side that I think more people probably care a lot about is the technical governance side, which is going to move more towards the model that we've been using internally, but we haven't exposed externally, which is to start really relying on RFCs, our change management process, which has been in place for the last couple of years, I think 18 months, we've been using it to move through various stages. We've been collaborating with Vercell, of course on that, and they've been one of the primary partners. But they've started to have to go through this change process just like we at Meta have to go through this change process to get something from an idea out into the public's hands. And most of the ideas end up with on cutting room floor, because they just don't scale. They just don't work well. We're going to bring that into the open and so that more people can participate in that. You'll have less of a question of like, how do I contribute to React? But it's important to think of like, what I'm going to spend the majority of my time on is making sure that all works well, but, you know, fundraising and making sure that we can share funds with, I don't want to get into too many details here, but share funds with all of the maintainers of libraries and educators and so forth that are really the heart and soul of the ecosystem, as opposed to just keeping it all behind Meta's walls.

I love that. What would you say success would look like for the foundation three years from now? I think a big part of it would be that the most important libraries and frameworks that are built around React, the ones that we all depend on on a daily basis, feel loved and supported by the foundation both from an appreciation perspective, but also from a monetary perspective, that it's easier for folks to focus on that instead of with nights and weekends energy, but with more full-time energy, maybe even hiring staff to support those projects. I think that, you know, seeing more communities flourishing around the world, we have a bunch of dark spots, like where there's not a lot of React usage in Africa, Southeast Asia, Japan has an amazing burgeoning React scene, thanks to the efforts of companies like Amazon who've been launching products there that are built on React and require React. And so I think there's a bunch of success metrics that we're looking at about flourishing community. And at the end of the day, I think the thing that would matter most to me personally is that I'm seeing more ideas brought to life through the openness of the foundation than were being brought to life before.

I guess shifting gears to the technical side of the house, I'm kind of curious if we can talk a little bit about React Compiler. React Compiler is starting to ship in more mainstream sort of tools and frameworks. I'm very interested in how folks see that changing how developers will be writing code on a day-to-day basis. Is this anything anybody's got a particularly strong opinion about? I don't have a strong opinion about anything really in tech, because there's a trade-off. And my favorite phrase in tech is it depends. I do wonder how the... I feel like a lot of the React Compiler and the use cases have to do with use cases that are good for server-side rendering. And that's not every case in using React.

I feel like a lot of the React Compiler and the use cases have to do with use cases that are good for server-side rendering. And that's not every case in using React. Personally, a lot of the things that I do, it uses GraphQL on the back end and we have a separate server that we leverage. But React itself is generally a single-page application, like most React applications that I've ever built. So I don't really have a strong opinion, but I do feel like it's really exciting that there are ways to kind of serve those use cases. Because I know that historically front end has been kind of looked at as the easy route when it comes to engineering, and people don't... We kind of have to fight for our spot for respect on the front end. And people think it's somehow much simpler to just... We're pixel pushers and we do border radiuses and we change the colors of buttons and things like that. But every time something big comes out with React and really grounds the UI community and the React community as an engineering tool, an engineering library, an engineering framework, I feel like it's just a win for all of us React developers or all of us front end folks. And I'm like, yeah, this is engineering. We're not just pixel pushers. We are a little bit, but there's more to it than that.

I think there's a big question for me that, you know... I think if you took a room full of C developers and you asked them to build a React website, they would probably struggle with it as much as a new React developer would struggle with writing C code. So I think mad props to all of the front end engineers out there. Give yourselves a round of applause because it's actually really tough, especially with everything changing all the time, right? But I think the other piece that that's really important to think about is that React compiler is never been just about automatic memoization. It's been to create the foundation of a compiler that truly, deeply understands React code and the intent of the developer who wrote it. You know, the economic value, the value of React, is in all the code that's been written, and it's in all the code that will be written. But that's a tax that we pay because it's very hard for us to change APIs. It's very hard for us to make new decisions about the framework because we pay the cost of the success of React. And so the compiler opens up an entire world of changes to React because we can compile down to the version that you're using and allow you to use new features.

And so I think the other really interesting aspect of it is with the advent of AI and vibe coding. Imagine a compiler in the loop workflow where instead of the LLM spitting out the best idea it has based on the training data that was given and the fine tuning it was given. But it actually talks to the compiler as it develops code and is able to say through the lint warnings, through the errors it receives, through the really deep understanding the React compiler has, which it can say, look, you're doing this. This is going to cause unnecessary re-renders. You're doing your reading ref and render. You're, you know, all these different things we can know because this compiler is a true compiler, every sense of the word. It understands React at the finest level of detail, and it knows all the rules. It can actually tell the LLM you're doing it wrong.

One of the most amazing things about vibe coding today is how often you'll see vibe coding be like, you know, I know I'm not supposed to do this in state, so I'm just going to use refs to track everything. Right? And if you've had this experience, your code is littered with refs. Right? That's not the right way to do it. Bill, we were just talking to some folks at the table last night about this, but just because you're a front end engineer doesn't mean you get to shove everything you need to do with your application into React. You should be separating your services out. You should be building classes that, you know, emit events and that you're subscribing to with React books. You know, still have to do those good engineering practices, and with the compiler in place, we can tell the LLM how to do that.

I think that's a very interesting idea, and since you took us to vibe coding, I will be asking the panel some questions about that in just a moment. But on React Compiler, any other thoughts on how you think this changes the nature of performance or memoization optimization from other folks? Yeah, so one of the things I've seen answering questions online is that a lot of people just don't have a good understanding of React's mental model in the first place. That's why I wrote a stupidly long blog post about how React rendering works, and you know, one of the most common misunderstandings I see is people still assume that my component only re-renders when its props change when in reality it's React renders recursively by default until you tell it not to in a specific component using React.memo or similar. So I am very excited for the compiler with the performance optimizations that we get. I'm also very excited about the potential of simplifying some of the mental model of React, but this does start to bring in some questions about how do we teach React in a world where the compiler becomes a default? Right now it's still something you very much have to opt into in your build tool chain because it's new, tool chains don't necessarily have it by default, there's some extra build time, etc.

But if we think ahead to a world where it's integrated into all our new project setups, what happens when the baseline React behavior is rendered recursively by default, but now that the compiler is in there and doing its awesome magic, and it's actually flipping that on its head to where it truly is, your child only re-renders when the props change. And we had a very similar situation with Redux. If you've seen your original legacy Redux code where you have all these handwritten object spreads in the reducers, Redux requires that you do immutable updates. And that was always the number one source of bugs was getting that wrong. So when we shipped Redux toolkit, we integrated the Emmer library for simpler immutable update code, and it simplified the logic, but now you're writing what is mutating syntax in a reducer. And that's only valid because Emmer traps that and converts it into a safe immutable update. But you still have to know that this is an abstraction, the magic only works inside this function call, because we have this piece working under the hood.

And you have to know that this is what I... this is the pattern I needed to be doing. It's just happening for me automatically. And so I see the same thing coming our way with the React compiler, where you do actually kind of need to know the layer below the abstraction. You need to know the baseline React behavior, and then you need to know that the compiler is doing all this work for you and actually flipping the behavior model on its head. And I'm not sure what that looks like in terms of teaching terms or in the docs. I've had some conversations with Dan and Ricky and a couple other people about right now the current React docs or the new-ish React docs are awesome. I love the teaching flow. So well thought out. But now we have both an additional layer and a difference in the mental model. Do you teach the new approach first and say there's some magic going on? Don't worry about it. How much do you need to know the fundamentals first, and then say here's the additional piece? I don't have answers right now, but I think these are the kind of things we're going to need to work through in the next year or two. I think that's a great setup for the next question. I would love to talk a little bit about how we educate people about React. Obviously React has gotten more powerful, more advanced over the years. You've got suspense, transitions, React compiler now. I'm curious if any of you have thoughts on how we should be changing how we teach the defaults and whether we should be starting from a much simpler place, whether we should be assuming these things are going to be used. Anybody have strong hands? Yeah, what's interesting is I've found that there's really two types of developers. There's the developers that just love the magic and embrace the magic, and there's other developers that are like, well, I can't use it. I have to know exactly what's happening under the hood before I can even think about it. I think sometimes the docs, we have to take both of those people, both of those personas into account in determining what is this person's use case? What is the problem that they're trying to solve, and how much do they really need to know? Some of it's kind of interesting because that also trickles down to frameworks and meta frameworks because for a lot of us, that's how we interact with React is through the context of a meta framework and how they structure their implementation and things like that. So I did say I don't have strong opinions. I actually do. So I have a pretty strong opinion on learning, and I do recognize that's a great point, Amy, that there are two different flavors of developers and their different styles of learning. Some people do prefer a little bit of magic, but the analogy that I think of is when I was teaching my son to read, I could start by just giving him sight words and you can start with words like the and see, or we could practice memorizing how to look at words and remember those words, right? Or which is the approach that we took is hooked on phonics. Let's take the phonics route and teach you the individual sounds of the letters and when a vowel and a consonant and a vowel happens, how does the sound of the vowel change? And you bit by bit expose them to the under the hood, this is what is happening, and it makes them so dangerous because now they can do more than just what was written in that doc. They can do more than just that little tutorial that was on the Remix website where you're building an invoicing app, or they can come up with a concept and then they can apply it in multiple ways. My son can read comic books, he can read newspapers, he can write paragraphs, he can do so much more because he has that fundamental knowledge. So I know that not everybody has the time to learn all of it, but I do think that, you know, whether your style is to lean in magic style first or to go under the covers and see what's under there, there should be a piece of your learning that goes back and understands what's going on under the hood, which doesn't answer your question about teaching. So the ways that we teach it, I think, are to, I know, to cater to both styles, but to give people a glimpse under the hood.

So if there's some magic that's happening, there's a React compiler, talk about it from a high level and say, okay, this is what it does, this is, it brought us from point A to point B. It used to be awful, the world used to suck so bad until the React compiler existed, and this is the narnia that we've placed the world in because React compiler exists today. But then a breakdown of, okay, this is exactly how it does that. These are the roads that we took to get to narnia, these are the trade-offs that we could have had, this is the left that we could have took, this is the right that we could have took, but this is why we went straight. And I think learners should do, the learners part is to do all of that learning and consuming, and then continue to reinforce that learning's never a one-time thing, you have to keep on practicing it as you go, keep running into different clutches and weird edge cases, build a redux or something and learn a little bit about it more that way.

Well here's the hand grenade, right? What happens with AI? Do we have to learn all that anymore? And that's a great question, I have strong opinions on that. Go ahead, Seth. I really appreciate both of your points. I think where I sit on this is that this is sort of a generational thing, you know? Very few of us look into how brew works, or care how brew works, but when it first came out everybody wanted to understand. So I think that we're in a stage now where because something's new, people are like curious about it, or scared of it, or frustrated about it, and they want to understand more about how it works before they'll trust it. And so you're kind of in that stage of learning to trust the compiler, learning to trust these new things, learning to trust server components or not. So I think those are important things, but I also think that it is sort of our duty to not only teach human beings how to do this, but our duty to actually teach AI how to do this well.

I don't think that two to three years from now we're going to care all that much about how the code looks. We're going to care a lot more about how fast we can bring ideas to life, which is, I think, what all of this, from the smallest component we've built for React to the largest meta framework is all coming to, is really helping everyone in the world be able to say, you know, have that bedtime thought and be like, oh, you know, it'd be so cool if this app existed and then tomorrow be able to see it. And so, like, to me, I don't care which one of the technologies wins or, you know, which, what the documentation is like or what the learning is like, as much as I care about shortening that lifecycle. And so to start today, we need to be able to serve all the audiences with our documentation and AI as well. But in the world of tomorrow, it's about optimizing that lifecycle. And so, you know, bringing more ideas to life more quickly. That's really where I started from, too. I almost resent that I had to become a programmer to build things. And, you know, the promise of something like React is that it's supposed to black box the complexity for you. And so whenever a problem with an application comes back down to, oh, well, you have to know that you can't just think about this one component, you have to think about these cascading updates. This is like a failure to deliver on where the team wants to get to. And so things like the compiler are like the steps that they're taking to get us closer to that, so that you don't need to learn the complexity that the React team knows, in order to accomplish the task of building an application. And so I think when it comes to teaching, if we have to have complicated, elaborate explanations for people to be productive in any technology, it's a sign that the black box has to be opened. And you can't just work with the inputs and outputs, you have to like look inside and understand how it works. And I think a lot of what Joe and the team are doing is trying to remove as much of that deep dive into the black box as possible, so people can get back to doing that work of realizing an idea as quickly as they can. We do have some of the compiler team here today. I don't know where they are.

I don't know where they are. I can't see a single soul. But big round of applause for them. This has been an amazing journey. I'm going to ask you a follow-up question. You and I were discussing benchmarks, evals, opportunities for us to improve the quality of React code that might get generated by models a little bit earlier. What do you see as being the really big opportunities ahead of the community for helping out there, and really just making it easier for people to build production-grade React apps with the help of AI in the future?

Yeah, I think, you know, in some ways, the advent of AI is forcing us to address some of the absurdities that we've allowed to occur when it's been people that needed to be trained, where you just rely on like, oh, you just need to get better at your job, you know, or you're junior, eventually you'll understand how this works. And so I think understanding that sometimes when we're trying to even just starting with the basics of working with AI, which is creating like instruction sets for how to work with tools, that sometimes when you're writing those instructions, you realize it's kind of ridiculous how many instructions I have to put in for this, you know, non-deterministic tool to function properly.

And so all of this work that I think is going to emerge is going to be a mixture of helping us understand how can we steer the existing models to produce better output and what are the tools that we use to help us understand if they are producing better output? But then also maybe how do we feed better data into those, into the training pods in the first place so that out of the box they perform better. And so I think there's going to be lots of layers where domain experts, as they start to think about how they can scale their expertise via AI so that when, you know, someone has an idea for an app, maybe they aren't a developer at all, maybe they're just getting into the space relatively new to it all, that these tools, when they use them, produce the kind of quality output that we spend hundreds of hours trying to train people on like this is how you should use React today or this is how you should use any of these parts of the stack today.

And so getting people to write something closer to what, you know, if you work on the React team, you have opinions about what React code should look like. I think AI becomes a tool, they don't have opinions now, but AI becomes a tool where maybe you can help everyone who picks up React today get closer to some idealised form of how you would like them to write code without having to put them through like a computer science degree. And so I think in that sense it could be quite empowering for a lot of people to think about how can you use your domain expertise to work through all this emerging part of the AI tool chain to help the code that you want people to write to come out of these tools? Whereas like, I mean, there's many of us at places like Meta who on paper look like we've been doing this for a long time and we don't know how to use like the latest React APIs because a lot of people, like very senior, they're busy doing their jobs, you know, they're working with teams of people trying to accomplish the goals of the team.

And so it's not simply that people aren't capable, it's like sometimes people don't have time, sometimes people just haven't had the time to spend with new APIs and tools. And so this AI platform that's being built has a potential, I think, to help get what the team's building frameworks want into people's hands faster. If I can make it like really concrete, if you're a framework or library offer, write claud and agent instructions for using your library that people can put into their claud or agents file. Write evals, learn to write evals for your framework so that, and share them open source, all those should be open source, obviously share them with, you know, Anthropix, share them with all the model providers, and make sure that when they're doing their training, they're actually using your evals to determine when they're, you know, reaping all the code off of the internet, which of that code actually follows the conventions that you want people using in your framework. Those two things I think will help accelerate the pace at which AI gets better at this.

I think that we've been digging, at Google, we've been digging into this problem a lot recently, and I think there's a huge opportunity to really lift up the benchmarks and our shared eval efforts. So if anybody watching this online later, or that's in the audience is interested in this problem space, reach out to us. I want to say another thing of like, the React compiler is a great tool for that, because it's like Seth was saying, it has a deep understanding of what the code is, and so it's a novel tool where if you're ingesting the entire internet, you can feed potentially React code through something like the compiler and get signal beyond, you know, there was a time like last year when people internally were like, how do we know what is good code? And we're like, yeah, this is a good question, but things like the React compiler can at least help us figure out what's good React code. It definitely can figure out what is bad React.

It definitely can figure out what is bad React. So can I ask a quick question? Sorry, I didn't even know. Our new moderator. I know, thanks, Adi. Where in the AI process would the compiler be? Would it be a tool that an LLM could have access to? Would it be part of the prompt? And or, yeah, where does it fit inside of that? Yeah, I think you can use it basically both ends of the pipeline. You can use it on the ingestion side. So as code is being pulled off and, you know, considered for training, it can be run through the React compiler and the React compiler can give you a score effectively and say like, hey, this code is, you know, 60% compliant with the rules of React and the model can then decide to say, well, I'm only going to take the 60% that's compliant and I'm going to discard the 40% that's not, right, and that's part of it. And then when you're fine-tuning for coding purposes, right, include compiler in the loop of that fine-tuning process, because you're now down to the corpus of code you consider to be like, you know, gospel, you can actually run it through there and actually figure out how to generate a fine-tuned model that complies with the compiler. The compiler is a very good source of truth as to whether or not your code is following the rules of React. Thank you.

So Shande, back to education, if I am someone that is learning React today and I have access to AI, how do you see that changing the learning process? Yeah, so I personally will use AI as a tool to kind of get deeper, but I feel like it's like talking to somebody else. So I can choose to trust or not. And I can kind of smell, okay, this is something that I should probably look into a little bit more. But the benefit is that no matter what the answer is, it'll point me in the right direction. So I'll use it as a way if I have like a broad question to kind of find an answer because one of the hardest things as a self-taught engineer is to find where the answers are and where the source of truth for that answer is. So largely is AI is a tool for me to help me to learn it. But specifically to learn AI concepts and React concepts, I started with the fundamentals and I don't think that's the path for everybody, but it did help me to have good mental models when I did start to use abstractions like React and AI to get a better understanding when I come up with a bug and I didn't have the React compiler to tell me that this is a linting error, this is just bad practice, or this is why, you know, I'm console logging and I'm just seeing this is happening 5 million times in the console. So it gives me a better mental model of like, this is what the DOM is, this is what the virtual DOM is, and this is when things get rendered, this is when things get painted. And so having all of those fundamentals were critical for me in the way that I like to learn and build upon that foundational knowledge. The way that I see it changing though in the AI landscape is that I feel like it's easier to get access to information. That said, it's easier to get access to the incorrect information just as it's easier to get access to the incorrect information. So I think it's up to the individual to do their own due diligence, start to suss out, like even the educator, because there are also bad actors in the education space who are more about clicks and likes than they are about actual teaching grounding concepts. So it's really up to you to start to build a community, start to peel back the layers and learn about, that's why I feel like it's so important to learn about what's going on under the hood, because that way you can discover on your own, you can do your own little science experiments and spin up different apps and explore as you come across bugs by bugs. There's never a day where I'm just sitting down and I'm like, today's going to be react research day, it's just like I have a project that I have to do and I come into a bug and that's how I start to learn more and more. But then you grow as you encounter those bugs and you experiment with, okay, this is how I'll solve this problem this time, or I'm going to try this thing. This matches with what this educator told me, or this matches with this other thing, or I'll just put it in AI and AI can point me in the right direction or AI might be able to help answer that question for me. But at the end of the day, to me, it really, it matters that you understand what's going on under the hood at some level. I don't think that we all need to be computer science experts. I'm not. We don't have to be computer science experts, but start to get a good picture of what the code is doing, what the compiler does, what's the value of it, why it's there and why it makes a difference if you put it in and not.

So, under the hood. I would echo some of that because we kind of talked about the two different types of developers, the ones that like magic and the ones that don't, but for me it's been helpful to AI tells me something so I implement it. Oh, that was magical, but now explain to me what you did. And that's kind of the looking under the hood as we've talked about. One of the things I realized when I've talked to junior developers, I take for granted is because I work on a development team, I have people that I can go and ask questions and a lot of juniors don't have that yet if they haven't landed their first job. And so, I think AI is really helpful for being that person-ish for them to be able to explain those concepts and help them to be able to understand things. And it does help to know what is actually happening because it does go off the rails. It does hallucinate and you have to have at least enough knowledge of what's happening to know where it fell off to be able to get it back on track. Right. I think this is why it was so important what you were saying earlier about the need for teams that are building software to provide rules and instructions with that because it's going to become really quickly, if not already, people are going to learn from what the AI models produce. I know in my job there's code that I would never have written myself that I prompt the AI to write and then I essentially learn how to write that kind of code from its output. And so, there's foundational concepts that as a programmer or developer are useful because they will translate across languages but you might not know how to write Python code, you might not know the APIs to write an AST code mod. But when you say here's what we need to accomplish, you see the output and because it's so close to the task you were trying to accomplish, you can really learn directly. Because humans, this is how we learn, we learn by copying, we learn by mimicry. And so you see something directly associated with what you were trying to accomplish. It goes in much easier than reading abstract documentation or code that someone wrote for another task that you have to go through all these mental translations to figure out how do I take what I've seen here and apply it to what I'm trying to do over there. So, I think on that front, that aspect of learning is going to become really important.

And the other is that, you know, part of when you work with AI and it does go off the rails, there's an element in which you there's reinforcement learning within us as well which is the clearer you can describe your ideas, the more the prompts start to look like specifications. And the more those prompts like I spend a lot of time working with LLMs to rewrite my prompts. Like why did you go off the rails? Okay, let's rewrite the prompt. And you go through this cycle that starts to become a little bit like if you and I are talking about something, we refine an idea and then we end up with something more concrete like a document or a specification that really describes very clearly when this happens, do this. And so, I think that way of working is going to help refine people's thinking. Because maybe a few months ago when this all started, people thought, oh just write me an app and then hope for the best that what comes out. And instead, the prompts for complex applications are going to look like essays full of, there's going to be collections of templates and prompts and very specific descriptions of how things should work and it starts to look much more like the technical specifications that we're used to. It's just that the production of the code might be kind of automated a bit more than it has been. Yes. I think that on that topic, something that I see people struggle with, whether it's with AI coding in React or just historically trying to go on this journey of learning how to use React in production is architecture and rendering. And I wanted to ask probably one of our last questions about this. So, I'm seeing a clear split in the community around architectures that lean a lot into server-side rendering and streaming versus doing simpler single page applications. And I think that whether you were saying yes, we've got hybrid architectures or something simpler, navigating that spectrum continues to be difficult, I would say, even for intermediate and advanced developers.

Any strong thoughts on this topic? Maybe not strong thoughts. I'm in a weird position because I observe the ecosystem and I'm not even writing that much front-end code myself these days. I know what tools are, I know what problems they solve, I don't even necessarily have lots of hands-on experience at this point. There's been a lot of debate within the React ecosystem, within the broader ecosystem about the trade-offs of different architectures, how much JavaScript should we be shipping, how much should we assume about the performance of end-user devices. Is the web for documents? Is the web for apps? I mean, there's a lot of competing concerns and competing thoughts. My fallback answer to a lot of things is, well, we just need to add a lot more information to the docs.

One of the broader issues with learning React and the ecosystem in general has been that React itself was traditionally just one piece of the puzzle. The early docs referred to it as just the view layer. It was great that you could pick and choose all the additional libraries you needed for your one use case. That also meant you had to pick and choose the libraries for your use case. And that's one of the reasons why the React docs have switched over to a default of recommending frameworks that provide all the integrations for the data fetching, the routing, and all these other pieces. But even there, you still kind of need to know what kind of an app am I building?

But even there, you still kind of need to know what kind of an app am I building? And if the framework offers 15 different modes and all these different options, which of these tools are the best approaches for the kind of app that I specifically am wanting to build? And this does become much more of a larger research question. You need to know the basics of React itself, the rendering, the component model, all those pieces. But then you have much larger architectural questions. And it's not necessarily the place of the core React docs to cover all those things.

I don't think the React team's job is to be spending time writing docs on trade-offs between full-blown application architectures. But I do think, this is actually a little bit of a gap in the docs at the moment, is that as great as the current learning path is, it kind of leaves you hanging a little bit at the end. It's like, okay, I've gone through, I've learned about React components, I've written some examples in built-in sandboxes. How do I translate that into the real world? If next was listed in the installation page, where am I supposed to put my component files in a next project? What does that mean? So maybe even just a small step could be adding a next steps page to the docs, or pointing to some community resources on architecture.

So there's this trade-off between learning React and all its concepts, and then how do you carry that knowledge into the real world and start thinking in the larger architectural terms. Right, and I think because, like I said before, everything is just trade-offs. There's so much that you can choose, and there's so little of, there's one correct answer for anything in tech. But a lot of space where people get confused is like, well, which choice is the best choice? Should I do streaming? Should I do a single page app? And clear reasons why, and a framework for understanding that. So I think even just like one of those old mall maps, where you're just like the little star, like you are here.