Every web application splits its work between server and browser somewhere. Where you draw that line decides how much JavaScript you write, how the app feels to use, and how hard it is to keep working. This card walks the spectrum from classic multi-page apps to full single-page apps, explains where we usually land and why — and prepares you for the JavaScript cards that follow.
Important
Work on this lesson in
teachermode.
Learning goals
- You can explain the three main web architectures — multi-page app (MPA), progressively enhanced MPA, single-page app (SPA) — and how each splits work between server and browser.
- You can name the main advantages and costs of each architecture, e.g. in complexity, amount of code, UI fidelity and time to first result.
- You can explain what a hybrid looks like, such as a server-rendered page with an "island" built in SPA technology like React.
- You can explain why progressive enhancement is our default for most requirements, and in which situations an SPA is the better choice.
- You can recognize which architecture an existing app uses by looking at how it handles links, forms and page updates.
The spectrum
Multi-page app (MPA). The server renders complete HTML pages. Every link and form submission loads a new page. The browser does almost nothing but display. This is how Rails works out of the box: simple, robust, fast to build, easy to test with a real browser. The price is that every interaction is a full page load, which limits how fluid the UI can feel.
Progressively enhanced MPA. Still server-rendered HTML, but a small JavaScript layer swaps page fragments instead of reloading, handles forms without a full round trip, opens overlays, keeps scroll positions. Libraries in this family: Unpoly (our choice), Hotwire/Turbo (the Rails default), htmx. You keep the MPA's simplicity — one source of truth on the server, one templating language — and gain most of the interactivity users expect. This is our default.
Single-page app (SPA). The browser loads one HTML shell and a JavaScript application that renders everything; the server becomes an API that speaks JSON. Frameworks: React, Vue, Angular, Svelte. The ceiling for UI fidelity is highest here — complex interactive editors, dashboards that update live, offline behavior. The costs are real: two applications instead of one (frontend and API), duplicated logic such as validations and authorization, state management, more code, more build tooling, and a much harder testing story.
Hybrids. The line isn't binary. A server-rendered app can embed an island: one region of a page mounted as a React component, with the rest of the page staying plain HTML. That gives you SPA fidelity exactly where a requirement needs it, without turning the whole app into an SPA. Later in the curriculum you build such an island yourself.
The short version: SPAs trade a higher UI-fidelity ceiling for more complexity and more code. We are not against SPAs — we build them where they make sense — but for most requirements a progressively enhanced MPA delivers what the customer needs at a fraction of the cost.
Resources
Read what's new to you, skim what's familiar, skip what you already master. Stop when you can meet the learning goals.
Your agent can also generate an overview, a tutorial or an explanation for anything here, tailored to what you already know. Just ask.
- 📄 Rendering on the web Show archive.org snapshot — the spectrum from server rendering to client rendering, with the trade-offs in one diagram
- 📄 MDN: Progressive enhancement Show archive.org snapshot — the principle in one page
- 📄 Hypermedia-driven applications Show archive.org snapshot and When to use hypermedia? Show archive.org snapshot — the case for progressively enhanced MPAs, from the htmx authors, including where it stops fitting
- 📄 Islands architecture Show archive.org snapshot — Jason Miller's original description of a server-rendered page with interactive islands
- 📄 The best of both worlds: progressively enhanced hybrid applications Show archive.org snapshot — MPA shell, SPA-style islands
- 📄 Unpoly Show archive.org snapshot — the homepage shows what a progressively enhanced MPA can do
- 📄 Limits of Hypermedia Show archive.org snapshot — internal slides: where progressive enhancement stops being enough. There is no recording yet; Henning will give you this talk in person, including the demos
Discuss with your mentor
- For each of the three architectures, name one kind of application where it is clearly the right choice.
- Think of an app you use daily. Which architecture is it, and how can you tell?
- Where would you draw the line for MovieDB as it is today — and what feature would make you reach for an island?
