If not React, then what?

Scope: “Sites” vs “Apps”

• Many commenters stress the distinction between low‑interactivity “sites” (marketing, blogs, docs, e‑commerce catalogs) and high‑interactivity “apps” (Gmail, Linear, complex business tools).
• Broad agreement: most of the web is “sites”, but much of it is built and shipped like “apps” (React SPAs), often unnecessarily.
• Disagreement on how often SPAs are truly needed; some say “almost never”, others say “for any substantial app”.

Performance and User Experience

• Critics argue React/SPAs lead to slow first loads, heavy JS, janky scrolling, broken browser history, and poor Core Web Vitals, especially on cheap Android phones and bad networks.
• Others counter that React itself can be fast; slowness usually comes from misuse, excessive dependencies, and server/API design.
• Tension between “hundreds of milliseconds don’t matter” and “every 100ms is user‑visible and costly, especially for e‑commerce and mobile users”.

Arguments Against React as Default

• Claims React is “legacy” and burdened by old design (synthetic events, hydration, poor SSR story, complicated hooks, useEffect footguns).
• React is seen as easy to build bad apps with, hard to master, and structurally biased toward SPAs and client‑heavy architectures.
• Several say large React codebases become spaghetti and are hard to maintain or refactor over years.

Defenses of React and Its Ecosystem

• Strong emphasis on hiring: it’s much easier to find productive React/TypeScript engineers and off‑the‑shelf components than for niche stacks.
• Many report good experiences on large, highly interactive apps; for these, a component model plus client state is described as a major win over jQuery/“Ajax era” patterns.
• Popularity is cited as a practical advantage (docs, Stack Overflow answers, LLM training data, security hardening).

Alternatives and Architectural Patterns

• For “sites”: server‑rendered HTML with light JS is widely recommended (Rails/Django/Laravel + Turbo/Hotwire, HTMX, Alpine, Stimulus, Turbo morphing, WordPress, etc.).
• For “apps”: proposals include Vue, Svelte, Solid, Mithril, Elm, Phoenix LiveView, Blazor, Rust/WASM frameworks (Leptos, Yew, Dioxus), and React used only as a thin view library or islands.
• Some advocate strict “no client state beyond a component” approaches, or hypermedia‑centric HTMX workflows returning HTML instead of JSON.

Meta: Article Tone and Persuasiveness

• Numerous readers find the article’s tone dogmatic, ranty, or hostile (e.g., “never start a new project with React”), which they say undermines otherwise valid performance and UX concerns.
• Others see it as a necessary overcorrection against “just use React” cargo culting and tech‑stack‑first decision‑making.