Jan Mikoláš
Glossary
Single-page application
An SPA keeps an application running in the browser and changes its state during navigation. It is not automatically faster or more suitable than a multi-page application; it must handle URLs, errors, loading, and accessibility well.
Short definition
Navigation changes inside the running application rather than by replacing the entire document.
When first opened, an SPA receives basic HTML and JavaScript. Once running, its client-side router evaluates the URL, loads data from an API, and renders the corresponding screen. Moving from an order list to an order detail therefore often creates no new document request; instead, the application state and DOM change in the browser that is already open.
This model does not specify where the initial HTML must be created. An SPA can be rendered purely on the client, pre-rendered on the server, or hybrid. The defining aspects are primarily navigation and long-lived client state. The server remains the source of authoritative data, authentication, and authorization.
The problem it solves
Fluid work across multiple connected screens
An SPA is especially suitable where users work in one tool for a long time and frequently move between related data.
- an e-commerce administration interface with an order list, order details, inventory, and customers
- an internal SaaS application where users filter data, edit forms, and monitor multiple panels
- a dashboard with continuously loaded overviews, alerts, and integration statuses
- an interface over an API that needs to preserve filters, work in progress, and browser history
- progressive loading of less frequently used screens so that all code is not loaded at once
Practical example
An administration interface with a URL for every order detail
A user opens the order list, sets a filter, and navigates to an individual order. The router changes the URL to /orders/4821, loads only the required data, and moves focus to the heading of the new screen. The Back button restores the previous filter or at least the previous navigation state, rather than an arbitrary blank page.
When /orders/4821 is refreshed, the server must return the application or an appropriate HTML fallback. The client then reloads the current data and the server checks permission to access the order. Stored client state must not be the only evidence that the user may read it.
JavaScript
history.pushState({}, '', '/objednavky/4821');
main.replaceChildren(document.createTextNode('Načítám objednávku…'));
const response = await fetch('/api/orders/4821');
if (!response.ok) throw new Error('Detail objednávky nelze načíst.');
const order = await response.json();
main.textContent = `Objednávka ${order.number}`;How it works
Navigation in an SPA, from URL to a new screen
The diagram shows the basic flow. A specific framework may organise the steps differently, but responsibility for the URL and state remains.
- Initial load The browser receives HTML, CSS, and JavaScript. The application starts only after the required code has loaded.
- The router reads the URL It decides whether to show a list, detail, or form, while preserving the ability to open a specific address directly.
- Loading data and states The client calls an API and progressively displays loading, an empty result, an error, or data.
- Rendering and focus It updates the DOM, announces a significant change, and moves focus to a meaningful location, typically the content heading.
- History and recovery pushState and popstate enable Back and Forward. The server must also be able to accept a refreshed deep URL.
Key concepts
Router, state, and resilient navigation
An SPA determines more than how quickly a screen changes; it also determines how the application behaves when users go back, an error occurs, or a script fails.
Client-side router
Maps URLs to application screens. It does not replace a server route: the server must handle direct opening securely and verify access.
Deep link
A link to a specific detail must work when pasted into an email, opened in a new tab, or refreshed.
Lazy loading
A less frequently used part of the code loads only when the user navigates to the relevant screen. This shortens initial startup but adds further error and loading states.
Hydration
When the server delivers HTML and interactive JavaScript attaches to it on the client, this is hydration. It is neither a requirement for every SPA nor a synonym for routing.
Interface state
A filter, an unfinished form, or an open panel belongs to UI state. Orders, permissions, and prices are verified against the server.
Benefits and limitations
Fluid navigation in exchange for more complex client state.
Benefits
- fast transitions between frequently used screens without replacing the entire document
- the ability to preserve filters, selections, and unfinished state during navigation
- a unified interaction layer over an API and client components
- progressive loading of less frequently used parts of the application
Risks and common mistakes
- a large initial JavaScript bundle and a long wait for startup
- a broken deep-link refresh without a server fallback
- lost focus or an unannounced screen change for screen reader users
- the belief that hiding an action on the client constitutes authorization
- using an SPA for simple pages where it adds more complexity than value
When it makes sense
For extended, continuous work in an application, not as the default label for every website.
An SPA suits administration interfaces, work tools, and dashboards where users move between data while remaining in one working context. The benefit appears only when the application actually handles loading, errors, URL recovery, and accessibility better than a full reload.
A server-rendered multi-page application may be more straightforward for a content website, a simple catalogue, or a few independent forms. The choice should not respond to a framework’s popularity, but to the length of the user journey, network conditions, and the team’s ability to test client state.
What to consider
Navigation must be tested as a real user journey.
A high-quality SPA does not hide loading or failure and still respects the expectations users have of a conventional browser.
- test direct opening, refresh, Back and Forward, and sharing for every important URL
- provide loading, empty, error, and success states for every screen
- update the title, focus, and any screen-reader announcement when the screen changes
- leave authority over data, authentication, and authorization for a specific record with the server
- measure actual time to first display and navigation responsiveness on a weaker device and network
Common questions
SPAs in practice
Is an SPA automatically faster than a conventional website?
No. Subsequent navigation may feel fast, but initial loading, script size, and weaker devices can make the result worse. The specific user journey must be measured.
Is an SPA the same as client-side rendering?
No. An SPA primarily describes navigation and a running application. Content may be created on the client, on the server during the initial request, or in a hybrid mode.
Can an SPA work without JavaScript?
A purely client-side SPA generally cannot do so fully. A server fallback or progressive enhancement can preserve important paths, but they must be deliberately designed.
Does a client-side router handle permissions?
No. It can hide or redirect a screen for convenience, but the server must verify permissions for every read or change to protected data.
How I approach architecture in practice
I choose an interface based on the workflow, not a framework label.
For internal and e-commerce applications, I connect the UI, API, and data flows so that they remain understandable during normal work, errors, and outages.