What are the advantages and disadvantages of using AJAX?

TL;DR

AJAX (Asynchronous JavaScript and XML) is a technique in JavaScript that allows web pages to send and retrieve data asynchronously from servers without refreshing or reloading the entire page.

Advantages

• Partial updates: The page can update selected regions without a full navigation, which can make interactions feel faster.
• Potentially smaller transfers: An endpoint can return only the data needed for an update instead of another complete document.
• Preserved in-page state: Inputs, scroll position, and other client state remain in place because the document is not replaced.

Disadvantages

• Asynchronous complexity: Applications must handle cancellation, errors, retries, race conditions, stale responses, and loading states.
• State and navigation design: URLs, browser history, caching, and indexability do not follow automatically from an in-page request.
• Client-side cost: Extra JavaScript, rendering, and state management can offset savings from smaller responses.
• Security risks: Untrusted response data must be handled safely; inserting returned HTML can introduce XSS.

AJAX (Asynchronous JavaScript and XML)

AJAX (Asynchronous JavaScript and XML) is a technique in JavaScript that allows web pages to send and retrieve data asynchronously from servers without refreshing or reloading the entire page. When it was first created, it revolutionized web development and resulted in a smoother and more responsive user experience. AJAX is explained in detail in this question.

Here's a breakdown of AJAX's pros and cons:

Advantages

• Partial page updates: An application can replace only the affected UI instead of navigating to and rendering another complete document. This often improves perceived responsiveness.
• Targeted payloads: A purpose-built endpoint can return only the data required for an update, reducing transferred bytes compared with a full HTML response. This is a possible design benefit, not an inherent reduction in server work.
• Preserved client state: Because the document stays loaded, form inputs, scroll position, media playback, and other in-page state can remain intact.
• Dynamic updates: Data can be refreshed independently of navigation, which is useful for chat, dashboards, collaborative editing, and notifications.
• Form validation: AJAX can be used for client-side form validation that requires back end interactions (e.g. checking for duplicate usernames), providing immediate feedback to users without requiring a form submission request. This improves the user experience and avoids unnecessary full page reloads for invalid submissions.

Disadvantages

• Asynchronous coordination: The client must handle loading and error states, retries, cancellation, duplicate requests, stale responses, and race conditions. Long-lived pages can also display outdated data unless refresh and invalidation rules are explicit.
• No automatic performance win: More requests, larger client bundles, client-side rendering, or chatty APIs can increase network, server, and device work. Measure the complete interaction rather than assuming AJAX is faster.
• Navigation and discoverability: In-page updates do not automatically create meaningful URLs, history entries, or indexable documents. Use the History API or a router, and choose server rendering or progressive enhancement when those requirements matter.
• Security concerns: Authentication, authorization, CSRF protections, validation, and output encoding still apply. Inserting response strings as HTML without sanitization can introduce XSS.
• JavaScript and accessibility requirements: If a feature must work without JavaScript or with assistive technology, provide an appropriate fallback and announce dynamic updates where necessary.

AJAX is a useful interaction technique, not a performance guarantee. Its value depends on payload design, client-side cost, accessibility, and how deliberately the application handles state, navigation, and failures.

Is AJAX still relevant today?

Mostly as a historical term. The technique it described—fetching data without a page reload—is standard in modern web applications. New code commonly uses fetch(), JSON, and promises instead of treating XMLHttpRequest, XML payloads, and callbacks as one named stack.

Here is what changed:

The pattern AJAX introduced is alive: async data loading without a full page reload is now the default expectation. The underlying technology has moved on.

Using "AJAX" today to mean "we make a fetch call from JavaScript" is loose but generally understood. fetch() is usually the default for new code; XMLHttpRequest remains relevant when its event-based behavior is required, such as portable upload-progress reporting.

The modern equivalent: fetch() with async/await

Side-by-side, classic AJAX vs current best practice:

// Classic XHR (~2005-style)
const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/users');
xhr.onreadystatechange = function () {
  if (xhr.readyState === 4 && xhr.status === 200) {
    const users = JSON.parse(xhr.responseText);
    render(users);
  } else if (xhr.readyState === 4) {
    showError();
  }
};
xhr.onerror = function () {
  showError();
};
xhr.send();

// Modern fetch + async/await
async function loadUsers() {
  try {
    const res = await fetch('/api/users');
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    const users = await res.json();
    render(users);
  } catch (err) {
    showError(err);
  }
}

The modern version is shorter and composes naturally with Promise.all and AbortController. Data-fetching libraries can add caching and request deduplication when an application needs them. One reason some code still uses XMLHttpRequest is its straightforward xhr.upload.onprogress event; browser fetch() does not expose an equally portable upload-progress event. Request-streaming support and required options vary by browser, so check the target environments before building progress reporting on streamed request bodies.

Re-examining the disadvantages

Several historical limitations now have well-supported solutions, but AJAX itself does not apply those solutions automatically:

• SEO challenges: Major search engines can render JavaScript, and modern frameworks offer SSR and SSG for content that needs to be indexable. Choose the rendering strategy intentionally; not every crawler executes JavaScript reliably or promptly.
• Bookmarking and back-button issues: The History API (pushState and the popstate event) and modern routers provide the necessary tools. The application still has to map meaningful state to URLs and history entries.
• Browser support: Standardized APIs have removed most historical inconsistencies for modern support matrices. Compatibility is still a project requirement, so verify the specific APIs and environments the application targets.
• Reliance on JavaScript: Many applications intentionally require JavaScript. When no-JavaScript operation, resilience, or progressive enhancement is a requirement, provide a server-handled path instead of assuming AJAX will work.

The disadvantages that genuinely remain are about complexity and security: race conditions and stale state, error handling in async code, XSS via innerHTML from API responses, and the ongoing complexity of state management. These are real, but they are problems of any client-side data fetching, not specifically of AJAX.

Further reading

• Ajax | MDN
• Fetching data from the server | MDN

Exercises