Why Tech Companies Are Moving Off React

TL;DR

Many “React scaling” complaints are attributed to developer practices, state/data architecture, and performance discipline rather than React itself.

Briefing Cornell Notes

Briefing

Silicon Valley CTOs are increasingly discussing moves away from React, but the most consequential takeaway is that many of the complaints blamed on React are really about scaling patterns, developer practices, and missing performance discipline—not React’s core design. The argument centers on a blunt idea: React “succeeded too well,” making it easier for more teams (including less experienced ones) to ship large, state-heavy front ends—so the resulting pain often shows up as “React problems” even when the root causes are elsewhere.

A fintech VP quoted in the discussion describes going all-in on React in 2017 and then hitting scaling walls by 2021 as a team grew to 200 developers. The counterpoint is that scaling issues aren’t automatically caused by React itself: a large Twitch codebase reportedly had scaling trouble tied to TypeScript and codebase weight, not React rendering. More broadly, the critique targets the React ecosystem’s “bets” at scale—hooks, concurrent mode, server components, and the compiler—arguing that several of these were specifically designed to address the exact kinds of performance and complexity problems large apps face.

Hooks get the strongest defense. The discussion contrasts older state-sharing patterns—higher-order components and render props—where state and data had to be threaded through wrapper layers with complex prop plumbing, with hooks that standardize state reuse and composability. The practical claim is that hooks reduce cognitive overhead for large codebases by making reusable state logic easier to package as custom hooks, which then compose cleanly with other state tools like Redux or Zustand.

Concurrent mode is framed as a performance fix for “sticky keys” style input lag: synchronous rendering can block user events on the main thread, while concurrent rendering can pause, defer, and resume work so typing stays responsive. Server components are treated as a larger architectural shift aimed at version drift and oversized client bundles. Instead of shipping JSON and client-side logic that must stay in sync with server-driven UI states, server components push rendered output (or render instructions) from the server, reducing client logic, version mismatch risk, and the need to update every client before new experiences can ship.

The compiler is presented as the newest lever, with concrete results from Meta. React Compiler was rolled out on Quest Store and Instagram.com, reportedly improving click/scroll interactions by more than 2×, speeding initial load and cross-page navigation by up to 12%, and improving route performance by several percentage points without measurable memory or crash regressions.

The broader conclusion is that “moving off React” rarely solves the real issues: performance bottlenecks often come from too much JavaScript, too many client-server round trips, and insufficient use of browser tooling. The recommended path is to adopt React’s scaling features (hooks correctly, concurrent mode, server components where version drift and bundle size matter, and compiler), and to keep non-React logic in the right layer when it’s more performant or simpler. The transcript also attacks the “churn” narrative, arguing that many framework changes are optional improvements rather than forced migrations, and that blaming React for developer onboarding delays or codebase complexity ignores the reality that complexity rises with product scope and team practices.

In the end, the case for leaving React is portrayed as mostly job-security or misdiagnosis dressed up as architecture. The prescription is to measure the actual bottlenecks, fix state and data-fetching patterns, and only change frameworks when the problem truly lies outside React’s reach.

Cornell Notes

The transcript argues that React isn’t failing; many scaling failures blamed on React come from how teams structure state, data fetching, and performance work as apps grow. Hooks are defended as a major win for large codebases because they replace wrapper-heavy patterns (higher-order components, render props) with composable reusable state via custom hooks. Concurrent mode is framed as a fix for main-thread blocking that causes input lag, while server components are presented as an architectural answer to version drift and oversized client bundles by shifting UI rendering responsibility to the server. React Compiler is cited with Meta rollout results on Quest Store and Instagram.com showing large interaction and navigation speedups without memory/crash regressions. The practical takeaway: measure bottlenecks, use React’s scaling tools correctly, and don’t switch frameworks just to avoid learning or debugging the real causes.

Why do some teams interpret scaling pain as “React’s fault,” and what counter-explanation is offered?

The transcript claims React becomes the scapegoat when teams scale up and ship more stateful UI, often with less experienced developers. A quoted fintech example links scaling problems to having ~200 developers on a React app, but the counterpoint is that scaling issues can stem from other system constraints—such as TypeScript/codebase weight (Twitch is cited as an example where TypeScript struggled under a large codebase while React was “totally fine”). The argument is that React’s success increases adoption, which increases the number of teams hitting performance and complexity issues; those issues aren’t automatically caused by React itself.

How do hooks change state reuse compared with older React patterns?

Hooks are contrasted with higher-order components and render props, which require wrapper layers to pass state/data down through props. The transcript walks through how HOCs and render props force components to be called with custom parameters and add “obnoxiously complex” context/prop plumbing, making composability and type flow harder. With hooks, state and data can be accessed directly inside components (e.g., using a GraphQL query via a hook), and reusable logic can be packaged as custom hooks (e.g., turning a query hook into a reusable `use user data` hook). The claim is that this reduces cognitive overhead and improves composability for large codebases.

What problem does concurrent mode target, and what user-visible symptom does it address?

Concurrent mode targets synchronous rendering that blocks user input on the main thread. The transcript describes a “sticky keys” scenario: when typing triggers an update, synchronous React can prevent input events from being processed until rendering finishes, leading to missed keystrokes or out-of-order events. Concurrent rendering can pause/defer work and switch to user-blocking tasks, letting typing continue while React finishes rendering later. The emphasis is that this matters most for large apps with heavy rendering.

Why are server components framed as a solution to “version drift” and server-driven UI challenges?

Server components are described as components that run on the server and send rendered output or render instructions to the client. The transcript explains that traditional client-driven React apps require the client bundle to contain logic for every possible UI state the server might request; if the server changes and the client is out of date, the app can render incorrectly or fail. Server-driven UI patterns (common in large platforms like YouTube/Facebook feeds) solve this by letting the server decide what to render, but implementing SDUI primitives across iOS/Android/web is expensive and usually requires large engineering teams. Server components are presented as a standardized path that reduces client logic, reduces version mismatch risk, and shrinks client bundles by moving rendering work to the server.

What evidence is given for React Compiler’s impact, and what does it claim to avoid?

The transcript cites Meta rollouts: React Compiler enabled by default on Quest Store and Instagram.com. Reported results include more than 2× speedups for certain click/scroll interactions, up to 12% improvements in initial load and cross-page navigation, and route-level gains (at least ~4% on Quest Store and ~3% average across Instagram routes). It also claims no impact on memory usage or overall crashes, suggesting the optimizations didn’t introduce regressions like out-of-memory errors.

What does the transcript recommend when performance problems appear—switch frameworks or change how React is used?

The recommendation is to treat React as part of the solution rather than the cause. The transcript argues that performance issues typically come from sending too much JavaScript, running large payloads on low-performance devices, and using inefficient client-server round trips. It also stresses learning and using browser performance/debugging tools. The suggested approach is to move the right work off the client (e.g., server components), adopt React’s performance features (compiler/concurrent mode), and avoid assuming a framework swap will fix problems caused by developer practices or architecture.

Review Questions

Which specific React features are defended as addressing scaling and performance bottlenecks, and what bottleneck does each one target?
How do hooks change the mechanics of state reuse compared with higher-order components and render props, according to the transcript?
What kinds of performance problems does the transcript attribute to client-side JavaScript and round trips, and why does it argue that switching frameworks won’t automatically fix them?

Key Points

1
Many “React scaling” complaints are attributed to developer practices, state/data architecture, and performance discipline rather than React itself.
2
Hooks are presented as a major improvement over wrapper-heavy patterns (higher-order components, render props) by enabling composable reusable state via custom hooks.
3
Concurrent mode is framed as a fix for main-thread blocking that causes input lag (the “sticky keys” problem).
4
Server components are argued to reduce version drift and client bundle bloat by shifting UI rendering responsibility to the server, aligning with server-driven UI needs.
5
React Compiler is cited with Meta rollout metrics showing large interaction and navigation speedups without memory/crash regressions.
6
Performance issues are often linked to too much client JavaScript and inefficient client-server round trips; the transcript recommends measuring and fixing those rather than switching frameworks.
7
“Churn” narratives are challenged: many changes are portrayed as optional improvements or interoperable transitions rather than forced migrations.

Highlights

The transcript’s central counterclaim: React isn’t failing—teams often misdiagnose scaling pain that comes from state complexity, performance tooling gaps, and oversized client work.

Hooks are defended with a concrete architectural comparison: wrapper layers (HOCs/render props) create prop/context plumbing and composability friction that hooks largely remove.

Server components are positioned as a standardized answer to server-driven UI and version drift—reducing client logic and preventing broken renders when server state changes.

React Compiler is backed by specific Meta rollout numbers on Quest Store and Instagram.com, including >2× interaction speedups and up to 12% navigation improvements without memory/crash impact.

The transcript repeatedly argues that framework swaps don’t fix performance when the real causes are too much JavaScript, too many round trips, and poor use of browser debugging tools.

Topics

React Hooks
Concurrent Mode
Server Components
React Compiler
Server-Driven UI

Mentioned

SDUI