Not for every site. That's the honest, boring qualifier this whole question needs before it's worth anything, so let's get it out of the way first: if you're building a genuinely interactive application — real client state, real user-driven UI that changes shape constantly — React is still a reasonable, well-supported answer. Nothing here argues otherwise.

But most content sites aren't that. A blog, a docs site, a marketing page — the interesting question isn't "is React good," it's "what is React actually doing on this specific page," and for a huge number of real sites running it today, the honest answer is: managing state that barely changes, for interactivity that mostly doesn't exist, shipped to every visitor whether they need it or not.

## Where the component model actually earns its keep

React's component model solves a real problem: reusability and state management for a large team of humans building a large, changing application by hand. That's a genuine, hard problem, and the tooling built around solving it is genuinely good at solving it.

The problem is narrower than "building a website," though, and content sites mostly don't have it. A blog post doesn't have state. A docs page doesn't need to re-render in response to user interaction. The thing being built is closer to a document than an application — and shipping an application's tooling to serve a document is where the cost shows up, in bundle size, in hydration time, in a build step that exists to solve a problem the page never actually had.

> This gets sharper, not weaker, once an agent is the one authoring content. A framework's component model exists partly to help a human avoid repeating themselves across files they can't hold in their head at once. A model doesn't have that limit. The scaffolding stops paying for itself the moment the thing it was built to help with isn't the bottleneck anymore.

## The actual question worth asking

Not "should I ever use React" — that's a different, much less interesting question with an obvious answer. The one worth sitting with is: for the specific page you're about to build, is there real client-side state and interactivity, or is there a document that happens to have a `.jsx` extension out of habit?

If it's the second one, the framework isn't making the page better. It's making it heavier, slower to build, and harder to reason about, in exchange for capability the page was never going to use. That's not a React problem specifically — it's what happens whenever a tool built for one shape of problem gets reached for by default, for a different shape of problem, because reaching for it stopped being a decision and became a reflex.

We wrote the fuller version of this argument, past just React specifically, in [the piece on why we skipped frameworks entirely](/blog/built-for-the-agent/).