Why start the XHR story before XHR?

XMLHttpRequest is often described as “the beginning of AJAX,” but the pressure that produced it built up earlier. From a web API perspective, the key question is:

What did browsers and servers expose as programmable interfaces between 1995 and 1998, and what did those interfaces make easy—or impossible?

In this period, the web’s “API surface” for app-like behavior mostly came from:

• HTML forms as the dominant way to send data to the server
• CGI and early server-side scripts as the dominant way to generate responses
• Browser scripting (JavaScript) as a way to validate input, manipulate the page, and trigger navigation
• Frames and later inline frames as a way to update part of a screen without repainting the whole window

None of this was “AJAX” yet, but it defined the constraints that XHR would later solve: send a request, get data back, update the page—without a full reload.

1995: Browser scripting arrives, but networking stays tied to navigation

JavaScript appeared in the mid-1990s and quickly became the first widely deployed way to program the browser. From a historical web API viewpoint, early scripting gave developers control over:

• Form events (like submitting, focusing fields, and basic validation)
• Window and document properties
• Navigation via things like updating a URL or triggering a form submission

But what scripting didn’t have was just as important: a first-class “make an HTTP request and give me the response body” API. If you wanted to talk to a server, the sanctioned path was still: submit a form or navigate.

This made the “request/response” model very coarse-grained. You could send data to the server and get back a page, but the browser didn’t yet treat network responses as something a script could directly consume and transform.

CGI and forms: the original web integration contract

In the same era, the most common server integration approach for interactive sites was CGI (Common Gateway Interface) or similar server-side scripting models. The pattern was straightforward:

1. User fills out a form.
2. Browser issues an HTTP request with form data (query string for GET, body for POST).
3. Server runs a program (CGI script) and emits an HTML response.
4. Browser replaces the current page with the new HTML.

As an early “web API contract,” forms and CGI were powerful—universal, simple, and compatible across browsers. But they forced a particular UX rhythm: click, wait, full refresh. Even if only one small part of the page needed updating, the entire document lifecycle restarted.

Developers tried to work around this by generating pages that were more dynamic on arrival (server-side rendering before the term was popular). But true interactivity—incremental updates driven by user actions—kept pushing against the limits of the available browser APIs.

1996–1997: Frames, partial refresh, and “page regions” as a workaround

As sites became more application-like, one of the most common hacks for reducing the pain of full-page reloads was to split the UI into separate documents using frames. The concept mattered historically because it introduced a practical idea that AJAX would later formalize:

You shouldn’t have to reload everything to update something.

With a frameset, you could keep navigation in one frame and update content in another. That wasn’t a data API, but it was a partial rendering API: you could target which document changed.

Later, the emergence and adoption of inline frames (standardized in HTML 4.0, published in the late 1990s) further reinforced “update a region” thinking. Instead of treating a page as one indivisible unit, developers began to treat the screen as a composition of independently loadable resources.

This mattered for XHR’s eventual reception: by the time XHR arrived, developers already understood the value of partial updates—they just wanted a cleaner, scriptable way to fetch data and apply it without embedding a whole new page inside a frame.

Early dynamic web techniques: what developers used instead of XHR

Between 1995 and 1998, developers used a mix of browser behaviors and nascent scripting capabilities to simulate “background” interactions. Some of these techniques became patterns that later AJAX libraries would refine.

1) Form submission triggered by script

If you could validate input in JavaScript and then submit the form programmatically, you could create slightly smoother experiences (for the time). But the response still replaced a page (or a frame). The network was not a first-class script object; it was a side effect of navigation.

2) “Image ping” requests

Another technique was to create a new image object in script and set its src to a URL that recorded an event. This sent a GET request without leaving the page. It was useful for analytics-style beacons, but it didn’t provide a usable response to the script. In web API terms, it was a one-way network call.

3) Script-tag loading (data as code)

Developers could also load external scripts dynamically. If the server responded with JavaScript code (rather than pure data), executing that code could update the page. This foreshadowed later “JSONP” ideas, even though the terminology and conventions came later. It was clever, but fragile: error handling, security boundaries, and data/code mixing were constant risks.

4) Frames and hidden targets

By targeting form submissions into a different frame, developers could keep the main UI intact while a subdocument changed. This could be taken further with a frame sized so small it was effectively invisible, turning the frame into a transport mechanism. Again, this was a workaround for the absence of a clean request/response API in script.

1998: XML becomes a big deal—and “data” starts to look separate from “pages”

A key ingredient in the rise of XHR was a change in how developers thought about what should travel over HTTP. In the earliest dynamic sites, the server mostly returned HTML because that’s what the browser could immediately render.

But by the late 1990s, structured data formats were gaining mindshare. Notably, the W3C published XML 1.0 in 1998. That didn’t instantly rewrite the web, but it strengthened an emerging idea: the server could return data that client code could interpret, rather than returning a fully formed page every time.

This is the conceptual hinge between “forms + CGI” and “AJAX.” Once you believe the response could be data, you start wanting a browser API that can:

• send HTTP requests without navigation
• receive response text as a value, not a document replacement
• let script decide how to update the UI

That is precisely the job XMLHttpRequest would later do, and why its name includes “XML” even though developers eventually used it for everything from plain text to JSON.

So where does XMLHttpRequest fit in this timeline?

If you’re looking strictly at 1995–1998, it’s important to be accurate: the widely recognized XMLHttpRequest object belongs to the later evolution of browser APIs (often associated with Internet Explorer’s XML features and then broader cross-browser adoption). The term “AJAX” also arrived later.

But the beginning of AJAX as a direction—the push toward asynchronous, script-driven communication—absolutely starts here. In this era, developers already had:

• a scripting language in the browser (JavaScript)
• a server integration model (CGI) that could generate responses programmatically
• UI composition tools (frames) that allowed partial screen changes
• growing interest in structured data (leading into XML’s standardization)

What they lacked was a clean, standardized web API that made “request as a function call” normal. Once XHR arrived, it didn’t create the desire for dynamic apps—it simply gave that desire a coherent interface.

For a modern reference on the API itself (including behavior and usage), see the documentation for XMLHttpRequest on MDN.

From workaround culture to API design: the lesson of 1995–1998

The history here is less about one object and more about a pattern you can still see in web API evolution today:

Developers prototype the behavior they want using awkward combinations of existing features, then browsers (and later standards) respond by turning those patterns into formal APIs.

In the mid-to-late 1990s, the “awkward combinations” included forms, frames, images, and script loading. Later, XHR became the formal mechanism. Much later still, the platform added newer interfaces like fetch() and more refined primitives.

If you’re tracing how web automation and integration patterns evolve over time, it can help to study these early constraints as “design pressure.” That’s also the mindset behind this series—along with practical experimentation and tooling discussions you can find at AutomatedHacks.com.

FAQ

Did XMLHttpRequest exist between 1995 and 1998?

Not as a widely deployed, standard browser API in that window. This chapter covers the web APIs and techniques from 1995–1998 that created the need for XHR-style background requests and partial UI updates.

How did developers update parts of a page before AJAX?

Common approaches included frames (updating one frame while another stayed stable), script-triggered form submissions, and resource-loading tricks (like image requests or dynamic script loading). These were workarounds rather than clean data APIs.

Why is “XML” in XMLHttpRequest’s name if people often use JSON today?

Because XML was a prominent structured data format in the late 1990s, especially after XML 1.0 was published in 1998. The name reflects that era’s expectations, even though the API can transport many formats.

What’s the key web API shift that XHR represents?

XHR turns HTTP communication into a script-accessible operation: send a request, receive response data as text, and update the page without a full navigation. That model was hard to achieve cleanly with the 1995–1998 toolset.