Choosing an application model and a rendering strategy

Objectives

By the end of the lesson, you can justify the choice of the application model (MPA or SPA) and the rendering strategy (SSG, SSR, CSR, or hybrid) for a given task, and you can list the considerations of the decision.

Why is there no "best" solution?

The lessons so far have shown different solutions: the navigation differs, the rendering differs, and each gains something and loses something. The summary of web.dev is also that the bottleneck must be measured first, a static or server-side solution is often enough, and minimal JavaScript helps preserve interactivity. The choice depends on what content has to be displayed, how often it changes, how much interaction is needed, and what should happen on a slow or missing network.

Three different tasks

• The official course description of the university is the same for many people, changes rarely, and it is important that it can be read from a direct link. A statically generated, multi-page structure fits it well.
• The enrolment interface needs fresh place data and a server-side decision: here HTML produced on request, an API refresh, or a hybrid solution can make sense.
• A shared diagram editor involves lots of local interaction and continuous data exchange: it is more natural as a client-side application.

These are examples, not mandatory technology requirements.

flowchart TD
    C[User task] --> T[Freshness of the content]
    C --> I[Amount of interaction]
    C --> N[Navigation and shareability]
    C --> O[Offline need]
    T --> V[Application and rendering decision]
    I --> V
    N --> V
    O --> V

Two separate decision axes

1. Navigation (MPA–SPA): for a view change do we usually request a new document (6.1), or does the client program swap the view?
2. Rendering (SSG–SSR–CSR): where and when is the initial important content produced: in advance (6.4), on the server at request time (6.3), or in the browser (6.2)?

The two decisions are related but do not merge. Possible combinations:

	SSG (in advance)	SSR (at request time)	CSR (in the browser)
MPA	static site, HTML per page	server-side pages, every navigation is new HTML	the pages are empty, the browser fills them
SPA	prerendered initial view, then client navigation	server-side initial view, then client navigation	classic SPA: skeleton + program + API

Separate parts of the application can also get different answers. The course description can be static, the number of free places can be refreshed from the API, and the checking of the form can partly happen in the browser. The actual enrolment must be accepted or rejected by the server. "Hybrid" is not complexity for its own sake: it is justified when the freshness and interaction needs of the parts really differ.

Considerations of the decision

1. First usable content: for a page meant for reading, the essential text should appear as soon as possible (chapters 9 and 10).
2. Interaction: frequent view changes and local editing call for more client-side program.
3. Freshness: a static description and the momentary number of places need different handling (6.4).
4. Shareability and navigation: the URL of a specific course must work after a refresh and on another device too (6.5).
5. Searchability and previews: if the search engine and the link preview must see the content, it should be in the raw response (6.2, chapter 9).
6. Offline need: a service worker is needed, and the boundary of offline must be defined (6.6).
7. Devices and network: a large amount of JavaScript reacts later on a weaker device.
8. Operations and team: static serving can be simple and cheap, SSR asks for server capacity and monitoring.

There is no strategy without a compromise: if we do heavy server-side work on every request, the response time grows; if with static content the refresh of publication is poor, old data stays published; if we build on a lot of JavaScript, the first usable state can be late.

Worked example: the architecture of Kurzuspont

Part	Navigation	Rendering	Reason
Regulations, semester course descriptions	MPA	SSG	Changes rarely, searchable, fast from the CDN.
Course page with the number of free places	MPA	SSG + API refresh (hybrid)	The description is static, the number is live.
Enrolment interface	SPA	CSR, the initial view with SSR	Fast filtering and feedback; the server decides on the enrolment.
"My enrolments"	part of the SPA	CSR or SSR	Personal, cannot be cached in common.
Course material readable offline	Any	+ service worker	Cache for the material already seen.

It can be seen that a real system is rarely a single strategy: we make the decision part by part, according to the needs of the task, and always document what we gained and what we gave up.

Common misconceptions

Statement	Clarification
"An SPA is always modern, an MPA is outdated."	A different navigation model suits a different task.
"SSG is good only for simple pages without interaction."	Dynamic elements can also work next to static HTML.
"SSR is faster than CSR in every case."	The work of the server, the network, and the client counts together.
"A service worker solves every offline problem."	Only the planned, storable content and operations work.
"Hybrid is always better, because it combines."	Only if the needs of the parts really differ; otherwise it is needless complexity.

In brief

• Two separate decisions: navigation (MPA–SPA) and rendering (SSG–SSR–CSR); they can be freely combined.
• The considerations: first usable content, interaction, freshness, shareability, searchability, offline need, devices and network, operations.
• The parts of a system can get different strategies; hybrid is justified when the needs differ.
• There is no strategy without a compromise: document what you gained and what you gave up.

Review questions

1. Which two decisions must be made separately when designing a new web application?
2. Why do MPA and SSG fit the page of regulations?
3. When is hybrid rendering justified for the enrolment interface?
4. What does a service worker not solve in the case of enrolment?

Learning resources

• Rendering on the Web (web.dev) — an overview of the options and their trade-offs.