React 19 Breaks Async Composability

Original Article ↗ Hacker News Discussion ↗

React 19’s changes to async rendering and data fetching are raising concerns that it makes lazy loading and parallel requests harder, worsening UX for complex apps that rely on composable async logic. Commenters tie this to a broader frustration with React’s evolving best practices, hooks “magic,” and the high maintenance burden of the JavaScript ecosystem, especially compared with more stable stacks like PHP or Rails. Many are re‑evaluating their choices, pointing to alternatives such as Vue, Svelte, Lit, and htmx, and questioning React’s trajectory under the growing influence of Next.js and Vercel.

React’s evolving patterns (classes, hooks, compiler)

  • Frequent “best practice” shifts lead to large refactors of working code; many see this as wasteful churn.
  • Some argue class components were React’s last “good” idea; others find function components much cleaner and hooks a major improvement in composing side effects and logic.
  • Critics of hooks see them as “magic” that’s hard to debug in large, aging apps, fearing the upcoming compiler will push more behavior into opaque internals and reduce developer understanding.
  • There is debate over calling them “functional components”: they are functions but not truly functional in the FP sense, since they rely on shared mutable state.

Async composability and React 19

  • The change is framed as degrading async composability: parallel lazy-loading patterns are pushed toward waterfall loading to improve rendering consistency and loading states.
  • Some say “nothing functional breaks,” but UX worsens for patterns that previously did parallel fetches.
  • Others emphasize that Suspense and related patterns were always awkward for dependent queries and complex data flows; hooks don’t compose well with promises.
  • Proposed mitigations (e.g., in routing libraries) help simple cases but are seen as insufficient for multi-step or dependent data fetching.

Ecosystem churn and maintenance pain

  • Many describe JavaScript/React tooling as fragile: projects can stop building after months due to dependency, bundler, or Node changes.
  • Comparisons are made to PHP and some other stacks where decade-old code often still runs with minimal changes, though this is noted as not universally true.
  • Package manager churn (npm → yarn → pnpm → bun) is cited as emblematic; some report relief using tools like pnpm, but others see it as more flavor-of-the-week complexity.

SSR, SPAs, and framework direction (Next.js/Vercel)

  • There’s frustration that client-side apps that just talk to JSON APIs are being pushed toward SSR/“app router” paradigms optimized for content-heavy sites.
  • Some view Next.js-driven features and React “server components” as aligning React with Vercel’s priorities, eroding framework-agnostic usage.
  • Concern extends to Svelte/SvelteKit because many core maintainers are also employed by the same company.

Overuse of React and alternatives

  • Several argue React is used in ~“95%” of cases where simpler tech (plain HTML, small JS, htmx, Rails/Phoenix, Lit, vanilla JS + web components) would suffice and be easier to maintain.
  • Others counter that teams choose React for hiring, familiarity, and a shared mental model, even when technically “overpowered” for the problem.
  • Vue is praised for simpler reactivity and event-driven patterns, though some find its Composition API harder than React hooks. Angular is widely criticized for churn and complexity.