The useful provocation in the Cloud Codes source video is not the slogan. It is the discomfort underneath the slogan: a lot of modern front ends make simple web work harder to inspect than it needs to be.
"React is dying" is bad framing because it turns an architecture question into a tribe question. React is still an active, useful library for building interactive interfaces. It is especially strong when the client owns meaningful state: editors, canvases, dashboards, offline workspaces, multi-step application shells, cross-widget interactions, and experiences where component composition is carrying real product value. Calling React dead confuses overuse with failure.
A better claim is sharper and more useful: SPA-by-default is the questionable default. The web already has a durable interaction model. Links navigate. Forms submit. Servers validate. Responses can carry the next visible state. Pages can expose headings, labels, tables, anchors, provenance, receipts, and caveats without requiring a client runtime to reconstruct meaning. When the page is mostly a document, catalog, receipt, or server-owned workflow, turning it into a full client application adds a verification surface before the work has asked for one.
That extra surface is not free. A full SPA can introduce client routing, hydration, bundle loading, state synchronization, optimistic updates, error reconciliation, and test paths that do not exist in the simpler design. Sometimes those are the cost of doing the job well. Sometimes they are only the cost of following habit.
Hypermedia and HTMX matter because they make the old web model newly discussable. HTMX lets HTML elements issue requests, target updates, trigger behavior, and swap server-returned HTML. That does not make HTMX universally better than React. It makes a different ownership model easy to express. If the server owns the record, the validation rule, the permission check, and the next workflow state, returning the next piece of HTML can be more honest than asking the client to simulate authority it does not really have.
Server-owned workflow state is especially important in governed systems. If a form submission fails, the returned HTML can show the error beside the field. If a record update succeeds, the returned markup can include the new value and the receipt. If a step requires approval, the next page can make the stop condition visible. Humans can read it. Validators can test it. Search and crawler systems can often discover more of the meaning. Agent tooling has fewer hidden assumptions to reverse-engineer.
Readable markup is not magic. It does not guarantee SEO, ranking, crawler access, or AI discoverability. But it does improve the public contract of a page. A heading says what section the reader is in. A link says where a path goes. A form label says what input is expected. A table says how rows compare. A receipt says what evidence exists. Those are useful to humans first, and they also give automated tools more explicit handles.
That is why the phrase "AI agents prefer HTMX" must stay in the right box. It is a source thesis and teaching interpretation, not a measured universal fact. Agent behavior depends on the tool, browser runtime, network access, robots policy, JavaScript execution, permissions, task shape, and the actual page implementation. A bad HTML page can be harder to use than a well-built React app. A React app with server rendering, accessible markup, stable routes, and visible state can be highly inspectable. The claim worth publishing is more modest: agent-friendly front ends tend to benefit from semantic HTML, smaller state surfaces, explicit actions, and inspectable responses.
React remains the correct answer when client-side interaction is the product. If users are manipulating a long-lived editor, arranging a visual workspace, handling offline changes, coordinating multiple live panels, or depending on rich local state, React is not an indulgence. It is carrying the interaction model. The mistake is not using React. The mistake is using a client app as the default wrapper around work that wants to be a page, a form, a receipt, or a server-owned workflow.
The practical decision rule is simple: choose the smallest architecture that honestly supports the interaction model. Start with semantic HTML and server-owned truth. Add HTMX when small server-returned updates make the workflow clearer. Add React islands when a specific region needs rich client state. Use a full SPA when the client application is genuinely the product. That rule is less glamorous than a framework debate, but it is much harder to fool.