Introduction 🔗︎

Today, the state of React and its ecosystem is complicated and fractured, with a mixture of successes, skepticism, and contention.

On the positive side: React is the most widely used UI framework, and its concepts have influenced the rest of the JS ecosystem. The React team recently released React 19 after multiple years of development. This was a huge release, including official stable React Server Components support, the new use hook for handling promises, multiple new form integrations, and the removal of many long-deprecated and obsolete features.

However, I've observed and experienced that the React community has had a growing sense of frustrations and disagreements on where React is headed, how it's developed, and the recommended approaches for using React, as well as the interactions between the React team and the community. This in turn overlaps with dozens of different arguments that have ricocheted around the React and general web dev communities in the last few years, as well as specific technical concerns with how React works, comparisons with other similar JS frameworks, and how web apps should be built going forward.

What makes this a lot worse is that everyone is arguing and debating a different subset of these concerns, and many of the stated concerns are either false or outright FUD. Unfortunately, the arguments and fears have also been complicated by communications problems, self-inflicted marketing mis-steps, and lack of developer relations work from the React team itself. All of these intertwine heavily.

I've been involved in many related discussions on social media. I've written numerous comments both defending and critiquing the React team, explaining why they made certain decisions or how things actually happened, pushing for improvements to docs and explanations, and more.

Trying to cover just some some of these topics has required an extensive and detailed post (and I'm not even going to touch on the "is React bad / how does React compare to other tools?" topics, which are even further out of scope). But, having spent far too many hours debating and explaining, I feel the need to write a consolidated post that covers many of these topics together.

I've also presented a talk based on the topics in this post as well.

Goals 🔗︎

My goals for this post are:

• Give an overview of how React has developed over time
• Describe the forces driving React's development
• Clarify why and how React's recent development directions have happened, and explain some of the architectural decisions behind that work
• Clarify and dispel FUD and confusion regarding the motivations and intent behind React's development

Table of Contents 🔗︎

• Introduction
  • Goals
  • Background: My Role and Involvement in the React Community
  • Biases and Caveats
• A Brief History of React
• React's Relationship with Its Owners
  • Facebook / Meta
  • Vercel, Next, and React
• React Usage Patterns
  • Standard React Architectures
  • React Build Tool Usage
• Inside React Server Components
  • React Server Component Development and Vercel
  • RSCs, Frameworks, and Bundlers
• Community Concerns and Confusion
  • Concern: Vercel, Next, and React
  • Concern: React Only Works with Next
  • Concern: React Might Someday Stop Working in Client Apps
  • Concern: Why Is React Pushing Frameworks?
  • Concern: Server Component Docs and Explanations
• Takeaways from the Concerns
• Final Thoughts

Background: My Role and Involvement in the React Community 🔗︎

(aka "who am I, why should you trust my descriptions, and why should you care at all what my opinions are about this? 😄")

I am not and never was part of the actual React team. That said, I've been deeply involved with the React ecosystem since 2015, and it's fair to say I'm as much part of the "React community inner circle" as anyone outside of Meta or Vercel.

As a TL;DR:

• I've used React since 2015
• I maintain the Redux family of libraries, contributed to React, and been involved in React ecosystem discussions
• I've written numerous lengthy tutorials on React and Redux, and frequently speak on React and Redux
• I've been involved in moderating major React community sections most of that time

If you want the long version:

The point of listing those accomplishments is to establish that I have a long history and expertise around how React is developed, what's going on in the React community, what's happening inside the React team, and trying to help people learn React and Redux.

Biases and Caveats 🔗︎

Since this is the Internet, I'll try to preempt some concerns folks might have with me writing this.

I am most definitely not always right, and I'm definitely going to end up describing some things incorrectly due to limited knowledge, misunderstandings, or over-summarizing. That said, I'm writing this as a best-faith effort to describe history, motivations, and behaviors as honestly and accurately as I can.

in more detail:

So, with all those caveats stated, let's get going.

A Brief History of React 🔗︎

The early history is covered better in other places, including the React Documentary, but to provide some context for the rest of this post:

React was developed internally at Facebook around 2011-12, and open-sourced in 2013. It gathered a handful of external contributors, but until recently all actual development was done by the React core team inside of Facebook / Meta.

While the core concepts of React have always stayed the same (components, props, state, data flow), the implementation details, public APIs, and breadth of scope have shifted over time. React went from creating components with createClass, to ES6 class MyComponent extends React.Component, to function MyComponent(). React split from web-only to supporting mobile with React Native, then became customizable for other platforms such as WebGL (react-three-fiber) and CLI (ink) via a customizable react-reconciler core. The internals were completely rewritten to a new "Fiber" architecture, unlocking further architectural changes. Function components gained the ability to have state and side effects with the release of hooks in 2018.

For years, React pitched itself as a minimal UI-focused rendering library ("the 'V' in 'MVC'", "A JS library for building user interfaces"). Other frameworks like Angular or Ember were fully batteries included and had significant opinions about how to build and structure apps, but the React team left all of that up to the community. This led to a massive explosion in the ecosystem, both for better and worse. For any conceivable library category, there were dozens of competing tools solving overlapping problems: state management (Redux, Mobx, Zustand, ....), CSS and styles (Styled-Components, Emotion, CSS Modules, ....), data fetching (React Query, Apollo, SWR, RTK Query, ....), build tools (Babel, Webpack, ESBuild, Vite, Parcel, ....), and hundreds more.

React users have always had to begin a project by picking and choosing a set of libraries to solve the various use cases in their app. Additionally, React could be used in numerous ways: rendering every single element on the client side in a Single-Page App (SPA), rendering multiple subtrees attached to a server-rendered page, on the server as part of a Multi-Page App (MPA), and much more. The flexibility and variety of ecosystem options has been both a strength and a weakness. You get to choose the exact combination of tools you need for your project... but you also have to choose a combination of tools. That leads to decision fatigue, variations in project codebases, and constant changes in what tools are commonly used.

Overall, both the React library and the React team intentionally stayed unopinonated. They didn't want to play favorites with specific tools in the ecosystem, their time and attention was focused on building React itself, and they still viewed the scope of React as being somewhat narrow.

That ecosystem variety provided flexibility, but also complexity. This was especially true with build tools. Early React tutorials often spent multiple pages at the start explaining "here's how to configure Webpack and Babel", before you could even write your first React component. This led the React team to build a pre-packaged build tool configuration called Create React App. CRA was a CLI tool that could generate a new React project from a template, and built it with a a highly complex and customized Webpack + Babel config that was designed to make it simple to start a new project with a single command. That config was kept encapsulated as a black box, to hide the complexity out of sight.

React never had a built-in method for data fetching, so it was standard to use third-party libraries to fetch and cache data. React did have server rendering (SSR) capabilities early on, with methods to render React component trees to HTML as strings or streams, but those had to be used manually in server handlers. Over time, other prepackaged React build systems and "frameworks" became popular. Next.js also wrapped Webpack, but added more features like built-in server rendering with filesystem routing conventions and page-based data fetching. Gatsby generated sites from GraphQL-based data sources. Later, Remix added server "data loaders" and pushed for more HTML/platform-based usage conventions.

In late 2020, the React team announced a prototype for "React Server Components", an architectural approach that allowed async React components to run on the server and fetch data, then render child components and pass the children and data to React running on the client. This was intended to be a React-idiomatic solution to data fetching, and marked a significant shift from React's original "just the view on the client" historical pitch. During the development of RSCs, some of the React core team members left Meta and joined Vercel, creators of Next.js. They continued building out the initial RSC implementation, and worked with the Next dev team to rearchitect Next with the new "App Router", the first production implementation of RSCs.

The React team also spent 2020-2023 completely rewriting the React docs site from scratch. The new React docs at react.dev have a fantastic tutorial that walks through React's concepts step-by-step, with numerous in-page examples in runnable sandboxes, as well as much improved API reference pages.

When the new docs came out, the React team made a significant shift in how they recommended using React. Previously, the old React docs recommended starting with CRA if you were learning or building a client-side SPA, or pointed to a couple other frameworks like Next or Gatsby if you needed SSR or static sites. With the new docs, the React team changed their approach, and begin specifically and strongly recommending "you should use a framework to write React apps - they have routing, data fetching, and build capabilities built in". This also tied into the work to build RSCs. As part of this, the "Start a New React Project" page specifically warned against using React without a framework. Next was listed prominently on that docs page - ordered first on the "Frameworks" list, and mentioned as the only RSC implementation. React team members working at Vercel were quoted as saying "I think of the upcoming Next.js release as the 'real' React 18 release",

This tied into Create React App having effectively died around 2022. It had been unmaintained for some time prior. When a PR was filed recommending "mark CRA as deprecated and recommend Vite", Dan Abramov wrote an detailed comment explaining why CRA was created, problems with CRA, the rise of frameworks, and the shift of React's vision. In response, the React community collectively moved on from CRA, and the docs stopped recommending it, but nothing was done to officially mark it as "deprecated".

React's Relationship with Its Owners 🔗︎

Today, React's development work is sponsored and owned by two companies: Meta (formerly Facebook), and Vercel.

Facebook / Meta 🔗︎

From the beginning, React was a Facebook / Meta-owned project. The code was open-sourced, and anyone could submit a PR, but essentially all dev work was done by the React team at Meta.

This had significant impacts on how React was developed. React core team meetings were generally internal, as were any roadmaps. The React team would often prototype a half-dozen ideas for a problem space, then get app teams at Meta to try them out for vetting. By the time a new React feature was announced, it had gone through many internal iterations and been validated in actual usage. At the same time, the React team has also been responsible for supporting Meta's app teams with bug fixes and other support.

Despite this, the React team has had a fairly free hand in how they've developed the library. While React was created inside Facebook for Facebook usage, the React team itself has decided their roadmap and long-term vision for how the library should work. For the most part, React's actual development process and roadmap has been driven themselves, rather than by other influences inside Facebook / Meta. The That said, they also do have to justify their own performance and how projects benefit Meta.

Meta's own use of React is both widespread and distinct from how the community uses it. Meta has its own massive server infrastructure, including standard techniques for data fetching, routing, security, and more. Meta invented the GraphQL protocol, as well as the Relay GraphQL client layer, and frequently uses those with their React code. This means that Meta's React use rarely needs third-party libraries for routing, state management, styling, or other problems common to the rest of the community.

Vercel, Next, and React 🔗︎

Vercel is primarily a hosting platform for web apps. They mostly make money by having more people host apps on their platform, and charge for the convenience of easier usage. They have put massive amounts of engineering time into building the Next.js framework (as well as supporting other frameworks), and making it trivial to set up and deploy Next apps on Vercel infrastructure.

Vercel's CEO, Guillermo Rauch, is a long-time believer in React and its capabilities, as shown by his 2015 blog post Pure UI that talks about the power of React's rendering model.

In late 2021, React team lead Sebastian Markbage left Meta to join Vercel. This was the first instance of full-time React core team members working anywhere other than Meta. He was later joined by core team member Andrew Clark and former React org lead Tom Occhino. Sebastian and Andrew began working on implementing RSC functionality in React and designing the Next.js App Router, and Vercel had additional engineers begin contributing to React's core and server rendering capabilities.

Today, the React team is split between Meta and Vercel (with a majority still at Meta), plus a handful of team members or consistent contributors externally.

React Usage Patterns 🔗︎

Standard React Architectures 🔗︎

The React (and ReactDOM in particular) library itself does not care how you use it within a page. You can serve a near-empty HTML placeholder and render a React tree that generates the entire page contents on the client side, as a Single-Page App ("SPA"). You can use React for server rendering ("SSR"), where the server dynamically responds to each request, or static site generation ("SSG"), where you pre-generate static HTML pages at build time. You can serve a static or server-rendered HTML page using any language or framework (Python + Django, Ruby + Rails, PHP + WordPress, .NET, etc), and sprinkle bits of React throughout the page to add interactivity.

That said, by 2015 React was most commonly used for client-side SPA app architectures. As with everything, these had tradeoffs. They made it easier to generate the page contents (it's all React components), had faster user interactions (show a different component on click or route change instead of a full page refresh), and enabled richer app experiences. It didn't matter what the backend was (JS, Java, PHP, .NET, Python) - just expose a JSON API and fetch data. However, they also were slower to load the initial page bundle, and client-side routing could lead to uncanny interactions vs native browser behavior.

Data fetching on those clients was initially fairly manual, and required careful logic in side effects (such as triggering a fetch in componentDidMount to request data when a component first rendered). This was often done with Redux-based logic to handle the fetching and caching, although that code was typically full of boilerplate and complexity. Later, purpose-built data fetching libraries like React Query, Apollo, SWR, and RTK Query greatly simplified data fetching on the client, providing purpose-built useQuery hooks and prebuilt caching mechanisms.

Frameworks like Next and Remix provided standardized approaches to server-rendering React, with built-in filesystem routing conventions. However, there was no convention for server-based data fetching. Next invented a getServerSideProps mechanism to specify an async function for fetching alongside a component. Remix later invented "loaders" with a similar architecture. Neither of those felt particularly native to React.

This has led to a general mindset shift in the React ecosystem. There's more of a push for SSR-based architectures to improve page loading experiences and minimize the amount of JS needed for a page, as well as removing the need to use data fetching libraries on the client side. The React team has argued loudly against "waterfalls" in data fetching in order to improve page loading performance, and even client-side routers like React Router and TanStack Router offer ways to prefetch data at the route/page level rather than triggering fetches nested deep in the component tree.

React Build Tool Usage 🔗︎

It's worth looking at the download stats for several major React related build tools and frameworks to get a sense of usage scale in the ecosystem over time and today.

Loosely put, today the major options for tools in terms of mindshare and/or downloads are

• Next.js (SSR / SSG / RSC / SPA)
• Remix / React-Router v7 (SSR / SSG / SPA)
• Vite (SPA)
• Create React App (SPA)

It's also worth noting that Vite itself started off from the Vue ecosystem, but has become a standardized and widely used build tool with support for many different client-side frameworks. It also has a plugin ecosystem, including the plugin for React support, and has become the build tool of choice for various frameworks. That includes Remix / React-Router, which recently switched from using ESBuild internally to providing a Vite plugin to enable their SSR and SSG support.

Here's a graph of NPM downloads for these tools over the last few years, with ReactDOM for scale:

Until recently, the React docs also listed Gatsby as a recommended framework for web and Expo as the only recommended framework for React Native. Gatsby effectively died after being purchased by Netlify. Meanwhile, Astro is a more generic static-site-focused tool that supports many frameworks including React. Here's their download stats for comparison:

A few takeaways from those stats:

• Next.js is most widely used
• Vite's React plugin has grown steadily, and is now the second most widely used React-related build tool
• CRA usage peaked in mid-2023 and has been declining since, but still sees considerable usage
• Remix has strong word of mouth at this point, but is relatively smaller. React Router is very widely used, but the newer versions that support "framework mode" aren't as widely adopted yet.
• Gatsby never had anywhere near as much traction as Next, CRA, or Vite, and Astro recently surpassed it.
• Astro is not React-specific, but has roughly the same downloads as Remix does
• Vite + CRA together equal Next's usage, which shows that there's still a strong demand for plain SPA projects in the React ecosystem

Inside React Server Components 🔗︎

React Server Component Development and Vercel 🔗︎

The React team had experience with server-based data fetching from Meta's infrastructure, as well as automatically splitting JS bundles and lazy-loading code. However, unlike previous React feature development, they really couldn't design and prototype RSCs inside of Meta. After all, Meta already had its own server infra, so they couldn't prototype there and have app teams try it out.

It's worth noting that React Server Components were the React team's vision for how to write React apps in the future. As far as I know, this was not something that either Meta or Vercel came up with, or pushed the React team to build.

There had been intermittent discussion and complaints about "all of React's development is done by Meta employees" for years, and occasional comments of "it might be nice if there was a 'React Foundation', or folks outside Meta working directly on React". While I don't know the actual discussions involved, from the outside my understanding is that the React team approached Vercel and pitched their vision of RSCs, and Vercel agreed to be the new proving ground as RSCs were developed. This led to Sebastian Markbage (and later Andrew Clark) moving from Meta to Vercel, and the Next team spending huge amounts of time, money, and engineering effort to design and build the Next App Router as the first working implementation of RSCs.

As Dan Abramov described it:

The Vercel team has allocated many full-time engineer/years to implementing the things the React team wanted. That’s not to speak of directly taking the technical direction from the React team. Next.js was more or less rewritten from scratch.
The person designing Next.js now is the person who invented React Hooks. So if anything, it was more of a case of React team “taking over” the Next.js direction rather than “favouring” it.

There were efforts made to get other frameworks and companies involved in that process. Shopify's Hydrogen framework did some very early testing and feedback of RSCs, but eventually concluded it wasn't a good fit for them. The Remix team was asked several times if they'd like to be involved, but initially decided to focus on their own approaches.

As a result, Next became the first (and effectively still the only) "production-ready" RSC implementation. Today several other frameworks are working on RSC integration (including Parcel, React Router, and Waku), but Next's App Router is the only meaningful option for using RSCs today.

RSCs, Frameworks, and Bundlers 🔗︎

I commonly see questions like "why do RSCs require a bundler or framework? Why can't they just be built into React?".

React's existing server-rendering methods like renderToString and renderToPipeableStream could be called anywhere, such as an Express route handler. However, architecturally RSCs are much more complex. RSC functionality requires parsing code to look for the 'use client' and 'use server' directives, then transforming that code to insert the appropriate calls to register Client Components and server functions with the RSC core functionality. That requires tight integration with a bundler, so that it can correctly determine the full module graph for both server and client and compile them appropriately.

Additionally, while the React core implements the actual RSC functionality, and provides primitives for sending serialized components and data between client and server, it's up to a framework to actually call and use those primitives in the right place. This is primarily about integration with a router, so that the client app receives the right lazy-loaded Client Components, and calls the right endpoints with actions and data.

This also means that every framework's use and implementation of RSCs will be different. Next made very specific implementation decisions with the App Router for handling layouts and routing. Other frameworks and build tools like Waku, Parcel, and React Router are already making some very different design decisions.

Overall, RSCs are an unusual hybrid feature. The main functionality is built directly into the React core packages, but that functionality cannot be used until it is integrated into some kind of bundler/router/framework combination.

Community Concerns and Confusion 🔗︎

With all that history and context in mind, let's move on to answering (and hopefully clarifying or dispelling) several frequently repeated concerns that are either confused, FUD, or outright conspiracy theories.

Concern: Vercel, Next, and React 🔗︎

There's now an extremely common viewpoint that "Vercel is driving React development, with a goal of making more money hosting sites". As an example, this is the highest-upvoted comment from a Reddit thread earlier this year:

"Vercel has effectively taken over React and has a primary interest of pushing users to NextJS, deployed on Vercel, so Vercel shareholders get richer." https://www.reddit.com/r/react/comments/1iarj85/xbluesky_react_recently_feels_biased_against_vite/m9cb51h/

This ties into several other related points of concern:

• Next is recommended first in the React docs, and the Next App Router is also mentioned as the main example under "Which features make up the React team’s full-stack architecture vision?"
• Next is still the only production implementation of RSCs
• React team members have been quoted as saying that "This Next release is the real React 18"

I can see how people might come to this conclusion. Vercel hired several React team members, who are working on both React itself and Next. Timeline-wise, this did naturally coincide with the development of RSCs, and the new shift towards pushing users to use a framework... and look, the "obvious" framework is indeed Next! Meanwhile, Vercel has put massive amounts of money and effort into making Next easy to deploy and host on Vercel. It's possible to host Next elsewhere, but there's always been features that didn't work or things were hard to configure.

All that said, from everything I've seen, this take generally inverts the cause and effect, and is mostly FUD. Yes, of course Vercel has invested in efforts they think will end up making them money. But, per above, everything I've seen describing Seb and Andrew going to Vercel and the development process of RSCs says that it was the React team that drove this set of changes.

RSCs were the React team's vision. They couldn't effectively be prototyped and tested inside of Meta, so for the first time there was a need for some other sponsor to invest in the development and provide a setting to iterate on the design. I don't know the specifics of how it happened, but my understanding is that the React team convinced Vercel to buy into the React team's vision, and let them drive rearchitecting Next to design the App Router approach that would match that vision.

There certainly has been some amount of "Next needs this"-type changes to React. I know I saw several PRs getting merged in the React repo the night before one of the NextConfs that had a significant Next version announcement (possibly the stable App Router in 13.4?). But, it was still the React team members doing that work.

At this point, the React team is split. The majority are still at Meta, but the members at Vercel are key to the core implementation. I've read that "React team meetings are still the same as always", but I wouldn't be surprised if there's some additional complexity from splitting that way.

All that said, I do think that "Vercel took over React" is wrong, and it's more like "part of React core migrated to Vercel and convinced Vercel to align with React's vision". I also don't see evidence that "Vercel" is driving the design of React, or that the emphasis on frameworks and RSCs is with the specific intent to make Vercel money.

Concern: React Only Works with Next 🔗︎

I've seen multiple comments online with people saying, either seriously or wonderingly, that "React only works with Next now".

This is easily refuted. Even just looking at the "Start a New React Project" page shows other frameworks that are not Next, as well as the somewhat infamous "Can I use React without a framework?" section.

Clearly this is a complete misunderstanding of how React works.

But, it also says something about how confused the messaging around React, "use frameworks", and Vercel's influence has become.

I'll tack on the very related "Should I use Next or React?" question, which also pops up frequently. The literal reading is that "Next" and "React" are different things. This is also clearly wrong. Next is a framework that uses the React libraries. It's a superset, not a competitor. I assume that what most people mean is "should I use Next, or a client-side SPA like CRA or Vite?", but they don't have the vocabulary to state that clearly.

Again, that shows how much confusion there is around the boundaries here.

Concern: React Might Someday Stop Working in Client Apps 🔗︎

I've seen this one come up repeatedly too. The concern is that "if the React team is putting this much emphasis and work into features that require a server, does that mean that someday the client-side functionality might change or go away?".

I can understand why people have this fear. It's driven by the huge shift in tone and emphasis from the React team, as well as the amount of effort they've put into server-side functionality.

However, it's also clearly impossible that this will ever happen. React's client rendering functionality will not ever go away! Just the fact that Meta itself has millions of lines of existing React code shows that. On top of that, the React team has always been extremely good about code-level backwards compatibility - describing breaking changes, keeping around deprecated features for years before finally removing them, providing migration guides and codemods.

It's also worth noting that many of the features in React 19 and 19.1 are client-only. If anything, the community has over-estimated the amount of effort put into server-side functionality, and missed the amount of effort put into client-side features.

Concern: Why Is React Pushing Frameworks? 🔗︎

And that leads us to our next argument: why is the React team so dead-set on making all React users use frameworks, to the point of telling people they're doing it wrong otherwise?

This is a concern that I have a lot more sympathy and agreement for. I just said that I don't think they're saying "use frameworks" with a goal of "get people using Next and hosting on Vercel", so what's the reasoning?

React Team Opinions on Frameworks 🔗︎

Andrew Clark's tweets from Jan 2023 state the intent pretty clearly:

If you use React, you should be using a React framework. If your existing app doesn't use a framework, you should incrementally migrate to one. If you're creating a new React project, you should use a framework from the beginning

Your React framework of choice should have built-in solutions for data fetching, routing, and server rendering. Frameworks don't treat these as independent concerns — they provide deeply integrated solutions that are easy to use and result in excellent performance out of the box.

If you choose to forgo a framework, what you're really choosing is to build your own bespoke framework, one that's likely much worse than what you'd get off the shelf. Even if you think your bespoke framework is better than the alternatives today, will that be true in a year?

It takes lots of time and energy to keep up with the state of the art. Are you ready to become a framework maintainer? Or are there better things you should be doing with your time?

The main thing that has changed since then is that the frameworks got really, really good. It used to be that plain React + Webpack was as good or better than all-in-one frameworks. IMO, that's no longer true

The question isn't whether it's possible to build a React app without using a framework. You'll always have that option. The question is whether your homegrown set up can compete with the industry leaders — on features, on performance, on DX. The bar is constantly being raised.

Similarly, in Dan Abramov's explanation of why they were considering CRA deprecated:

Create React App solved only one side of the problem. It provided a good (at the time!) development experience, but it didn't impose enough structure to help you leverage the strong sides of the web for a good user experience. You could try to solve these problems yourself, but that would involve "ejecting" and significantly customizing your setup, which defeated the point of Create React App. Every truly efficient React setup was custom, different, and unachievable with Create React App.

These user experience problems are not specific to Create React App. They are not even specific to React. For example, apps created from the Vite homepage templates for Preact, Vue, Lit, and Svelte suffer from all of the same problems. These problems are inherent to purely client-side apps with no static site generation (SSG) or server-side rendering (SSR).

If you build entire apps with React, being able to use SSG/SSR is important. The lack of support for them in Create React App is glaring. But it's not the only area where Create React App is behind

React itself is only a library. It does not dictate how to do routing or data fetching. Neither does Create React App. Unfortunately, this means that neither React alone nor Create React App, as originally designed, can solve these problems. As you can see, this isn't about a single missing feature. These features — server-side rendering and static generation, data fetching, bundling, and routing — are interconnected.

Times changed. Now it's getting increasingly difficult to recommend a solution where you are locked into not having these features. Even if you don't use all of them immediately, they should be available for you when you need them. You shouldn't have to migrate to a different template and restructure all of your code to take advantage of them. Similarly, not all data fetching or code splitting needs to be route-based. But it's a good default that should be available to most React apps.

I've also had conversations with the React team where they directly told me that they have heard many of the external complaints about React apps having bad loading times and overall poor performance. So, the frameworks emphasis is a direct response to that, with the goal of getting more apps to have decent performance by default.

Based on that, we can summarize the React team's stance as:

• Frameworks have built-in approaches for data fetching, routing, and server rendering, that are designed to work together
• Those are all provided out of the box, so you don't have to spend time picking and choosing pieces (that may not work well together)
• Frameworks lead to better performance by default, due to build setups and better data fetching patterns
• Additionally, React Server Components require integration into a framework to work properly
• Those concerns are critical to how the React team feels React should be used today

In other words, it's a combination of an ideological stance, a belief that "this will save you time and effort", and also a belief that "most React apps follow similar patterns and need similar solutions".

Frameworks, SSR, and SPAs 🔗︎

Also, note the specific mention of "server rendering". In general, both the React team and other key members of the ecosystem (such as Ryan Florence and Michael Jackson of Remix / React Router) have put heavy emphasis on the need to do server rendering to avoid "waterfalls" of data fetching on the client (such as <List> fetching a set of items, rendering its children, <ListItem> doing its own fetch after mount, etc ). Frameworks like Next and Remix have been specifically designed to support server rendering out of the box.

The justifications for SSR around "faster initial page loads", "less JS on the client", and "avoiding waterfalls" all make reasonable sense. I also agree that client-side SPAs have been used in a lot of places they probably shouldn't have been (same as with Redux, really), and that it can make sense to start with a framework even if you don't need all the functionality right away, so that you can take advantage of those features when you decide you need them.

I'll note that Next and Remix do have "SPA / export" modes that just output static JS/HTML assets, so it is possible to use them to create a purely client-side app with no Node server process needed. However, those are not the defaults, and I would assume most of the community is unaware that is even an option.

Framework Push Lacks Nuance 🔗︎

Given all that: I understand why the React team has decided to recommend frameworks as a default. I think it's a reasonable opinion, and valid intentions to improve the average React app.

But I also feel that the "recommendation" has turned into an overly-broad prescription that doesn't give enough credit to the variety of ways React is used in practice throughout the ecosystem.

There's many good reasons to use a full-stack React framework, but also plenty of reasons not to:

• Frameworks add many additional features and functionality, but that's also added complexity to learn, making them less suitable for beginners that are just trying to get a handle on how to use React at all.
• The added complexity can also be a trap that leads to confusion, such as accidentally using Context or hooks in Server Components (which throws errors)
• Many companies may not be running JS backends, and may even have rules and restrictions against that
• Frameworks with server functionality do require specific hosting to run, whereas a pure SPA can be trivially hosted anywhere that serves static HTML and JS (including Github Pages and Amazon S3)
• While the need to pick and choose your libraries has often been a source of frustration for React users, it does enable customizing projects to meet your specific needs. Opinionated frameworks remove the need to make most of those decisions, but can also limit your ability to customize behavior later.
• The emphasis on "server rendering" clearly helps some kinds of apps, but not all - there are plenty of apps that only need to live on the client side.

Docs Recommendations Matter 🔗︎

The React team has said that "the docs are aimed at beginners", so they want to keep the list of recommended tools and options fairly simple to avoid confusion. This is a very reasonable stance.

They've also said that "anyone who's experienced enough to know to use Vite doesn't need to see it listed in the docs anyway" (paraphrased). That's technically true.

However, it's not just beginners that read the docs, and what the docs recommend does have an influence as a stamp of official approval. That's a large part of why the React team had historically avoided recommending specific libraries or techniques.

If we refer back to the framework / build tool usage stats, today Vite React and CRA usage outweighs Next, and it's clear that SPA usage is still at least half of the React ecosystem. The docs recommendations ought to reflect that usage.

Dismissal of the Ecosystem 🔗︎

When the new React docs came out, the only mention of non-framework options was an expandable details section labeled "Can I Use React Without A Framework?", with several paragraphs saying "yes, but we don't think it's a good idea".

And buried at the end of that section was this statement:

If you’re still not convinced, or your app has unusual constraints not served well by these frameworks and you’d like to roll your own custom setup, we can’t stop you—go for it! Grab react and react-dom from npm, set up your custom build process with a bundler like Vite or Parcel, and add other tools as you need them for routing, static generation or server-side rendering, and more.

So, not only did the new setup page not list Create React App, but the closest equivalent tool (Vite) wasn't even listed as a meaningful option in the outer section of the page. Instead, it was buried as a mere mention at the bottom of this expandable explanation.

I'd also say that the phrase "unusual constraints" is very poor here. SPAs had been the standard architecture in the React community since the beginning. CRA and Vite are commonly used. How is building an SPA suddenly an "unusual constraint"? There are many reasons to want an SPA, from architectural to business reasons to simplicity of learning. Those aren't "unusual" - those are all common use cases.

And beyond that... note the phrase "we can't stop you". That phrase stuck out to many people as poor phrasing that came across as dismissive of the community, and an indication that the React team was relegating SPAs as an unsupported approach, overnight.

As an example of this, here's a quote from a debate about the "frameworks" emphasis in the docs from mid-2023:

In some ways React is having its AngularJS moment. Teams are using this time of instability and uncertainty to shop around for alternatives. We certainly are.
React is great. It's the strong server & framework alignment tone change that's concerning to communities. The server-neutral aspects that made it what it is today suddenly feel second-class. (SPA routers & loaders are a mess & underserved!)
It's not about React or Vite. It's the ecosystem. It's painful to realize that React won't encourage the traditional "non-framework" as strongly as the "new ways". The "React without a framework" section is tucked away in the docs and depressing.
As a non-Node backend company we see those docs as a sign that we don't align with React's primary direction anymore. Framework endorsements are a big enough change to cause teams to reevaluate entire stacks. React is great, but its influence has limits on architecture. It's not "wrong" for React to go this direction. But we can't pretend that non-Framework React usage is now a second-class concern. How long until it's not a viable option? It's uncomfortable. So, we look for safer bets. What would you recommend a non-node backend company do?
https://x.com/vyrotek/status/1649097699696992256

Fixing the Docs Recommendations 🔗︎

When the React team finally announced CRA as deprecated in early 2025 (after I helped push them to fix it and make that deprecation official), the initial docs update included a new "Building Your Own Framework" page. The concept was that picking your own router and data fetching approach was equivalent to cobbling together a bespoke framework that wouldn't be as good as a "real" framework.

I understand the mental model here, but this is also rather dismissive of both the way the ecosystem had been building apps, and of people's ability to choose their own options.

As an example, Vite creator Evan You posted his take:

it feels the React team's hesitance on Vite (and build tooling in general) is how it aligns with their vision of React (i.e. RSC being the recommended paradigm), and how much influence / connection they have with the said tools to make sure the integration works as they designed and can adapt to design iterations. ...
I apologize if this is not what the React team is thinking, but it’s my honest guess because I am just as puzzled as many React users by what took it so long for Vite to be better acknowledged as a recommended tool.

I ended up filing a draft PR to revamp the setup pages to improve the tone, add nuance in recommending project setup tools, and offer some architectural guidance on choosing approaches. That PR got closed, but the React team did cherry-pick some of the ideas and phrasing over into a new PR.

Ultimately, they ended up with a "Building a React App from Scratch" setup page that is fairly reasonable. It recognizes SPAs and picking your own tools as a valid approach, lists Vite / Parcel / RSPack as suggested build tools, points to some routers and data fetching libraries, and provides some actual useful guidance to users trying to set up a project.

It's unfortunate that it took us multiple years to get the docs to that point :( Much of the confusion and angst could have been avoided if the React team had applied some of the community-recommended phrasing changes soon after the new docs were released.

Concern: Server Component Docs and Explanations 🔗︎

One of the big pain points and sources of confusion around React Server Components is that official docs and info has been scattered and unfortunately lacking.

The React team originally announced RSCs with an explanation video in Dec 2020, and that was followed by a lengthy and detailed RFC doc explaining RFCs. These did do a decent job of explaining the background and primary motivations.

However, the development process of RSCs, combined with the fact that it's up to frameworks to implement design choices, meant that the actual React docs have never meaningfully documented RSCs.

It took almost 2 years for Next 13.0 to come out with the first official beta release of RSCs in the form of the new App Router, and another 6 months until Next 13.4 officially declared the App Router as "stable" and ready for production in May 2023. Vercel and Next have a sizeable devrel team, and by the time of Next 13.4's release, they had done a sizeable rewrite of the Next docs to cover the then-new App Router, available as "beta" docs. That included some docs pages that talked about using RSCs, under the "Data Fetching" category, as well as later detailed blog posts like Understanding React Server Components. These were excellent resources, with very helpful explanations of architecture and concepts.

And yet, even though the RSC functionality was part of React itself, the React docs didn't have any information on RSCs. Not "What Are RSCs", not "How Do I Use an RSC", and definitely not "How Do I Integrate My Library With RSCs". Vercel's team did a good job documenting their actual product and some of the overlap with React, but it was extremely confusing to people why there was no info or explanations about RSCs in the actual React docs themselves (which, timeline-wise, had just officially launched a couple months earlier).

There's been lots of discussion from individual React team members on social media, responding to questions, arguing in favor of RSCs as a concept, and trying to flesh out sales pitches for RSCs. But as of today, the only official core docs page on RSCs is API Reference: Server Components. This page is, honestly, confusing and not particularly helpful. It's definitely not an "API reference" content-wise, and the content doesn't have any real context introducing RSCs or explaining when and how to use them - it's a grab bag of random topics.

There have been a number of excellent external blog posts explaining various aspects of RSCs:

• Dan Abramov has written numerous fantastic posts explaining the mental model of RSCs and the problems they solve.
• Vercel published a great "Understanding React Server Components" intro blog post
• Daniel Saewitz wrote Server Components Give You Optionality explaining how they're an addition to your toolbox

This is the kind of information that should be in the React core docs - explanations of RSC concepts and why you might want to use them, independent of how any specific framework implemented RSCs.

Related to this: the community has taken away the idea that "RSCs are the future of React", and that "the React team wants us to use RSCs all the time everywhere". In reality, I've seen React team members explicitly say on social media that "RSCs are optional, we just want people to understand them properly". Given that confusion, it seems like making that point specifically in the docs is important.

Personally, I'd like to see an entire section on RSCs added to the React core docs, with pages like:

• "Intro to RSCs"
• Mental model
• Use cases / when to choose RSCs
• Technical data flow / architecture
• Adoption / migration
• FAQ
• Framework implementor's guide

Having those docs pages would not make all the questions go away. Lots of people don't even read the docs in the first place :) But having those topics covered officially would make it visible, and it would act as a resource that could be used to answer these questions whenever they come up on social media.

Takeaways from the Concerns 🔗︎

I don't think it's the React team's job to spend all their time dispelling FUD on the internet. Lots of people will have opinions, many of them will be differing or wrong.

That said, it's striking that there's a strongly consistent theme of "all of this emphasis on frameworks and servers is being forced on us to make Vercel money". It's wrong, but there's enough circumstantial evidence to lead people to that belief, and the React team's actions and statements have to some extent reinforced that belief instead of disproving it. Unfortunately, at this point it seems to be a meme that is permanently embedded in the community, and I don't think we're going to make it go away.

It's also genuinely concerning that users are worried or assuming potential problems with how React might change or stop working in the future, especially when those concerns are clearly wrong and easily disprovable. You can continue to use React exactly as you always have, and all of the RSC / server functionality is entirely additive and optional.

The internet being what it is, even a blog post on the actual React blog that explicitly refuted those statements wouldn't change a lot of people's minds. But it does feel like maybe some of the worst of that could have been avoided with better developer relations work from the React org - more time spent reading the concerns, acknowledging that they exist and understanding where they're coming from, and trying clarify and answer them.

I do feel that the push for "frameworks" has been genuinely well intentioned, but also too broad and ultimately dismissive of the variety of usage patterns in the ecosystem. Yes, it's hard to write docs and provide recommendations that offer nuance, and it's understandable to try to keep things simple to target beginners and nudge the ecosystem in a better direction... but part of being a maintainer is recognizing and supporting the variety of ways your tools are used by the community.

We did finally end up with a reasonable set of React project setup docs that have useful instructions on setting up a project yourself and recognize that as a valid approach. It's unfortunate that it took us years to get to that point, and that the React team essentially ignored the very vocal feedback from the community on how to improve that section of the docs. The docs would still really benefit from more advice on how to approach choosing an appropriate tool and architecture for your app.

Similarly, the lack of official core docs info on RSC concepts and tradeoffs has contributed to the confusion. I strongly feel that covering those topics would be a huge improvement in people's understanding of RSCs and the resulting discourse.

Final Thoughts 🔗︎

This hopefully answers a lot of questions about how and why React has developed the way it has, what the influences are on React's development process, the main goals of the React team, and where React usage patterns stand today.

I also hope I've been able to dispel some of the confusion and FUD around the React team's motivations and reasons for pushing in specific directions. It's fine if people disagree with the technical directions, or decide that they don't need React Server Components or to migrate to a larger framework. But the React team's intentions are valid and genuine here.

It's really hard to maintain widely-used libraries and satisfy the variety of needs and usage patterns in the community. I do think the React team has done a good job overall. Unfortunately, the places where the communications have been poor and the issues with the docs have been a big contributing factor to a lot of the frustration and angst in the community.

Going forward, I'm hopeful that we can find ways to improve that communication, and maybe even get more of the community involved in improving the docs.