05 — Engineering notes
Default to the server
Why most institutional pages should be rendered before they reach the browser, and where that rule stops.
Most of the sites I maintain are read far more often than they are interacted with. A program profile, a news item, an accreditation document, a list of lecturers — the common case is someone arriving from a search result, reading, and leaving.
For that case, a server-rendered page is the simplest thing that works:
- The content is in the first response.
- The page is readable if JavaScript fails.
- The HTML is what search engines and link previews see.
- There is no hydration step to get wrong.
None of that is novel. What is worth writing down is how often the opposite decision gets made for reasons that do not apply.
The pulling force
Client-side rendering is the default in a lot of modern stacks, and it is a good default for applications: dashboards, editors, exam runners, anything with continuous state. Once a team is comfortable in that model, it starts to feel like the normal way to build everything.
The cost shows up later:
- A content page that needs a spinner to show text.
- A blank screen when an API call fails.
- Metadata that has to be reconstructed for crawlers.
- A JavaScript bundle that grows with features most visitors never use.
The page still works, so nothing forces the issue. It just becomes slower and more fragile than it needed to be.
Where I draw the line
I use server rendering as the default and add client-side interactivity where a workflow genuinely needs it:
| Need | Approach |
|---|---|
| Public content | Server-rendered, cacheable |
| Forms and validation | Server action or endpoint, light client enhancement |
| Long-running interaction | Client component, explicit boundary |
| Offline behaviour | Client buffer with a server authority |
The exam platform is the clearest example of the last two rows. It needs a client-side runner and local answer buffering, but it still keeps the server as the authority on timing and submission. The public site around it does not need any of that.
What this is not
This is not an argument against React, Next.js, or client state. The exam runner is built in React because the interface is stateful and complex. The argument is against using a stateful architecture for pages that are documents.
A useful test: if the page would work as a printed sheet, render it as a document first and add behaviour only where the paper analogy breaks.
That test has saved me from a lot of unnecessary complexity.