React 19

Original Article ↗ Hacker News Discussion ↗

React 19’s release highlights both the power and the growing complexity of today’s frontend ecosystem. Many developers praise React’s maturity, ecosystem, and backwards compatibility, but argue that its ever-expanding set of hooks, patterns, and surrounding tooling makes it hard for newcomers and encourages fragile, over-engineered SPAs where simpler server‑rendered approaches (e.g. with HTMX, LiveView, or classic MVC frameworks) would suffice. Others counter that React remains a solid choice for large, interactive apps—especially given its stability over a decade and strong TypeScript and library support—framing the real problem as ecosystem churn and misuse rather than the core library itself.

Overall Reaction to React 19

  • Many welcome incremental QoL changes (refs as props, <Context value={…}>, better hydration errors, custom elements support).
  • Enthusiasm for the React Compiler beta: expected to reduce manual memoization and “render optimization” boilerplate.
  • Skepticism toward new hooks like useActionState, useOptimistic, use, and Actions/Transitions: seen as powerful but conceptually heavy and adding cognitive load.
  • Some feel React has drifted from a small, elegant core toward Kubernetes‑like layers of abstraction.

Learning Curve & Beginner Experience

  • Several worry that the growing surface area (hooks, server components, transitions, Suspense, actions) makes React intimidating for newcomers.
  • Others argue beginners don’t start with changelogs; official docs shield them from advanced APIs and still present a coherent, gradual path.
  • Strong advice from many: start with HTML/CSS/vanilla JS (maybe TS), then move to a framework; don’t begin with React.

Alternatives & Architectural Debates

  • Large subthread: React vs HTMX / Hotwire / Phoenix LiveView vs “boring” server‑rendered apps.
    • Pro‑HTMX/server‑HTML side: simpler, fewer moving parts, fewer bugs, better use of the web’s native model (backend returns HTML). Argue many apps don’t need SPA‑level complexity.
    • Pro‑SPA/React side: necessary for highly interactive or offline‑first apps; avoids server round‑trips for every interaction; React’s model fits large stateful UIs.
  • Other alternatives praised: Vue, Svelte, Solid, Mithril, LiveView, Alpine.js; many say Vue/Svelte/Solid feel simpler, with fewer “footguns.”
  • Debate over payload size and performance: HTML vs JSON differences found to be smaller than often assumed; tradeoffs depend on data volume, interactivity, and server load.

State Management & Performance

  • Redux often cited as over‑engineered and a source of historical pain; modern tools like React Query, Jotai, Zustand, Valtio, MobX, context, and Relay are preferred.
  • Some say React makes it easy to accidentally create slow, over‑rendering apps; others report very fast large apps when guidelines are followed.
  • Confusion and criticism around hooks: dependency arrays, useEffect semantics, and React’s “re‑run entire render function” model vs more granular systems (Vue/Svelte signals).

Stability, Churn & Ecosystem

  • Split perception:
    • One camp: React is relatively stable (few major versions in a decade, strong backwards compatibility; class components still work).
    • Another: practical churn is high because surrounding ecosystem (Next, routing, state libs, tooling) and “best practices” keep changing.
  • Concerns about upgrading in real‑world codebases: abandoned deps, library rewrites, and pressure to keep up with major React and Next.js releases.

Jobs, Community & Broader Frontend Fatigue

  • React’s huge ecosystem, TS support, and job market are seen as major advantages; avoiding it can be “career hard mode.”
  • Others claim deep React‑only experience can produce weaker generalists who try to impose React patterns everywhere.
  • Strong undercurrent of “frontend fatigue”: constant new paradigms (VDOM → signals → compilers → islands → server components), perceived over‑engineering, and nostalgia for simpler SSR stacks.