Jan Mikoláš
Glossary
Client-side rendering
CSR moves a large part of rendering into the browser. It enables rich interactions but requires careful management of application startup, loading states, errors, performance on weaker devices, and the accessibility of dynamic changes.
Short definition
JavaScript creates content only after it runs on the client.
With client-side rendering, the browser first downloads HTML, CSS, and JavaScript. Once the application starts, JavaScript loads data from an API, processes state, and creates the corresponding DOM. Visitors may therefore initially see a loading state, skeleton, or only the basic shell, followed later by the actual dashboard, list, or detail.
CSR is not the same as every use of JavaScript. A server-generated page with one interactive filter can still use SSR. CSR is not automatically bad for SEO either, but the design must deliberately account for access to content by users without scripts, search engines, and browsers on weaker devices.
The problem it solves
A rich interface assembled from current data in the browser
CSR is practical when a screen changes frequently in response to user actions and the application needs to maintain multiple items of local state.
- a dashboard for orders, revenue, alerts, and integration statuses
- an administration interface with filters, selections, and editing without leaving the working context
- a client over an API used simultaneously by a website, mobile application, and internal tool
- progressive loading of widgets by role, selected tenant, or open section of a screen
- interactive visualisations, configurators, and work panels with complex UI state
Practical example
A dashboard loads sections independently according to the current state
After JavaScript starts, the dashboard displays each block in a loading state. It then loads the order overview, revenue, and synchronisation status separately. Failure in one section must not lock the other blocks or tell users that a value is current when it is not.
Received data is checked before display, and text is written with a safe text API rather than as untrusted HTML. Hiding a section on the client is only a convenience; the API must verify the user, tenant, and permissions for the requested data again with every request.
JavaScript
const summary = document.querySelector('[data-summary]');
summary.textContent = 'Načítám přehled…';
const response = await fetch('/api/dashboard/summary');
if (!response.ok) throw new Error('Přehled nelze načíst.');
const data = await response.json();
summary.textContent = `Nové objednávky: ${data.newOrders}`;How it works
From a page shell to content created in the DOM
CSR adds intermediate steps between opening a URL and displaying data. Each requires a corresponding state and resilience to failure.
- The server returns an initial document It contains at least basic HTML and links to CSS and JavaScript modules or a bundle.
- The browser loads and runs the script The application initialises; a large bundle or weak device can slow this step.
- The client evaluates the URL and state The router or components determine which data and screen are needed and display an intermediate state.
- The application calls the API An HTTP request returns data or an error. The browser handles the network and CORS, while the server still verifies access.
- JavaScript creates the DOM The result is rendered, focus is preserved or moved, and any important change is announced to assistive technologies.
Key concepts
Application startup, state, and progressive loading
Client-side rendering offers flexibility, but without clear states users only see a blank or constantly changing screen.
HTML shell
The server’s initial response. It can contain navigation and a fallback, but in pure CSR may not yet include the screen’s main data.
Loading and skeleton
An intermediate state explains what the application is doing. A skeleton should not merely mimic content or obscure that the data is not yet available.
Lazy loading
Code and data for a less frequently used section load only when it is used. The design must handle a failed chunk and network changes during navigation.
Runtime validation
Source-code types do not guarantee the shape of an HTTP response. Data from APIs, URLs, and storage is checked before trusted use.
Fallback
An important feature can have a server alternative, a brief explanation without JavaScript, or a clearly stated requirement for a supported browser.
Benefits and limitations
A flexible interface in exchange for demands on client performance and resilience.
Benefits
- rich interactions and local state without the server repeatedly assembling the entire page
- the ability to load data and modules separately for the current screen
- a shared API contract for multiple clients
- fluid updates to parts of the interface when states are managed correctly
Risks and common mistakes
- a blank or incomplete screen when JavaScript is slow
- a large bundle and demanding rendering on a weaker device
- a response race in which an older request overwrites a newer filter
- unannounced DOM changes or lost focus
- treating a client-side role or cache as proof of authorization
When it makes sense
For work interfaces with frequent state changes and a clear API contract.
CSR is often suitable for a dashboard, administration interface, or tool where users work with filters, forms, and different panels for extended periods. The benefit appears when the application can load data progressively, recover from errors, and avoid forcing users to download all code for the first simple view.
Server rendering may be simpler and more resilient for public content, a simple form, or a page that must be fully usable without JavaScript. CSR is chosen not because a client application is always more modern, but when its interactions provide real value.
What to consider
Time to usable content matters more than merely loading the bundle.
The quality of CSR becomes apparent on an ordinary phone, during an API outage, and when the interface is used without a mouse.
- measure load time, JavaScript execution, and the display of genuinely usable content
- model loading, error, empty, and ready as distinct and comprehensible states
- cancel obsolete requests or check response order when filters change rapidly
- manage focus and announce significant screen changes to assistive technologies
- treat data from APIs and URLs as untrusted and also validate it on the server
Common questions
CSR in practice
Is CSR the same as an SPA?
No. CSR describes where the main content is created. An SPA describes navigation in a running client application; it may have a server-rendered initial page or a hybrid mode.
Is CSR automatically bad for SEO?
No. It depends on the type of content and technical solution. SSR or static output is suitable for some public routes, while other pages may be intended only for authenticated work.
Does client-side validation replace API checks?
No. The client uses it for rapid feedback. The server must validate data, verify identity, and authorize the specific operation and record.
Why can a dashboard be slow after the page loads?
In addition to network traffic, the browser must download and process JavaScript, create the DOM, and load data. Delays can arise in any of these layers.
How I work with applications in practice
I design client state together with the API and server-side rules.
For internal and e-commerce interfaces, I address behaviour during loading, errors, and data changes together with a secure backend contract.