Introduction
In the first part of this series, we looked at the early web — a world of full-page reloads, where servers did most of the heavy lifting: from routing and rendering to data handling and UI feedback.
But then something changed.
A new technique emerged that allowed web pages to update without refreshing the entire page. This wasn't a new programming language. It was a new approach, and it reshaped how users interacted with the web.
This is where AJAX enters the story.
What Is AJAX?
AJAX stands for Asynchronous JavaScript and XML. But don't let the name fool you — it's not limited to XML, and it's not a library or framework. It’s a combination of technologies:
- JavaScript (to make the request)
XMLHttpRequest
(the API, now replaced byfetch
)- The browser’s ability to update specific parts of the DOM dynamically
It allowed browsers to send and receive data asynchronously without refreshing the entire page.
Suddenly, the web became interactive.
Why It Was Revolutionary
Before AJAX:
- You submitted a form → server responded → whole page reloaded
- You clicked a link → entire page refreshed with new content
With AJAX:
- You could fetch new data and inject it directly into the DOM
- Forms could submit in the background, with dynamic error/success messages
- Pages felt smoother, faster, more app-like
AJAX didn’t just reduce load times — it redefined user expectations.
What Changed Architecturally?
With AJAX in the picture, the backend still handled persistence, routing, and business logic, but now, the frontend took responsibility for part of the experience:
Responsibility | Before AJAX | With AJAX |
---|---|---|
Routing | Server | Server |
Data Fetching | Server | Browser (via AJAX) |
Data Mutation | Server | Still server-side |
Rendering | Server | Partial, in browser |
UI Feedback | Server | Browser (JS) |
The frontend began to split off from the backend. Not completely — but it was enough to spark the shift.
Real-World Example: A Live Search Box
Before AJAX:
- User types a query → submits a form → server responds with a new page
With AJAX:
- User types → browser sends an AJAX request on each keystroke → results appear below instantly without reload
This kind of fluid experience became common across Gmail, Facebook, Twitter — it was the beginning of the dynamic web.
The Rise of jQuery
AJAX wasn’t always easy to work with — XMLHttpRequest
was verbose and inconsistent across browsers. Enter jQuery, which made AJAX far more accessible:
$.get('/api/posts', function(data) {
$('#post-list').html(data);
});
With just one line, you could fetch and display content dynamically. jQuery became the way to do AJAX — and shaped frontend development for years.
jQuery Took Over the UI
jQuery didn’t just make AJAX easier — it also transformed how developers built UIs.
With just a few lines of code, you could:
- Show and hide elements
- Create dropdowns, modals, tabs, sliders
- Animate DOM elements
- Dynamically inject HTML
$('#message').text('Form submitted!').fadeIn().delay(3000).fadeOut();
Suddenly, the UI felt alive. You didn’t need to reload pages or write verbose vanilla JS to get interactivity. Everything was instant and visual.
This era saw the explosion of interactive forms, live validation, auto-suggest inputs, infinite scroll, and even single-page-feeling dashboards — all thanks to jQuery combined with AJAX.
It was the first time the frontend really started owning the user experience, not just displaying what the server sent.
What We Learned
The introduction of AJAX taught us a few important things:
- Not everything needs to be re-rendered.
- Users prefer speed and continuity.
- The browser is capable of doing more.
This was the moment developers started thinking, "If I can fetch and inject data like this, why not go further?"
And that’s exactly what came next.
Why This Phase Matters
This phase of the web wasn’t just about making things faster. It introduced a mental shift:
- From page-based thinking to component-based interactions
- From wait-and-refresh to real-time feedback
It also laid the groundwork for the Single Page Application (SPA) revolution that followed — where everything would eventually be handled on the client side.
In Part 3, we’ll dive into SPAs — how JavaScript took over rendering, routing, and the entire frontend experience. The good, the bad, and the heavy bundles.
If you found this post helpful, consider supporting my work — it means a lot.
