React 19 almost made the internet slower

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.