React and the Community in 2025, Part 1: Development History ...

**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. … ... Most of the React apps I've worked on have been internal tools with limited distribution, and mostly "desktop-style apps in a browser" - in other words, true SPAs without even any routing or CRUD-type behavior. I did work on … *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. ... *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. ... 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. … *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.