The State of React and the Community in 2025

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

FAQ

React server components allow React components to run on the server and manage data asynchronously. They are controversial because of misconceptions about their origins and their association with Vercel. They are a React concept, not exclusive to any framework.

Confusion arises from a lack of communication and clarity from the React team about new features and their intended use. The push towards frameworks and server components has also caused debate within the community.

Vercel collaborated with the React team to test and implement server components. Although there are misconceptions, server components were initially a React team idea, and Vercel helped in the development and alpha testing.

The React team believes frameworks provide built-in solutions for bundling, routing, and server-side rendering, which can improve app performance and reduce complexity for developers. They recommend frameworks to offer a better starting point for new projects.

Create React App became unmaintained and was eventually deprecated. It was replaced by modern tools like Vite and frameworks such as Next.js and Remix, which offer more comprehensive solutions for building React applications.

The React documentation underwent a major update to improve tutorials and emphasize function components. It faced criticism for not mentioning tools like Vite but has since been updated to include more options and reflect different use cases.

No, server components are optional in React. They offer a new way to handle data and reduce bundle sizes but are not required for React applications.

Mark Erickson is a senior engineer at Replay, a moderator for React communities, a Redux maintainer, and known for his Simpsons avatar. He is actively involved in the React community and shares insights through blog posts and podcasts.

In 2025, React is extremely successful and widely used, but it is also facing community frustrations regarding feature decisions and communication from the React team. The ecosystem is complex with debates over the use of server components and frameworks.

While the rollout has been slow, server components are gaining adoption and are expected to become another tool in the React ecosystem. They are not mandatory, but offer benefits in specific use cases.

Mark Erikson
Mark Erikson
29 min
13 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Mark Erickson discusses the state of React in 2025, React community debates on React's direction and misconceptions, React's shift towards client-side frameworks and SSR emphasis, React's feature development process at Meta and Vercel, controversy around Vercel's server components involvement, tight relationship between React and Next, React team's emphasis on frameworks for app performance, critique of React's heavy-handed framework recommendation, React team's delay in adding VEET as a recommended tool, challenges with server components' origins and communication, no official signals support planned for React 19, social media impact on React development decisions, React community diversity and server components usage insights, React's evolving black box concept and tradeoffs discussed.

1. Mark Erickson on React in 2025

Short description:

Mark Erickson discusses the state of React in 2025, highlighting its complexities and the community's mixed reactions to React's direction and decisions.

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.

2. React Community Discussions

Short description:

React community debates on React's direction and misconceptions. Exploring React's history, development influences, and community disconnects.

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.

3. React Evolution: SSR and Tooling Shift

Short description:

React's shift towards client-side frameworks and SSR emphasis. Create React App deprecated. Shift to SSR mindset. Common tools: Next, Remix, React Router V7, Vite's React plug-in. React Server Components introduced in 2020.

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.

4. React Feature Development at Meta and Vercel

Short description:

React's feature development process at meta. Vercel's role in React development. Split in React team between meta and Vercel. Issues with Next's server components.

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.

5. React Documentation and Vercel Controversy

Short description:

Absence of server components in React docs. New docs emphasize frameworks like Next, Gatsby. Controversy around Vercel's server components involvement.

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.

6. React Server Components and Future Impact

Short description:

Tight relationship between React and Next. Server components not Vercel's invention. React feature, not exclusive to Next. Server components tie into bundler for module graph. React continues to work on the client side, server components optional.

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.

7. React Team's Framework Emphasis

Short description:

CSS and JS libraries affected in server components. React team emphasizes frameworks for app performance. Frameworks as default for better performance, despite critique. React's push for frameworks simplifies development, lacks nuance. React's focus on simplicity in docs sparks diversity discussions.

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.

8. React's Framework Recommendation Critique

Short description:

Valid critique of React's heavy-handed framework recommendation. Lack of nuance in promoting frameworks over diversity. Concerns about beginners jumping straight to complex frameworks. Dismissive tone towards varied React usage. React's focus on simplicity overlooks ecosystem diversity.

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.

9. React's Documentation Challenges

Short description:

React team's delay in adding VEET as a recommended tool raises suspicions. Balancing simplicity for beginners with reflecting ecosystem diversity. Issues with building recommendations and the delayed inclusion of tools like V and Parcel. Delayed updates to documentation causing frustration within the community.

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.

10. React's Server Components Documentation

Short description:

React's lack of detailed documentation on server components and their optional nature. Community's need for more information and clarification on server components. Importance of core documentation covering server components and their usage.

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.

11. React's Server Components Challenges

Short description:

Challenges with server components' origins and communication. React client stability and optional server components. Need for more detailed documentation on server components and their usage.

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.

QnA

Server Components in New Frameworks

Short description:

Server components in new frameworks. Communication and community understanding are key. No official signals support planned for React 19.

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.

React 19 Signals Support

Short description:

No official signals support planned for React 19. Andrew Clark mentioned a signals primitive for compiler output only. No concrete plans for official signals support.

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.

React Server Components and Social Media Impact

Short description:

React server components support in Vite is in progress. Social media discussions and user feedback influence React development decisions.

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.

React Community Diversity and Server Components

Short description:

React community diversity and React server components usage insights.

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.

React's Black Box Evolution and Q&A Closure

Short description:

Server components as a versatile tool in React. React's evolving black box concept and tradeoffs discussed. Q&A closure with applause for Mark.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.