React 19 almost made the internet slower

Original Article ↗ Hacker News Discussion ↗

React 19’s now-reverted change to Suspense, which would have penalized a common pattern for parallel data loading, has reignited criticism of React’s direction and its perceived alignment with large platforms like Vercel and Meta. Commenters argue over whether React and the broader JavaScript ecosystem have become an overcomplicated, performance-draining “machine to generate complexity,” especially for large SPAs, versus a still-essential tool for highly interactive UIs. The debate broadens into alternatives such as Vue, Svelte, SolidJS and server-first approaches (htmx, LiveView, Inertia), with many calling for simpler stacks, less churn, and architectures that push more work back to the server without sacrificing rich client experiences.

React 19 Suspense Change & Revert

  • Core issue: a React 19 change altered how Suspense handles async work, degrading performance for parallel data-loading patterns used in SPAs.
  • React team rationale (per linked PR): optimize for “best practices” like hoisting data fetching into server components or route loaders, accepting worse behavior for “bad” patterns.
  • Community feedback: they underestimated how often Suspense is used for parallel loading; this pattern is common, especially in libraries.
  • Change was reverted after pushback; some see this as a normal “try, observe, revert” process, others as evidence React is out of touch with real-world usage.

Vercel, Meta, and Influence

  • Some argue decisions are biased toward Vercel’s SSR/RSC-centric ecosystem and large PaaS interests, at the expense of traditional SPAs.
  • Others counter that the change came from performance considerations at Meta scale, not a plot to “pump Vercel bills,” and note it was quickly walked back.

SPAs, Scaling, and Tooling Pain

  • Several developers report large SPAs (tens of MB bundles, many devs, frequent deploys) as hard to scale: slow builds, heavy tooling, tricky caching, high resource usage.
  • Others say their large React apps build quickly with modern tooling (e.g., Vite) and claim “you overcomplicated your stack” rather than “SPAs don’t scale.”
  • Disagreement on “local-first” vs server-centric: some want more logic and even synced databases on the client; others emphasize team complexity and prefer a strong server–client boundary.

SSR, RSC, Route Loaders

  • Route loaders and “render-as-you-fetch” are promoted as better patterns: start data loading at the router/top-level rather than inside deep components.
  • Some see React Server Components and server actions as solving mostly “Facebook/Vercel problems,” adding complexity for typical SPA use cases.
  • Concern that React’s focus is shifting from simple SPAs to RSC-heavy architectures, potentially alienating developers.

JS Ecosystem Complexity & Churn

  • Frequent complaints about “insane” JS ecosystem churn, heavy bundlers, TypeScript slowness, and fragile dependency stacks.
  • Others push back that “JS ecosystem is insanity” is a lazy cliché, and that modern tools are much simpler than earlier Webpack-era setups.

Alternatives and Framework Tradeoffs

  • Mentioned alternatives: Vue/Nuxt (saner defaults, good perf), Svelte/SvelteKit (lightweight, high DX but visible churn), SolidJS (fine-grained, very fast, small ecosystem), Preact (React-like without current complexity), Inertia.js, HTMX, and even small custom vanilla-JS “frameworks.”
  • Debate over prioritizing ecosystem size, performance, or developer experience; many see React as still the safest bet for complex, interactive UIs due to its ecosystem.

Architecture & Philosophy Debates

  • Renewed arguments about React’s original role as “just the view” vs components now handling model, view, and controller concerns.
  • Some advocate classic MVC-style data loading in controllers/routes or server frameworks (LiveView, Inertia) with React/Vue as thin views.
  • Others view MVC in practice as messy and prefer modern component-centric architectures despite their own pitfalls.