Introduction 🔗︎

As we start 2025, the state of React and its ecosystem is complicated and fractured, with a mixture of successes, skepticism, and contention.

On the positive side, 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 exacerbated by numerous self-inflicted missteps, communications problems, 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 most of these topics has required a post far longer than even I usually write (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.

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

This is followed by Part 2: React Team Interactions with the Community, which is an extensive dive into the history of the React team's interactions with the community, reasons why those interactions have often produced frustration and concerns, and some suggestions to improve communications and the relationship between the React team and the community going forward.

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, very little of React's actual development process and roadmap has been driven by other influences inside Facebook / Meta. The React team itself has decided their roadmap and long-term vision for how the library should work.

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. It's reasonable to shorthand their business model as "a reseller over AWS" - in other words, 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 (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:

The React docs also currently list Gatsby as a recommended framework for web and Expo as the only recommended framework for React Native. That said, 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 a relatively smaller
• 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.

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 currently still the only) "production-ready" RSC implementation. Today several other frameworks are experimenting with RSC integration, 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.

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 and Parcel 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 just within the last couple days:

"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 "Bleeding Edge Frameworks"
• 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 Seb convinced Vercel to buy into the React team's vision, and let him 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: 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?

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".

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.

That said, it also feels like this switch from "the React team has no opinions on how you build your apps", to "You should always use a full framework" is too much of a pendulum swing.

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.

Given all that: I understand why the React team has decided to recommend frameworks as a default.

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.

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.

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". Even if that's wrong, there's enough circumstantial evidence to lead people to that belief, and the React team's actions and statements are reinforcing that belief instead of disproving it.

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.

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, which is a point I'll get into later.

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.

With that information as background, it sets the stage for Part 2: React Team Interactions with the Community, where we'll look at the long and complicated history of interactions between the React team and the community, and I'll offer suggestions to hopefully improve the communication and interactions going forward.

This is a post in the React and the Community in 2025 series. Other posts in this series:

• Feb 10, 2025 - React and the Community in 2025, Part 2: React Team Interactions with the Community
• Feb 10, 2025 - React and the Community in 2025, Part 1: Development History and Clarifying Community Concerns