React 19 Breaks Async Composability

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.