Since leaving my last job in March 2025, I have avoided using React for website development. I am using vanilla JavaScript, CSS, and HTML with some third party libraries and a small framework I developed called places.js. These are the main website projects I am working on:

• createthirdplaces.org/: The goals of this website is to promote accessible public spaces where people interact in person. It uses Kelp for styling. There is some use of places.js or highlight.js with it’s own styling for code examples. Most pages on the site run with no Javascript aside from code for blocking bot scraping.
• dmvboardgames.com. This site is designed to support the mission of createthirdplaces.org by supporting public board game events in the DC area. It uses Kelp for styling and places.js for interactive parts of the website.
• This website, which uses WordPress. I set up WordPress for this site more than 10 years ago, and I haven’t seen a strong reason to move towards another tool.

Source code for createthirdplaces.org and dmvboardgames.com can be seen here.

From looking through job postings and source code from open source projects, React is still widely used. Recent https://w3techs.com/technologies/overview/javascript_library from multiple sources confirms that it is one of the most popular JavaScript libraries. Despite this popularity, I think React is a flawed tool and that there are better choices out there.

Most sites are designed to render static content, and adding React is unnecessary complexity. For sites where interactivity is needed, I think React has problems that lead to an overly complex code base with UI performance issues.

1. Gaps in functionality around efficient cross-component state management, page routing, and API data fetching

Finding dependencies to address functionality gaps in React can be a time-consuming process. Due to the way React works, simply applying vanilla JavaScript patterns is probably not going to be a viable option. For example, I was once tasked with evaluating state management options for a React application, and the evaluation took two weeks.

First of all, there were a variety of state management tools available including MobX, Jotai, Redux Toolkit, and Zustand. Improved state management with more efficient uses of the useContext, useReducer, and useState hooks was also considered.

The project also had other dependencies used to address gaps in functionality, and it was using an old version of React. This version was not compatible with the latest version of some state management libraries. When I tried upgrading to the latest version of React, I ran into errors with some of the dependencies that required version upgrades and some code changes. Also,one of the dependencies was incompatible with the latest version of React, and adding a replacement was gong to take a while.

2. Quality of official documentation

As of June 2026, the official documentation recommends using React with a full-stack framework. Not every website requires custom server-side code, and adding it will likely lead to unnecessary complexity. While the documentation mentions that a full-stack framework can be configured to only support client-side rendering, the configuration is still added complexity.

There are better ways of implementing the functionality provided by a full stack framework. If the goal is to fetch data and render web pages on the server, I think PHP is a better choice due to the ease of getting started and quality of documentation. Otherwise, I think it’s better to run a separate server in the language of your choice. This ensures that complexity on the frontend and backend is isolated, which improves long-term maintainability of a codebase.

The documentation recommends one of three frameworks, Next.js, React Router, and Expo. I don’t think any of these frameworks are worth using.

Next.js is the top recommendation. It has features designed to rely on server-side logic, and they do not work with client side rendering.

The next recommendation, React Router suggests configuring a website as a single page application(SPA). I don’t think a website should be created as a SPA. Using a SPA can make the user experience slightly better due to faster loading speed after the initial page load. However, creating a high quality SPA will add a significant amount of complexity and time needed to maintain code. Complexity will come from the code necessary to implement SPA functionality in addition to the fact that complexity on one area of the website is less likely to be isolated.

It doesn’t appear that client side rendering is a limitation for Remix, which is the third recommendation. However, the documentation includes functionality that is unnecessary for a website.

The documentation is also hard to follow in some pages. One example is the fact that the https://react.dev/reference/react lists sections for server APIs and static APIs. Both of the them are used to render React components to HTML and include text saying “Most of your components don’t need to import or use them”. Meanwhile, these sections are also a distraction from documentation on hooks and built-in components that are more relevant.

3. API complexity

The React API has become very large, and it’s hard to know when certain functionality should be used. Every React application I worked on has turned into an unmaintainable mess of spaghetti, regardless of how experienced the developers were. The complexity of the API without effective tools for structuring UI code made it difficult to avoid the spaghetti.

The most notable example of this I experienced is with state management hooks. useContext, useReducer, and useState can all be used to manage UI state. Using all 3 hooks in a codebase will make it harder to understand. One can also use a state management library that comes with its own hooks.

The API complexity also leads to slow websites due to the challenge of writing React code. For a good user experience, a user interface should show some sort of feedback within 0.1 seconds of a user clicking on a button. On a slow React website, it might take significantly longer than 0.1 seconds. In the case that the codebase has turned into spaghetti, finding the cause of slow responses can be next to impossible.

Once the cause of the slowness has been identified, fixing it can take a long. Sometimes, this means indefinite postponement because of other high priority work.