If you search for the XMLHttpRequest history, you’ll quickly run into a timeline problem: XMLHttpRequest (XHR) is usually associated with late-1990s browsers, and AJAX wasn’t named until much later. So why focus on 1990–1994?

Because the real “beginning” of AJAX isn’t the moment the XHR object appeared in JavaScript. The beginning is the moment the Web gained a simple, universal way for a client to request a resource from a server—reliably, repeatedly, and with predictable semantics. That happened at the very birth of the Web.

This chapter follows a chronological path through 1990–1994, when the Web’s earliest HTTP interfaces established the request/response patterns that XHR and modern web APIs still depend on. In other words: the pieces that made asynchronous, script-driven network calls inevitable were already on the board, even if the board didn’t yet include JavaScript.

1990: The Web Starts as a Remote Document Interface

The earliest Web was conceived less like an “application platform” and more like a distributed document system. But even that required an interface between software components: a browser (client) needed a standardized way to ask a server for content. That interface was HTTP, paired with the idea of a URL (or, historically, related terms like URI).

In the earliest period (often described as HTTP/0.9), the model was intentionally simple: a client opened a connection, requested a path, and received a document. There were no rich headers, no content negotiation, and no notion of “API endpoints” the way we think of them now. But the key architectural move was already present:

• A network call initiated by the client
• A predictable response produced by the server
• A shared protocol that multiple implementations could adopt

That is the core of a web API, even before anyone used the term.

1991–1992: From a Single Browser to an Ecosystem of Clients

As the Web moved beyond a single research environment, it began to look less like one product and more like a platform. Multiple clients and servers meant the protocol had to be implementable by different teams without negotiation every time two machines spoke.

This is an underappreciated part of web API history: the Web’s early success came from reducing the number of special cases. If a client could request a document from one server, it could request a document from many. That universality later made it natural to request data as easily as documents.

Even though the early Web was page-centric, the mechanism—HTTP requests—was general-purpose. That general-purpose nature is what later allowed browsers to do background requests through XHR without introducing an entirely new protocol.

1993: Mosaic, Momentum, and the Pressure for Interactivity

By 1993, the Web’s reach expanded rapidly, helped by browsers that made the experience more accessible to non-specialists. With growth came pressure: people didn’t just want to read documents, they wanted to interact with systems.

In web API terms, this is where the story starts bending toward applications. The early request/response flow was fine for static pages, but awkward for:

• search interfaces
• directories and indexes
• guestbooks and user-submitted content
• anything requiring a server-side calculation

The Web needed a way for the browser to send structured input to the server. That brought two big building blocks into focus: HTML forms and server-side gateways (especially CGI).

1993–1994: Forms and CGI as “Proto-APIs”

If XMLHttpRequest is often remembered as “the thing that let the browser call the server without reloading the page,” then forms + CGI were “the thing that let the browser send parameters to the server at all.”

As HTML form capabilities spread through browsers in the early-to-mid 1990s (the details and exact timing vary by implementation and specification maturity), the Web gained a primitive but powerful interface style:

• The browser collects user input through form fields.
• That input is encoded into an HTTP request (commonly via GET query strings or POST bodies).
• A server program (often via CGI) interprets the input and returns an HTML page.

From a modern perspective, this looks like a crude API call that always returns HTML. But architecturally, it introduced patterns that later became central to web APIs:

1. Parameterization: request data changes the response.
2. Statelessness (mostly): each request can stand alone, even if sessions later evolve.
3. Uniform transport: the same HTTP machinery can carry “app” requests.

Even without JSON, even without JavaScript, this was already a form of remote procedure invocation through a web-shaped interface.

What 1990–1994 Did Not Have (And Why That Matters for XHR)

To understand why XMLHttpRequest was such a big deal later, it helps to be clear about what early Web interfaces lacked:

• No standard client-side scripting environment (JavaScript would come later.)
• No DOM-centric programming model for updating parts of a page in place.
• No expectation of “partial updates”; navigation was the interaction model.
• Limited content-type conventions for structured data compared to today’s JSON-first APIs.

So while you can trace the network idea behind AJAX back to early HTTP, you can’t honestly claim that XHR itself existed in 1990–1994. The point is subtler: the Web’s earliest API surface area was HTTP itself. Once browsers became programmable, the most straightforward move was to expose HTTP requests to scripts—leading to XHR.

From “Documents Over HTTP” to “APIs Over HTTP”: The Conceptual Bridge

By the mid-1990s, developers were already treating certain URLs as functional endpoints. A CGI script wasn’t just “a page”; it was an interface. Developers learned to rely on stable parameter names, stable response shapes, and stable behavior—just delivered as HTML.

This is the conceptual bridge to XMLHttpRequest and AJAX:

• Before: the browser requests a document meant for humans.
• After: the browser requests data meant for code, then renders a UI.

AJAX didn’t invent the idea of calling the server from the client. It reframed it: “What if the browser could make the same kind of HTTP request, but do something smarter than replace the entire page?”

Why XMLHttpRequest Was the Natural Next Step

When XMLHttpRequest eventually appeared (after this chapter’s era), its impact came from fitting neatly into the Web’s existing contract:

• It reused URLs to identify resources.
• It reused HTTP methods (like GET and POST) to express intent.
• It reused status codes and headers once those became common expectations.

In other words, XHR looked revolutionary in the browser UI, but it was evolutionary in protocol terms. The Web’s 1990–1994 foundation did the heavy lifting by normalizing HTTP as the universal interface layer.

If you want to see the modern standard that defines XHR behavior today, the authoritative reference is the WHATWG specification: https://xhr.spec.whatwg.org/.

What This Chapter Means for Web API History

When people tell the story of web APIs, it’s tempting to jump straight to “AJAX changed everything,” then fast-forward to REST, then to JSON and fetch(). But the more accurate historical arc begins earlier:

1. 1990–1992: define a universal request/response protocol for documents.
2. 1993–1994: add input (forms) and server-side execution (CGI), creating functional endpoints.
3. Later: expose HTTP calls to scripts (XHR), enabling asynchronous UI updates.

That’s why this chapter belongs in a chronological history of web APIs: it’s the “quiet” period where the interface primitives were formed. XHR and AJAX are easier to understand when you see them as a continuation of early HTTP’s minimal but powerful model.

If you’re building modern automations or integrations and want practical experiments that connect history to real developer workflows, you can explore more at AutomatedHacks.com.

FAQ

Did XMLHttpRequest exist in 1990–1994?

No. The early 1990–1994 Web established HTTP and early interactive patterns (like forms and CGI), but XMLHttpRequest came later. This chapter focuses on the foundations that made XHR and AJAX possible.

So why talk about AJAX in the early 1990s at all?

Because AJAX depends on the idea that a browser can make HTTP requests as part of an application workflow. That idea originates with the Web’s first client-server interfaces—long before the term “AJAX” was coined.

What were the earliest “web APIs” if not XHR-based endpoints?

In 1990–1994, “web APIs” were mostly HTTP-accessible resources plus form-driven CGI endpoints—interfaces that accepted parameters and returned responses predictably, typically as HTML.

What is the most authoritative place to read about XMLHttpRequest today?

The WHATWG XMLHttpRequest standard is a primary reference for current behavior and compatibility expectations.