Multi-page and single-page web applications

Objectives

By the end of the lesson, you can tell a multi-page and a single-page application apart by the way of navigation, you can explain the role of deep links and history, and you know that this decision is not the same as the rendering strategy.

Why two models?

The web was originally built from documents: clicking a link, the browser requests a new document (1.2). For an application-like web this model can be inconvenient: a mail client does not want to reload everything at every click. Developers therefore use two kinds of structure, and both have their place. The difference shows in the user's path, in the tasks of the server and the client, and in error handling.

Two versions of a course catalogue

The student opens a course list, then clicks on the details of a course.

• Multi-page version: the browser navigates to the address of the details (/kurzusok/webprog), and receives a new HTML document.
• Single-page version: after the initial load the JavaScript of the application handles the click, requests data from the API, and swaps the visible view within the current document.

In both versions a distinct URL can exist for the course, and both can be interactive.

flowchart TB
    U[Click on the course] --> M[Multi-page: new HTML request]
    U --> S[Single-page: client-side view change]
    M --> L[Details visible]
    S --> A[Data request if needed]
    A --> L

The diagram shows typical operation, not a rule: a multi-page site can also have JavaScript updates, and a single-page application can request a complete document from the server on first opening.

Multi-page application

In an MPA (Multi-Page Application) the different pages mostly have separate document responses. The server can produce HTML for every navigation, or serve a static file. The known behavior of the browser (links, history, the Back button, bookmarks) works by itself. Loading a new document means network and rendering work, but a full reload is not automatically slow: the cache, the server, and the size of the page also matter.

A news portal or a simple course catalogue can work well this way. Addressable content and a standalone HTML document are a particular advantage. The model does not mean that every operation involves a full reload: a filter can work with JavaScript here too.

Single-page application

In an SPA (Single-Page Application), after the initial load JavaScript takes over a significant part of the view changes: it requests data through an API, then modifies the DOM (3.2). The switch can be fast and continuous, but startup needs more client-side work: the program has to be downloaded and run. Faulty or slow JavaScript can also block access to the content, if every view depends on it.

Because the browser does not load a new document, the SPA itself has to provide what the browser gives for free in an MPA:

• the URL should change along with the view, so that the address can be shared;
• the Back button should lead to the expected view;
• a deep link (the direct address of an internal view) should lead to a meaningful view after a refresh or on another device.

The browser's History API makes these possible: according to MDN, pushState adds a new history entry, replaceState overwrites the current one, and the popstate event fires on Back/Forward. Changing the URL does not load a new document and does not paint the view: the application must do that.

Not the same as the rendering strategy

The MPA–SPA difference is about navigation: we request a new document, or the client swaps the view. Client-side, server-side, and static rendering describe where and when the HTML or the visible view is produced (6.2–6.4). The two axes can be combined: the pages of a multi-page site can be pre-produced HTML, and the first page of an SPA can arrive as HTML produced on the server. Mixing up the two axes is a common misconception.

Worked example: two pages of Kurzuspont

Page	Likely model	Reason
Course descriptions, regulations	MPA	Meant for reading, easy to link, searchable.
Enrolment interface (filtering, basket, instant feedback)	SPA or hybrid	Frequent, quick view changes, a lot of local state.
Shared study-group editor	SPA	Continuous interaction.

On the same site the two models can live side by side: the catalogue can be an MPA, the enrolment interface an SPA, and the transition between them an ordinary link.

Common misconceptions

Statement	Clarification
"An MPA cannot be interactive."	A multi-page site can also use JavaScript and APIs.
"An SPA requests a new HTML document at every click."	It often swaps the view within the existing document.
"An SPA is always faster."	The first load, the running of the program, and the data request also count.
"MPA or SPA automatically determines the rendering."	The navigation model and the rendering strategy are separate decisions.
"An SPA has no need for a URL."	Because of sharing, refreshing, and history, the URL is part of the state.

In brief

• MPA: navigation requests a new document; SPA: the client swaps the view on the loaded page.
• An SPA must itself manage the URL, the history, and deep links (History API).
• For deep links the server must also support the internal paths.
• The navigation model and the rendering strategy are two separate decisions.

Review questions

1. What is the difference between the click handling of an MPA and an SPA?
2. What does pushState do, and what does it not do?
3. Why can an internal link of an SPA get a 404 on refresh?
4. How does the MPA–SPA choice differ from the choice between client-side and server-side rendering?

Learning resources

• History API (MDN) — programmatic handling of the history.
• Rendering on the Web (web.dev) — an overview of the rendering options.