The Mental Model
The five ideas that explain every Waku app.
Five ideas
Everything you will build in this series follows from five ideas. Hold onto these and the rest of Waku is detail.
1. Server components first
Components are server components by default. They execute on the server, can be async, and can fetch data, read files, or query databases directly. Their output, not their code, is sent to the browser. When you need interactivity, you add 'use client' to a file; that module and everything it imports, directly or transitively, become client code running in the browser.
2. Static first
Every page and layout is prerendered at build time by default. If a page should instead reflect the current request (current data, cookies, headers), you declare it dynamic with getConfig. Static output is a build artifact: it stays exactly the same until the next build replaces it.
3. Fresh at request time
A dynamic page executes on every request, and Waku does not implicitly cache the result or the data fetched inside it. When your data changes, the next request sees it. There is no revalidation API to call because there is no hidden cache to invalidate.
4. All React, small surface
Waku adds conventions, not a parallel programming model. Routing is files in src/pages, navigation is the <Link> component, rendering mode is a getConfig export, and mutations are React server actions. Data fetching is await inside a server component; there is no framework data layer between you and your sources.
5. Portable across runtimes
The same application deploys through adapters to Node.js, Vercel, Netlify, Cloudflare, AWS Lambda, Deno, and Bun. The React programming model does not change per host; only runtime-specific capabilities (like filesystem access) vary.
Where code runs
| Code | Where it runs | When it runs |
|---|---|---|
| Static page or layout | Server (build machine) | Once, at build time |
| Dynamic page or layout | Server | On every request |
| Server action / API route | Server | When invoked |
| Client component | Browser | On render and interaction |
One nuance: client components also execute once on the server per page render to produce the initial HTML (server-side rendering), then hydrate in the browser.
What this series proves
Each chapter demonstrates one of these ideas hands-on, continuing the project from the Quick Start:
- Pages and Layouts: routing with files
- Server and Client Components: the component model and the 'use client' boundary
- Static and Dynamic Rendering: declaring rendering modes and observing freshness
- Building for Production: seeing the model hold in a real build
