What does server-first development mean in modern Next.js?

Server-first development is the architectural shift the App Router pushes — components run on the server by default, and you opt in to client-side JavaScript only when you need it.

In the Pages Router, React ran on the client. The server rendered an initial HTML snapshot, then hydration kicked in and JavaScript took over. Every component shipped to the browser, whether it needed to or not.

In the App Router with React Server Components, every component in app/ is a server component by default. They render on the server, stream HTML to the browser, and their JavaScript never ships to the client. You add 'use client' at the top of a file only when a component needs browser APIs, state, effects, or event handlers.

A typical server-first page:

// app/products/page.tsx — server component
import { db } from '@/lib/db';
import AddToCart from './add-to-cart';

export default async function ProductsPage() {
  const products = await db.product.findMany(); // direct DB access
  return (
    <ul>
      {products.map(p => (
        <li key={p.id}>
          {p.name}
          <AddToCart productId={p.id} /> {/* client component island */}
        </li>
      ))}
    </ul>
  );
}

What you gain:

• Smaller client bundles — only interactive pieces ship to the browser. The data-fetching logic, ORM client, and Markdown parser all stay on the server.

• Direct data access — server components can talk to the database, read env vars, call internal services, and use Node-only libraries without an API layer in between.

• Secure-by-default — secrets stay on the server automatically. You can't accidentally leak an API key into client bundles.

• Streaming — pages can send HTML progressively. Fast parts render immediately; slow parts stream in under Suspense boundaries.

• Server Actions — mutations become plain async functions that run on the server, callable from forms or client components with no manual fetch wiring.

The mental model:

• Default to server. Write components as async server components and fetch data right inside them.

• Carve out client islands where interaction lives — modals, forms, real-time UI, anything using useState, useEffect, or browser APIs.

• Pass data down, not up. Server components can render client components and pass props, but not the reverse (since client components don't run on the server).

• Mutations via Server Actions rather than client-side fetch calls. You get progressive enhancement and built-in type safety.

What changes in day-to-day work: less time writing API routes that exist only to serve your own frontend. The page component is the endpoint. That's the shift — the server and the UI collapse into the same file tree.