If not React, then what?
A long polemic arguing that new projects should avoid React and single‑page app architectures in favor of server‑rendered HTML has reignited debate over how modern web UIs should be built. Commenters clash over whether React’s complexity, bundle size, and reliance on client‑side JavaScript are to blame for sluggish, fragile sites—especially on cheap mobile devices—or whether poor engineering and bloated ecosystems are the real culprits. Many suggest that for highly interactive “apps” React‑style tools remain pragmatic, but that most content‑oriented sites would be faster, simpler, and easier to maintain with server‑side rendering plus light progressive enhancement using tools like HTMX, Hotwire, or small component libraries.
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.