What are Server Components vs Client Components trade-offs?

Choosing between Server Components (RSC) and Client Components requires understanding the trade-offs: Server Components — Strengths: zero JavaScript sent to client (huge bundle reduction); direct database/file system access without API layer; can use secrets (API keys, DB credentials); automatic code splitting for RSC; better initial page load performance; data fetching collocated with rendering. Server Components — Limitations: no interactivity (no event handlers); no React state (useState, useReducer); no lifecycle hooks (useEffect); no browser APIs (window, localStorage); no context that depends on client state; cannot use class components with client state. Client Components — Strengths: full React interactivity; access to browser APIs; React hooks (useState, useEffect, useRef, etc.); real-time features, subscriptions; immediate UI feedback (no server round-trip). Client Components — Limitations: increase JavaScript bundle; secrets must be handled via API calls; can't directly access database. Decision framework: start Server Component, add "use client" only when you need: interactivity, browser APIs, third-party client libraries. Composition pattern: Server Components can render Client Components (passing server-fetched data as props). Client Components cannot render Server Components (they're already on the client). BUT: Client Components CAN receive Server Components as children via the children prop (the Server Component renders server-side and its HTML is passed through). Minimize "use client" boundaries — push them as far down the tree as possible.