GitHub

React 19 & Server Components

React Server Components (RSC)

React Server Components, now fully stable in React 19, represent the most significant architectural shift in React since Hooks. Server Components render on the server and stream HTML to the client without sending any JavaScript for those components. They can directly access databases, file systems, and backend services — no API layer needed. The client never downloads, parses, or executes the code for a Server Component, which fundamentally addresses React’s biggest criticism: bundle size.

In the Next.js App Router (and increasingly in other frameworks), all components are Server Components by default. Only components that need client-side interactivity — event handlers, state, effects, browser APIs — are marked with "use client". This inversion of the mental model means you ship JavaScript only for the parts of your UI that truly need it. For a typical content page with a header, navigation, article body, and a single interactive comment form, only the comment form sends JavaScript to the browser. Everything else is zero-JS server-rendered HTML.

RSC also eliminates the “waterfall” problem of client-side data fetching. In a CSR SPA, the pattern is: load HTML → load JS → execute JS → fetch data → render. With RSC, data fetching happens on the server during rendering, colocated with the component that needs it. The data never crosses the network as a separate API call — it’s embedded directly in the server-rendered output. This produces dramatically faster LCP, especially on slow networks.

Resources:

Server Actions and the Actions API

React 19 introduces Actions, a first-class API for handling data mutations (form submissions, database writes, API calls) that replaces the verbose pattern of managing loading states, errors, and optimistic updates manually with useState and useEffect. You define a function with "use server", pass it as the action prop on a <form>, and React automatically handles the entire lifecycle — pending states, error boundaries, progressive enhancement (forms work even if JavaScript fails to load), and automatic form reset on success.

Several new hooks support this pattern. useActionState manages the state of an action (pending, success, error) without manual state management. useFormStatus lets child components access the submission status of a parent form (e.g., disabling a submit button while pending). useOptimistic enables instant UI feedback — update the UI immediately while the server request is in flight, and roll back automatically if it fails. Together, these hooks can reduce form-handling boilerplate by 50–70% compared to traditional REST/GraphQL approaches.

Server Actions are particularly powerful because they compose with Server Components: a Server Component can render a form whose action runs on the server, fetch data from a database, and return updated UI — all without the client ever knowing about the data source, API endpoint, or authentication logic. This is the “full-stack component” pattern that Next.js App Router and React Router v7 build upon.

Resources:

The React Compiler (React Forget)

The React Compiler, formerly known as “React Forget,” is a build-time tool that automatically optimizes re-renders without manual memoization. It analyzes your component code, understands the dependency relationships between state, props, and derived values, and inserts useMemo, useCallback, and memo equivalents at compile time — but more precisely than a human would. One team reported removing 2,300 lines of manual memoization code from a dashboard app, and the app actually ran faster because the compiler optimized cases they had missed.

The compiler works transparently: you write standard React code with no new syntax or APIs, and the compiler’s output is optimized JavaScript. Instagram uses the compiler internally at Meta, and early adopters report 25–40% fewer re-renders in complex applications without any code changes. For new projects, this means you can stop worrying about useMemo/useCallback in most cases and focus on writing clear, readable components. For existing projects, the compiler can be adopted gradually — start with isolated components, measure the impact, then expand.

The practical implication for performance is significant: premature or incorrect memoization has been a long-standing source of both complexity and bugs in React applications. The compiler eliminates this entire class of problems. It also composes well with Server Components — server-rendered components don’t need memoization at all (they render once on the server), and the compiler optimizes only the client components that actually re-render.

Resources:

The use Hook and Suspense Integration

The use hook is a new primitive in React 19 that reads the value of a resource — a Promise or a Context — directly inside the render function. Unlike other hooks, use can be called conditionally and within loops. For Promises, it integrates with Suspense: when a component calls use(somePromise), React suspends that component (showing the nearest <Suspense> fallback) until the Promise resolves, then re-renders with the resolved value. This eliminates the useState + useEffect pattern for data fetching:

// Before (React 18)
const [data, setData] = useState(null);
useEffect(() => { fetchData().then(setData); }, []);

// After (React 19)
const data = use(fetchData());

For Context, use(SomeContext) replaces useContext(SomeContext) but with the added flexibility of conditional calls. Combined with streaming SSR and Suspense boundaries, the use hook creates a declarative data-fetching model where components describe what data they need, and React handles when and how to fetch it, including progressive rendering of partial results.

Resources:

Streaming SSR with Suspense

React 18 introduced streaming SSR via renderToPipeableStream, and React 19 builds on this with optimized streaming that reduces TTFB by an average of 340ms in reported benchmarks. The pattern: wrap slow-loading parts of your page in <Suspense> boundaries with fallback UI, and React streams the fast parts immediately while the slow parts render asynchronously on the server.

When the slow component finishes, React streams a <script> tag that swaps the fallback with the real content — no client-side JavaScript framework needed for this swap. Combined with selective hydration (React prioritizes hydrating the component the user is interacting with), this means users see content quickly, interact with the parts that are ready, and the rest fills in progressively. Next.js App Router, React Router v7, and SvelteKit all build on this pattern.

Resources:

Next.js: App Router, PPR, and Turbopack

Next.js remains the dominant meta-framework for React, and its evolution closely tracks React 19’s capabilities. Next.js 16 (October 2025) made Turbopack the default bundler, and Next.js 16.1 (December 2025) added stable File System Caching. The App Router, which has been the default since Next.js 13.4, provides built-in support for Server Components, Server Actions, streaming SSR, parallel routes, intercepting routes, and nested layouts.

Partial Prerendering (PPR), still experimental, is Next.js’s most forward-looking feature: it combines static and dynamic rendering within a single request. The static shell (layout, navigation) serves instantly from the edge cache, while dynamic “holes” (personalized content, real-time data) stream in via Suspense. This eliminates the need to choose SSG vs SSR per route — the framework determines which parts of each page can be static and which need to be dynamic.

For caching, Next.js provides multiple layers: the Data Cache (server-side, persists across requests and deploys), the Full Route Cache (caches static route output), and the Router Cache (client-side, caches prefetched routes). Understanding these layers — and when to use revalidateTag, revalidatePath, or cache: 'no-store' — is essential for performance tuning. Server Actions compose directly with these caching layers via revalidateTag() to invalidate specific cached data after mutations.

Resources:

Vinext: The Next.js API on Vite

Vinext, released by Cloudflare in late February 2026, is an experimental project that reimplements the Next.js public API surface as a Vite plugin. It is not a fork of Next.js or a wrapper around next build — it’s a from-scratch reimplementation of Next.js routing, server rendering, RSC integration (via @vitejs/plugin-rsc), Server Actions, middleware, ISR, and all next/* module imports, built on Vite 8 and Rolldown. The result: 4.4× faster builds and 57% smaller client bundles in benchmarks on a 33-route App Router application compared to Next.js 16 with Turbopack.

The project is remarkable for several reasons beyond raw performance. It demonstrates that the Next.js API surface can be decoupled from Next.js’s internal build system, reducing platform lock-in — roughly 95% of vinext is platform-agnostic Vite code. Cloudflare Workers is the primary deployment target (with vinext deploy producing globally distributed Workers with zero cold starts), but it was adapted to run on Vercel in under 30 minutes as a proof of concept. It also introduces Traffic-Proportional Rendering (TPR), which queries Cloudflare zone analytics at deploy time to pre-render only the pages that actually receive traffic, achieving SSG-level latency for popular pages without building your entire site.

Vinext covers 94% of the Next.js 16 API surface and is already running on CIO.gov in production. However, major caveats apply: it’s one week old as of this writing, explicitly experimental, has known bugs, and was almost entirely AI-written (800+ Claude Code sessions, $1,100 in API tokens, one engineer). For production workloads today, OpenNext (which adapts standard next build output for various platforms) remains the safer choice. But vinext is a significant signal about the future direction: the Vite + Rolldown + Oxc toolchain as a universal build layer, with framework-level APIs implemented as plugins on top.

Resources:

React Router v7 (The Remix Merger)

React Router v7, released in late 2024, merged Remix’s full-stack capabilities directly into React Router. This means React Router is no longer just a client-side routing library — it now supports Server Components, server-side data loading (loader), mutations (action), streaming, and progressive enhancement out of the box. The lazy route property enables per-route code splitting, and the prefetching system pre-loads data for likely next pages based on link visibility and hover intent.

The philosophical approach differs from Next.js: React Router v7 emphasizes progressive enhancement and web-standard patterns (standard <form> submissions, HTTP response semantics) over framework-specific APIs. It deploys to any Node.js server, Cloudflare Workers, Deno, or Vercel. For teams that prefer Vite over Turbopack and want a React meta-framework without the Next.js ecosystem, React Router v7 is the leading alternative.

Resources: