Jan Mikoláš
Glossary
Frontend
The frontend turns system data and actions into a clear interface. The user controls their own device, however, so the frontend cannot be the application's security boundary.
Short definition
The interface a person works with directly.
The frontend displays data, accepts input and communicates with the backend. It can be traditionally rendered as HTML on the server, enhanced with a few JavaScript interactions or built as a separate client application on top of an API.
Frontend is not a synonym for design or for a specific framework. In addition to visual presentation, it handles accessibility, responsiveness, interface state, loading, validation for user convenience and clear presentation of errors.
Full-stack development includes frontend work, but a dedicated frontend specialty can go much deeper into accessibility, performance, and design systems for a complex interface.
The problem it solves
It makes application functionality accessible to people
The frontend translates technical system state into controls that work on different devices and under less-than-ideal network conditions.
- displaying catalogues, orders, inventory levels and details in an administration interface
- forms, filtering, navigation, search and confirmation of user actions
- accessibility for keyboards, screen readers and different screen sizes
- communicating with an API or submitting a traditional HTML form
- showing an operation in progress, validation errors and temporary service unavailability
Practical example
An administration interface loads and changes an order status
The frontend loads a list of orders, allows filtering and sends a request to the API when an action is selected. While waiting, it prevents a double click and shows that the change is being processed.
If the backend returns 403, the frontend does not invent an alternative route but reports insufficient permissions. For 409, it may offer to refresh the data because another user has changed the order in the meantime. The server still performs the final validation and authorization.
How it works
From a user action to a result in the interface
Each step has its own role: rapid client-side feedback cannot replace a server decision.
- The user takes an action They fill in a form, open a detail, change a filter or confirm an order change.
- The frontend checks basic input It can point out a missing value or invalid format before the user has to wait for a network request.
- The client sends a request A form or JavaScript uses HTTP and sends only the data needed for the operation.
- The backend decides The server verifies the input, identity and permissions again, then applies the business rules.
- The frontend displays the result It updates the state, explains an error or offers the next step without pretending that a change succeeded.
Important parts
Rendering, state and accessibility.
The technical solution may vary, but the core frontend responsibilities remain.
HTML, CSS and JavaScript
HTML carries structure and meaning, CSS controls presentation and JavaScript provides interactions. Each layer can support accessibility and resilience.
Server-side and client-side rendering
HTML can be assembled by the server or by the browser from API data. Neither approach is automatically better; the choice depends on the product and its operation.
Interface state
An open filter, unfinished form or loading indicator is local UI state. It is not by itself the source of truth for an order.
Accessibility and responsiveness
Semantic elements, focus, keyboard controls and clear errors belong in the normal design process, not in a later fix.
Safe rendering
User content is escaped for its context. Raw HTML, URLs and JavaScript strings each require a different safe procedure.
Benefits and limitations
User convenience cannot replace server-side checks.
Benefits
- rapid and clear feedback for the user
- an interface adapted to different devices and roles
- separation of presentation from application rules
- the ability to use the same backend for the web, a mobile application and integrations
Common mistakes
- treating a hidden button as authorization
- relying on client-side validation to protect data
- failing to escape content for its context and introducing XSS
- building a complex SPA for an interface that would be clearer as a server-rendered page
When it makes sense
Every application needs an interface; the degree of client-side complexity is a choice.
A simple portal can rely mainly on server-rendered HTML and a few forms. An administration interface with frequent filtering, long-running operations or multiple data sources may need richer client-side state and API communication.
Choosing React, Next.js or another technology does not define the frontend. A clear interface, accessibility, correct failure behaviour and a well-defined boundary with the backend matter more.
What to consider
The frontend must account for both the user and an unreliable network.
A good interface does not conceal a failure; it explains the state and does not pretend that the server succeeded.
- use semantic HTML, focus states and keyboard navigation
- display loading, errors and update conflicts clearly
- never store secrets or permission decisions only on the client
- escape and, where necessary, sanitise untrusted content
- test the interface on mobile, on a slow network and without relying on accidental state
Common questions
Common misconceptions about frontends
Does a frontend always run in a browser?
For a web application, typically yes. More generally, frontend means the user-facing part of a system, so it also exists in mobile and desktop applications.
Is server-rendered HTML part of the backend?
It is generated on the server but serves as the user interface, so it is part of the frontend. Implementation boundaries need not be physically separate.
Is React a frontend?
React is a library for creating user interfaces. A frontend can also be built without React or without a separate client application.
Can the frontend protect data?
It can improve usability and prevent unintended actions, but the backend must enforce security and business rules.
How I approach applications in practice
I design backend systems with the interfaces that use them in mind.
For e-commerce and internal applications, I connect the backend, APIs and data flows so the frontend can give users an accurate and clear result.