Thick vs. Thin Client
One of the most important architectural decisions in web development is where logic runs: on the client (browser) or on the server. This is the "thick client vs thin client" spectrum.
| Aspect | Thick Client (More in Browser) | Thin Client (More on Server) |
|---|---|---|
| Examples | React SPA, Gmail, Google Docs | Wikipedia, Craigslist, traditional forms |
| Initial load | Slow (large JS bundle must download and execute) | Fast (server sends ready-to-render HTML) |
| Navigation | Fast after load (no page reloads) | Each page requires a server round-trip |
| Works without JS | No — blank page without JavaScript | Yes — HTML works in any browser |
| SEO | Difficult (content generated by JS) | Easy (content in HTML from server) |
| Server cost | Lower (client does rendering) | Higher (server renders every page) |
| Security | Business logic exposed in client JS | Business logic stays on server |
| Complexity | High (state management, routing, build tools) | Low (request → process → respond) |
The Security Boundary
The most important line in web architecture is the trust boundary between client and server:
- The client is untrusted. Users can modify any HTML, CSS, or JavaScript. Browser DevTools make this trivial.
- The network is volatile and hostile. Delivery conditions change like the weather, and without HTTPS, anyone can read or modify data in transit.
- The server is where we have control and where truth lives. All validation, authorization, and business logic must run on the server if we are to trust it.
Where to validate: Always on the server. Optionally also on the client for UX (instant feedback for usability), but never only on the client. Simply put, we validate on the client for usability and the server for actual security.