Why We Ditched React Server Components

RSC promised the best of both worlds: server efficiency and client interactivity. In practice, it introduced systemic complexity, bundling bloat, and vendor lock-in. Here is what we run instead.

## The Architecture That Was Promised React Server Components (RSC) were pitched as the definitive solution to the modern web's dual dilemmas: excessive client-side JavaScript payloads and fragmented developer ergonomics. The promise was clean: leave heavyweight dependencies, database queries, and static rendering pipelines securely on the server, while selectively hydrating interactive nodes on the client. After maintaining three major enterprise web platforms built entirely on the RSC architecture throughout 2024 and 2025, our studio made the deliberate decision to rip it out. We did not make this decision out of dogma. We made it because RSC traded straightforward client performance challenges for systemic structural complexity, unstable mental models, and deep vendor lock-in that degrades application maintainability. ## The Reality of the RSC Stack To run an RSC-centric application effectively, you don't just write React; you adopt a complex orchestration layer. The boundary between the server runtime, the client runtime, and the serializable intermediate format (the RSC flight payload) introduces subtle failure modes that can stall entire production teams. ### 1. The Serialization Tax Every component crossing the `'use client'` boundary must have its props serialized into an internal streaming format. Passing complex instances, callbacks, custom classes, or circular references results in runtime serialization failures. Developers end up building defensive mapping layers simply to push data ten pixels to the right. ### 2. Dual-Execution Mental Fatigue Explaining the mental model to intermediate developers requires an entire week of onboarding. A component might run *only* on the server at build time, *only* on the server at request time, or *both* on the server and then hydrate on the client. A misplaced import can silently bundle server logic into the client payload or trigger waterfall fetches that destroy Time-to-First-Byte (TTFB). ### 3. Framework and Hosting Lock-in While React is technically open-source, the production runtime for RSC is tightly coupled with proprietary infrastructure primitives. The moment you step outside pre-packaged ecosystem configurations, setting up independent streaming caches, asset manifests, and edge-routing primitives requires deep, low-level internal knowledge. ## The Alternative: Edge-Rendered HTML and Modern Islands We returned to fundamental primitives: pure semantic HTML generated via ultra-fast Edge runtimes, supplemented with zero-dependency Custom Elements (Web Components) and Islands of interactivity only where dynamic state is genuinely required. Instead of shipping a heavy runtime engine to decode a serialized component tree on the client, the server streams standard, valid HTML. Dynamic interactivity is isolated strictly to self-contained custom elements that hydrate independently without blocking the main browser thread. ```javascript // An interactive Island that requires zero framework runtimes to hydrate class RealtimeChart extends HTMLElement { connectedCallback() { const endpoint = this.getAttribute('data-stream'); const socket = new WebSocket(endpoint); socket.onmessage = ({ data }) => { const payload = JSON.parse(data); this.renderFrame(payload); }; } renderFrame(payload) { // Mutate only internal DOM; no virtual DOM reconciliation required this.querySelector('.metric-val').textContent = payload.metric; } } customElements.define('realtime-chart', RealtimeChart); ``` ## How the Architectures Compare in Production When we benchmarked our standard e-commerce client rebuild, comparing an optimized RSC application against an Edge HTML + Web Components model, the performance metrics settled the debate: * **Initial JavaScript Sent to Client:** Reduced from 184 KB (gzipped framework runtime + flight decoders + component manifests) to 12 KB (strictly isolated Island logic). * **Total TTFB at Edge (P95):** Dropped from 380ms down to 42ms. The Edge workers do not spin up complex node-emulation layers; they assemble pre-compiled HTML templates and flush them instantly. * **Interaction to Next Paint (INP):** Hovered around 18ms consistently across low-tier mobile devices. Because there is no overarching client-side reconciliation tree, main thread execution stalls drop to zero. ## The Engineering Trade-off There is no free lunch in software architecture. Dropping RSC in favor of Edge Islands means leaving behind the convenience of ubiquitous, uniform React component libraries. Your engineers must be fluent in native DOM APIs, understand how browser layout cycles operate, and write clean, structured CSS instead of relying on runtime CSS-in-JS solutions. However, what you regain is engineering velocity, predictable debugging environments, and platforms that load instantly across every device category without depending on heavy third-party runtimes. Before you commit your next multi-year platform rewrite to the complexity of React Server Components, ask yourself: are you solving a user experience problem, or are you servicing the complexity of your framework?

Why We Abandoned React Server Components for Zero-JS Edge Islands

What clients say

Why We Abandoned React Server Components for Zero-JS Edge Islands

What clients say

Related posts