The State of React and the Community in 2025

All right. Good afternoon. My name is Mark Erickson, and today we are going to talk about the state of React and the community in 2025. A couple quick things about myself. I am a senior engineer at Replay. I will answer questions anywhere there is a text box on the internet. I moderate communities like the React subreddit and the Reactaflex Discord. I collect interesting links and talk about them in places like the This Month in React podcast. I write extremely long blog posts, and I am a Redux maintainer, but most people tend to know me as that guy with the Simpsons avatar.

Now, I have entirely too much material to talk about and not enough time, so we are going to go very quickly. I'm going to have to summarize a lot of things that I could talk about for hours. There's a lot of things I'm going to have to skip over. I am trying to explain things as best as I understand them. I may get some things wrong. I do have the slides on my blog, as well as a blog post that goes into more detail. There's a QR code for that. I'll show this again at the end if you want to follow along.

So, the state of React today is complicated. Really complicated. On the one hand, React is extremely successful. It's the most widely used JS framework. It has influenced all the other tools and frameworks in the ecosystem. We've had React 19, which came out and gave us things like stable React suspense and server components and a lot of new features on the client side. The React compiler is in release candidate. Things should be looking great. And yet, I've spent a lot of time reading discussions and talking to people, and a lot of people are frustrated. They don't agree with where the React team is going. They don't understand why the React team has made decisions about what features to work on, or even how those are being developed. Some people are just, like, actually suspicious about why the React team does things. And so I've even seen a split between how the React team seems to want people to use React, and how people are actually using React in practice.

And that doesn't even touch on people outside the React community arguing about whether React is even a good idea in the first place. And it doesn't help that everyone is arguing about a different subset of these problems, which makes this really hard. Some things I've seen. I've seen people complain that Vercell took over React and they invented server components just to make money off servers, or the React team is forcing everyone to use server components. Why do server components need a bundler anyway? What's up with React and Next? Why is the React team emphasizing frameworks so much? And a lot of other very similar questions.

Now, I want to be very clear. A lot of these complaints are either misunderstandings, conspiracy theories, or FUD, and it's not the React team's fault that people are thinking a lot of these things. But it's also true that some of the communications from the React team have made this a lot more confusing and sometimes contributed to the confusion. So the goal for today, very quickly, we're going to look through some of the history of React and talk about why and how React has been developed and the influences. Talk about what's driven the directions. Look at some of the disconnects between the React team and the community and try to address some of these concerns. I'm not trying to point fingers. My goal here is to explain.

So if we go all the way back, React was originally a very small UI library, just the view layer. And because of that, we grew a huge ecosystem of different tools and packages to solve every possible use case. Dozens of different options. And some of this was because Facebook has all their own built-in solutions already, but also the React team didn't want to play favorites in the ecosystem. Back in 2016, we had Create React App to simplify the process of creating new React projects, but it was really only focused on creating client-side applications. And because React never had a built-in data fetching layer, we've always used third-party libraries to do that.

As Taner said earlier, React has always had a concept of server-side rendering, but it was very hard to do that yourself. And so frameworks like Next and Remix abstracted that process and made it easier to do SSR. But also as Taner pointed out, most of us tend to think of React as a client-side framework. And over time, bundle sizes have gotten very large as we keep tossing in libraries for drop downs and other things like that. And so SSR is kind of a secondary thing. And a lot of us are working on projects that don't even use Node on the backend.

Create React App became standard for a few years, especially for beginners, but it became unmaintained. And Dan Abramov finally wrote a long comment and said, it's deprecated, we don't think it's the right approach anymore. But the team never officially marked it as deprecated, and by that time a lot of people were actually just using V, anyway. And over the last few years, we have seen an emphasis in the community on doing more SSR, trying to improve page loads and cut down on waterfalls. So there has been a shift in mindset.

Today, if you're creating a new React project, the most common tools are things like Next and Remix or React Router V7, Vite's React plug-in, or sometimes still Create React App. It's deprecated, but it's still in common use. And it's worth noting that the downloads for Vite plus CRA are actually still more than Next itself. So there's clearly still a lot of interest in client side applications. Back in 2018, the React team announced suspense as a concept. And they said that we're going to get this suspense for data fetching thing someday. It never really materialized. But in 2020, they announced React Server Components, the idea that you could run a React component on the server, async, fetch some data, pass it as props to the client.

And this was meant to both be a React built-in method of data fetching and a way to shrink bundle sizes. And I want to point out that this was created while the whole React team still worked at meta. Now React's development process has always been to try out new features inside meta. They would prototype, have some meta app teams try it out, throw it away, iterate, refine. And so by the time they announced a new feature, they were very sure this is what we want to ship.

And they have to spend time supporting meta's own usage, but they have a decent amount of freedom in building what they think is the right approach for React. Then we have Vercel. And Vercel is primarily a web app infrastructure platform. And they built Next. They made it very easy to host Next on Vercel. And starting in 2021, some React team members began moving from meta over to Vercel. And so today the React team is split. About 15 folks at meta. About five folks at Vercel.

The Vercel folks are mostly building the server side features. The meta people are working on the compiler and some other things. But there's still one big combined team in terms of what they're trying to do. So what we ended up with is the Next app router is the first production version of React server components. And it's really cool, but it also had some problems when it came out. I personally think that they made it the default option too soon. There were a lot of problems with Next's caching. And it was kind of hard to figure out, is this the Next bug? Is this a server component bug? It all kind of ties together.

And one thing that didn't help was there really wasn't any mention of server components in the actual React documentation. Now on that note, the React team announced in late 2020 they were going to rewrite the docs, improve the tutorials, teach function components first. It took them almost two and a half years to ship it, and the current React docs are wonderful. I genuinely love them. Fantastic learning resource. But still no real explanation of server components in the docs.

Now when the new docs came out, the React team changed the recommendations for what tools you ought to use when you create a new project. The old docs said if you're making a single page app, use CRA. If you need SSR, use Next. And the new docs have this huge emphasis on frameworks. Built-in data fetching and routing and bundling, and so they mentioned things like Next and Gatsby or Remix. And they really said everybody in the React community should be using frameworks. Now it's fine that they didn't mention CRA. It's dead. We shouldn't be using it anyway. Why didn't they mention Vite? Why is Next so prominent? And so this push for frameworks caused a lot of people to start arguing.

People constantly complain Vercel invented server components just to make money. I know why people say this. They're wrong. Please stop saying this. The key point here is that server components were a React team idea, not Vercel's. The issue was that Facebook meta already had their own back-end infrastructure. You really couldn't test and try out the new features inside of meta. So the React team convinced Vercel, here's what we want to build. Will you be the alpha testing and invest in the implementation? Dan Abramov said it's more like the React team took over Next's direction and told them what to build. There are a lot of valid reasons why people are making these associations. Vercel has invested a lot of money in the team and Next and server components. They do benefit from having people running things on their infrastructure. And there is a very tight relationship between the React team and the Next team.

And there is a very tight relationship between the React team and the Next team. Although, as I heard some of them say yesterday, they have tried to have some degrees of separation. So I understand why people have drawn these conclusions. The React team did try to get other frameworks involved in the development process, but ultimately we ended up with just Next as the original implementation of server components. The good news is we are seeing other frameworks making progress on that today. What I really want to emphasize, server components are not a Vercel invention. They are not exclusive to Next. They are a React concept. So sort of similarly, server components require a bundler because they really tie into how the bundler builds the module graph. You need to know which of these files need to go into the client side, which of these files need to go into the server side. So it's not something you can just drop in to an existing application. So it is a React feature. The React core provides the primitives, but it's up to a framework to decide where and how they call those methods and even what the usage patterns look like. If you look at the docs for the Next app router, it's very different than what React router or Waku or Redwood have said they're going to do for their server components implementation. Along with that, frankly, server components is just a bad misleading name anyway. You don't actually have to have a running server process to use server components. I much prefer the name serialized components. They're outputting JSON, representing the children. A couple other things I've legitimately seen people say. I've seen people say that React only works with Next. Come on. That's just wrong. Or that somehow React on the client will stop working someday? No. No. React, everything that we have in React today, is going to continue working. It's not going to suddenly break. In fact, React 19 shipped with a lot of new features that only work on the client side. And so all this new server component functionality is entirely optional. You don't have to use it. But it is true that a lot of people have looked at this and said, well, server components are apparently the future of React, so we think we have to try to keep up with where React is going, and they have had an impact on the ecosystem.

Things like CSS and JS libraries are kind of going away because they don't work in a server component environment. This impact on the ecosystem raises the question: why is the React team emphasizing the framework idea so strongly? The React team's stance is clear—it's not about Vercel or a dislike for Vite. They believe that frameworks, combining bundling, routing, and server-side rendering, are crucial for modern applications. React's aim is to improve performance by standardizing the use of frameworks to mitigate issues like slow apps and large bundle sizes.

The React team envisions frameworks as an all-in-one solution, eliminating the need for developers to select individual components. By promoting frameworks as the default starting point, React anticipates enhanced performance for average apps. The rationale behind this push is to simplify development by incorporating essential features into frameworks, providing flexibility for future adoption of additional functionalities like server components. However, some critique the one-size-fits-all approach, stating it overlooks the diverse uses of React today, especially in SPA architectures, which remain prevalent and valid choices.

Concerns arise regarding the React team's heavy promotion of frameworks, particularly Next, as the default option. The React community's diverse needs and preferences, including existing codebases and restrictions on backend technologies, may not align seamlessly with this approach. The React team's focus on simplicity in documentation, aiming at beginners, has led to a concise list of recommended tools. This strategy, while well-intentioned, has sparked debates about inclusivity and the acknowledgment of alternative tools like Vite within the React ecosystem.

And I think there's a lot of good, very valid points behind that. I understand why they're saying this. I think they have good reasons for saying this. I will say that I think this recommendation has become kind of heavy-handed and single-note. And it really doesn't give enough credit to the variety of ways that React is used in the ecosystem today.

Tanner gave us some stats earlier. I had VEET and CRA are over 50% of downloads. Tanner said, like, 85% apps are SPAs. An SPA is an entirely valid architectural choice. And we have some great tools for working on these on the client side today. And so I think this single note of use a framework, use a framework is well-intentioned, but it doesn't have enough nuance to it.

If you're a brand-new beginner, should you really be going straight from the React tutorial into Next with all its complexity? What if you have an existing codebase? What if you're not even allowed to run Node on your enterprise backend? When the new docs came out, there was actually a phrase in there that said, if you want to use a framework, well, we can't stop you. And they've said it wasn't intended this way, but it kind of came off as rather dismissive of the way people were using React.

And the fact that they spent so long avoiding adding VEET as a recommendation started to become suspicious itself. If a third or half of the ecosystem is building SPAs and using VEET, why is it that they aren't even listing it as a possibility in the documentation? Now, the React team has said, we want to focus the docs on beginners. And so we want to keep the list of recommended tools short and simple so we don't confuse people. And I think I understand. I think that's a good decision. But more people than just beginners read the docs. And what you list in the docs acts as an official stamp of approval. And that's why they spent so many years trying to avoid having recommendations and playing favorites. So it is hard to balance keeping things simple versus listing the different ways that people use things. But if, like, half your ecosystem has been building things this way, shouldn't the docs kind of reflect that?

Earlier this year, create React broke. And I ended up pushing the React team to both fix it and announce it's actually dead, which they did. Finally. When they did that, they added a new doc page called building your own framework. And the idea was that if you pick your own router and data fetching library, you're sort of building your own framework badly that's not as good as a real one. And I understand what they were trying to say. I don't think that was very helpful. And they still didn't recommend V. After some back and forth, they did finally end up with a rewrite of the docs page that now says it's building a React app without a framework. And they do actually list tools like V and Parcel as options, routers, data fetching libraries. So the current docs are actually in a good place. Like, I want to be very clear about that. But it took us way too long to get here. And I think that's why a lot of people are upset.

Similarly, server components. The announcement of server components was in late 2020. We had an announcement video and the RFC document that described what they were and some of the purpose. There's been lots of comments from the React team on social media. When Next released the app router, they documented how to use the app router. But there really hasn't been any information on server components in the official core React docs. And it took them a year to add anything.

And at this point there's just one page that's buried under the API reference section. It's really not even an API reference anyway. And I personally find that page very confusing, and it doesn't really explain what they are, when you would want to use them, how you would use them.

There have been some fantastic blog posts about server components. How many of you have read any of Dan Abramov's blog posts on server components in the last few weeks? If you haven't, please go look at it, overreacted.io. He's writing a ton of excellent posts on how to understand the mental model of server components. Vercell had a great intro blog post. Switz had a post saying, this is a new tool in the toolbox.

A lot of this info ought to be in the core documentation. And some of this is like, the community has assumed that the React team is telling us to use server components. Instead, the React team has literally actually said they are optional. You don't have to use them, but we think people misunderstand them. So we want to have people understand them first. That's the case. Shouldn't there be more actual documentation covering them? So time's almost up.

Some takeaways. Unfortunately, I think this Vercell invented server components to make money thing probably isn't going away. It's a shame. I wish we'd had better communication earlier to fix this, but I think we're kind of stuck with it.

The good news is React on the client isn't changing. Server components are optional. Use them or not. Your choice. There are a lot of ways that React is used. And I think that the docs should do a better job of trying to reflect that, but I recognize it's hard to balance how much info to give.

We did end up with docs that say if you're not using a framework, here are your options. It took us too long to get there. And I wish they gave us a little more info on making the tradeoffs in choices. I really wish that they would add more detail on server components in the docs. I'd love to see pages on use cases, tradeoffs, mental models, migration.

And the good news is we are seeing server components coming out in new frameworks. Parcel release, production-ready version, React router is in beta. As Tanner said, TanStack is going to release some functionality eventually. I have links to other blog posts and info in my slides, available on my blog. Hopefully, this has answered some questions, explained how we got here, and clarified some myths. Better communication between the team and the community is essential for understanding the tools' tradeoffs and usage.

Thank you. Great talk. Some hot takes, but as I mentioned, mild spicy. Even for the hotter takes, find him with a beer at the after party. Maybe get him extra drunk for the extra hot takes. We're going to jump into the audience questions. First question: Were there plans to make signals in React 19? It seems like it's not happening anymore. I don't think there's ever been an actual plan to officially add signals, definitely not for React 19. The compiler is intended to replace the concept of optimizing performance and re-rendering.

Yeah. Even for the hotter takes, find him with a beer at the after party. Maybe get him extra drunk for the extra hot takes. We're going to jump into the audience questions.

There were plans to make signals in React 19. Seems like it's not happening anymore. Maybe you have some ideas on when it can or will it ever happen. I don't think there's ever been an actual plan to officially add signals, and definitely not for React 19. The closest that I know of is Andrew Clark at least once said that we might someday add a signals primitive, but solely for the purpose of a compiler output piece, not even something that you are intended to write directly.

So I don't think it was ever intended to come out in 19, and I don't know of any concrete plans to add official signals support at this point. The compiler is intended to replace that concept of optimizing performance and re-rendering. That joke incoming. There was never a signal. I'll not continue. I'll not continue. Thank you.

Thank you. Oh, love these. Next question is from Benjamin. Tanner said earlier that he and other framework authors are waiting for better Vite support from React server components. How far out do you think React server components fully supported in Vite is? So I've been following this a little bit. Apparently the issue is that Vite itself does not have full support, whatever that means, for like separating the client and server module graphs at the same time, so it does the builds. There is... I think there's two pieces of work that have to be done. There has to be work in Vite itself to make the module graph piece possible, and I think that's happening with like the Vite 6 and roll down work, and then there needs to be a server components integration, and somebody from the community is working on a PR right now in the React repository to try to implement that Vite plus React server component piece. I have no idea on timelines. All I've done is skim the PRs. But it's something that is in progress somehow. The beauty of open source here on stage.

Next question is from our friend Pim. Isn't complaining or hating just a feature of the internet and social media? Shouldn't the number of users outweigh the screamers? What do you think? Social media is what it is. I mean, everybody... Social media is a loud signal in a lot of ways. It's overrated. But it's also where discussions happen. I would assume that the number of people quietly, happily using React who don't even know any of the things that I've just talked about outweighs the number of people who know about this, much less are screaming. But for me personally as a maintainer, I can only go off of the visible discussions and signals that I see when people say, like, hey, this piece of Redux doesn't work well, or I wish you'd add this feature. So it's a weighted discussion, but it's also what we have to go with. Yeah, in my experience also, like, even the audience members here, they are interested in new things and learning new things, but there's plenty of developers that outweigh all of us that just, oh, there's React 17 now? I'm still at 15. I don't care, it works. Legacy applications, been there for 10 years. If it works, it works. Right.

Next question. The reason I hate is because React is wildly used as a quick start in IT for beginners, and beginners usually don't like that frameworks are harder to learn. So there's a lot of you are probably familiar with the XKCD webcomic, and there's an XKCD for every situation. I've actually made the comparison recently. There was an XKCD that had, like, three different maps of the United States color coded, and they were saying that this map represents a certain bunch of people using this thing, and a certain bunch of people using this thing, and someone else pointed out that's just a map of the population of the United States. And so, like, as a number of people get big enough, it just is representative of everybody. The React community is huge. You have beginners and experts and spas and server side and all sorts of weird situations. It's a big community. It literally includes every possible set of users at this point. So you've got all the different levels. And it is true that a lot of beginners jump straight into React as well. Yeah, there's even a lot of people that kind of start JavaScript with React. They never learned... What's this HTML thing? Yeah, exactly, yeah.

We have time for a few more questions. What do you think of the take from Evan Yu and others that React server components is a bet that has never paid off? It's a good question. I saw that discussion thread on Twitter. There's a lot of ways to look at it. Server components are a real technology. People are actually using them. Dan has made very good cases in his blog posts that if you look at the problems with a REST API, a GraphQL, other ways to transfer data, that server components do provide a good technical some of those problems. I think it's also true that the rollout has been much longer than anyone, including the React team, would have expected. That the fact that they're still really only next as the only viable option has been a real problem. That a lot of people don't understand them. So it is very fair to say that the rollout has been slow and rocky and probably not what they would have wanted. I think where we're going to end up is that server components are not just the future of React or something that everyone has to adopt, but hopefully we will start to get an understanding of it's another tool, here's when it makes sense to use it, here's when it doesn't, and here are some of the tradeoffs of when and why I might choose it. I think that's what people need to start thinking about.

I think where we're going to end up is that server components are not just the future of React or something that everyone has to adopt, but hopefully we will start to get an understanding of it's another tool, here's when it makes sense to use it, here's when it doesn't, and here are some of the tradeoffs of when and why I might choose it. I think that's what people need to start thinking about. Good answer. I approve. Thank you.

It's always tradeoffs. Next question. React, more and more looks like Angular. Ooh, hot takes. Is it already a framework? Is moving the black box concept, etc.? What are your thoughts on it? In some ways React has always been a black box. One of the things I liked about the backbone library back in the day was I could put a break point, step into the event trigger, step out of the event trigger, look at the 1500 lines of library code and see exactly what it was doing. You really can't do that with React. It's too complicated. But part of the point of React is it does give you a consistent mental model. Set state, re-render, updates the tree, don't worry about how it does it. And sometimes that black box is a problem. You want to know what happens under the hood, and server components do add more layers of complexity to that. Sometimes it's justified. Sometimes it's like, this is a pain and I would just like something simpler. Something, something, tradeoffs. Well, then be a handyman next year.

That's all the time we have for Q&A, so please, everyone, give a warm round of applause for Mark. Thanks.