React Framework Shift
For a long time, React was just a UI library. It didn't tell you how to structure your app, where to put your data fetching, or what build tools to use. That was its appeal—it was flexible, adaptable, and worked in all sorts of environments. But recently, it feels like React is shifting away from being a standalone library and becoming more of an API description, something that needs a larger framework around it to be usable.
This became especially noticeable with the introduction of Suspense for data fetching, Server Components and Server Actions. These features were released with tight integration into frameworks like Next.js and Remix, without any documentation on how they could be used elsewhere. If you wanted to take advantage of them outside of those frameworks, you were on your own. This alone wouldn't be too concerning—after all, some features do need a backend to function—but it's part of a broader trend where React is becoming more and more intertwined with specific tools.
"So even long term, we expect that libraries and frameworks will play a crucial role in the React ecosystem."
The deprecation of Create React App (CRA) reinforced this shift. CRA wasn't perfect, and it was outdated, but it was a common and straightforward way for beginners to start a React project. With its deprecation, React's official documentation now suggests using a framework first. If you don't want to, they recommend Vite, but even in that section, they push React Router v7 as a "framework." The wording in these recommendations makes it clear that React's identity as a standalone UI library is fading.
"React recommends using a framework that integrates with build tools like Vite for new projects."
This evolution of React isn't necessarily bad. Frameworks provide powerful abstractions, making it easier to build complete applications without worrying about the low-level details. But at the same time, it creates a more fragmented landscape where different frameworks interpret React in their own ways. We're already seeing this with frameworks like Hono, that are React-compatible but obviously reimplement parts of it differently, even if in subtle ways.
Hono components look like React ones, they use similarly named hooks, but they're ultimately their own thing.
What's missing in all this is a clear, solidified identity for React itself. The official documentation should emphasize React as a UI library first, with guidance on how to set up a project using just React, without a framework. Frameworks should be positioned as optional tools that add additional functionality—not as the default way to use React.
If this trajectory continues, we could end up in a world where "React" no longer refers to a specific library, but instead to a collection of loosely related ideas that change depending on the framework you use. That's a future where React is harder to learn, harder to use independently, and more fragmented than ever.
Update (2025-02-18)
The React team has updated the Sunsetting CRA post to include a How to Migrate to a Build Tool section. They also added a Build a React App From Scratch guide, replacing the previous "Build a React Framework From Scratch" document.
While this is still unsatisfactory to me, based on the language that steers people away from using React as a standalone library, it's a step in the right direction.
If your app has unusual constraints, or you prefer to solve these problems by building your own framework, or you just want to learn how react works from scratch, you can roll your own custom setup with React using Vite, Parcel or Rsbuild.