Jan Mikoláš
Glossary
AJAX
AJAX improves interface responsiveness without reloads. It does not mean XML, a specific library, or a security boundary between the browser and backend.
Short definition
A background HTTP request and a targeted interface update.
The name AJAX originated from Asynchronous JavaScript and XML. Today, however, applications commonly use the Fetch API or XMLHttpRequest and receive JSON, an HTML fragment, or another format. The important point is that the user need not wait for the entire page to reload while the browser processes a separate HTTP request.
AJAX is neither a specific interface nor an application architecture. The Fetch API is one tool, a REST API can be the remote contract, and a single-page application is a broader navigation model. Even with an asynchronous call, the server still validates inputs, identity, and permissions; frontend logic is easily bypassed by a direct request.
What it is used for
Working with data continuously without unnecessary reloads
A well-designed asynchronous element keeps a clear HTML path and simply enhances it with a faster response.
- filtering and paginating a list of orders or products
- loading availability, price, or a variant after the user changes a selection
- submitting a form with a visible saving state and errors beside specific fields
- search autocomplete with request rate limiting
- refreshing a small part of a dashboard without waiting for an entirely new HTML response
Practical example
Filtering orders after a status change
The user changes a filter and the interface displays a loading state. JavaScript creates a URL using URLSearchParams, checks the HTTP response, and inserts the result as text into the existing list. If an error occurs, the previous result remains readable and the user is given a clear way to retry the action.
The example deliberately does not store a token in the URL or use innerHTML for API data. Validating the filter on the client is only a convenience; the server must check the same value and verify authorization for a protected list.
JavaScript
const params = new URLSearchParams({ status: 'paid' });
const response = await fetch(`/api/orders?${params}`, {
headers: { Accept: 'application/json' },
});
if (!response.ok) throw new Error('Objednávky nelze načíst.');
const { items } = await response.json();
results.textContent = `${items.length} objednávek`;How it works
Text diagram: user action → HTTP request → loading → response or error → safe DOM update
Every visible asynchronous step needs a state before sending, during loading, after success, and on error.
- The user triggers an action They change a filter, submit a form, or open part of a detail view. A native link or form can remain a functional fallback without JavaScript.
- The client prepares the request JavaScript constructs the method, URL, headers, and, where applicable, body according to the API contract. It must serialise parameters and inputs safely rather than concatenating strings blindly.
- The interface announces loading The user sees that an operation is in progress and unintended duplicate submissions are prevented where appropriate. A change of state is suitably announced to assistive technologies.
- The backend evaluates the operation The server checks authentication, authorization, CSRF protection for cookie-based sessions, and validation. A technically successful request can return a business validation error.
- The client processes the result It checks both the HTTP status and the expected data shape, updates the DOM safely, and offers a comprehensible error state. An older response that arrives later must not overwrite a newer filter.
Key concepts
An asynchronous request is only part of the user flow
To represent its state truthfully, an interface must account for timing, errors, and operation without JavaScript.
Fetch API and XMLHttpRequest
Both browser APIs can call HTTP asynchronously. The Fetch API is a modern Promise-based interface; AJAX is a broader term for the approach, not the name of one function.
Loading, empty, and error states
Loading, no results, and failure are all normal outcomes. Users must know whether data is still being retrieved, truly absent, or unavailable.
Response order
When a filter changes quickly, an older request may finish after a newer one. The application cancels it, assigns it a version, or ignores it to avoid showing an incorrect result.
Debouncing and cancellation
Searching after every character can place unnecessary load on an API. A short debounce and AbortController help, but must not hide a state the user has already submitted.
Safe rendering
Text from an API belongs in a text API or verified component. Inserting HTML without validation can execute unexpected content and create an XSS risk.
Benefits and limitations
A smoother interface in exchange for more states that must be designed
Benefits
- fast updates to part of a page without a full reload
- better responsiveness for filters, forms, and progressively loaded details
- the ability to show progress and offer retries after a transient error
- separation of the user interface from a documented API contract
Common mistakes
- failing to show loading, an empty state, or a comprehensible error
- assuming that every response arrives in the order in which it was sent
- inserting untrusted data through innerHTML
- treating validation in the browser as sufficient backend protection
- removing a functional link or form merely because the application expects JavaScript
When to use it
For a focused interaction that needs fast, clear feedback.
AJAX is suitable for an order filter, an availability check, or saving a small change in an administration interface, for example. It provides value when the update genuinely saves users time while keeping the interface understandable. Basic navigation and forms need not be rewritten with complex scripts without a reason.
For frequent server-initiated changes, WebSocket or another live-event technology is worth considering. An important data change also requires idempotency, retries, and a consistent business outcome; an asynchronous request alone does not provide them.
What to consider
A good asynchronous interaction is visible, secure, and recoverable.
The user interface should state exactly what is happening, while the backend must protect the operation regardless of browser behaviour.
- design loading, success, empty, validation, and technical failure states
- preserve an accessible HTML path, correct focus, and announcements of relevant changes
- validate input on the server, authorize the specific resource, and protect cookie-based forms against CSRF
- handle timeouts, cancellation, retries, and races between responses according to the operation’s meaning
- render data safely and measure error rates, latency, and repeated requests
Common questions
AJAX without historical shortcuts
Does AJAX require XML?
No. XML appears in the historical name, but today’s applications often transfer JSON. AJAX describes asynchronous communication and a partial page update, not a specific format.
Is the Fetch API the same as AJAX?
The Fetch API is a specific browser interface for network calls. AJAX is the broader approach of using such a call without a full page reload.
Is AJAX secure if I validate the form in JavaScript?
Not by itself. Client code can be bypassed. The server must validate input, identity, and permissions and usually also protect cookie-based sessions against CSRF.
Why does an older result appear after rapid filtering?
Network responses need not arrive in the same order as requests. The client must cancel the previous request or verify that the response still belongs to the current filter.
How I connect frontends and APIs in practice
I build interactions on a clear contract, safe rendering, and visible states.
When working with e-commerce and internal systems, I address slow networks, invalid input, server errors, and repeated user clicks.