When developers talk about Server-Sent Events (SSE) today, they usually mean a clean browser API—EventSource—that keeps a single HTTP connection open so the server can continuously push text updates to a page. That tidy story is modern. But the need for streaming updates is as old as the Web itself.

This chapter covers a narrow but foundational era—roughly 1990 through 1994—when the Web was being invented, browsers were still learning what “interactive” meant, and HTTP was intentionally minimal. In that environment, the Web’s earliest “API” was basically the uniform interface itself: a URL plus a method like GET, returning a document. The twist is that even in those earliest years, people already wanted something more like a live feed: a stock ticker, a log tail, a monitoring dashboard. SSE didn’t exist yet—but the pressure that eventually produced SSE was already forming.

The early Web API: a document interface with hard edges

From the beginning, HTTP’s appeal was its simplicity: request a resource, receive a response, and move on. That’s why the early Web scaled conceptually even before it scaled operationally. But that same simplicity created an immediate limitation for anything “live.”

In 1990–1994, typical web interaction was:

• Client-initiated: the browser asks; the server answers.
• Stateless by design: the server doesn’t assume a continuing conversation.
• Response-oriented: a response is a finished document or file, not an endless stream.

That “one request → one response” posture is the ancestor of many web API patterns. It’s also the reason streaming is historically interesting: streaming is an intentional bending of the original model. It takes a protocol designed for discrete documents and asks it to behave like a live channel.

1993–1994: Mosaic, growth, and the first real demand for live updates

By the early 1990s, the Web transitioned from a research novelty to something more broadly accessible. Browsers like Mosaic (released in 1993) helped normalize clicking links, fetching remote assets, and rendering mixed content. As usage broadened, expectations changed: people didn’t just want documents; they wanted freshness.

Even without modern analytics, it’s easy to infer why. The pre-Web internet already had “live” experiences—chat on IRC, ongoing discussions via Usenet, news feeds, and system monitoring tools that updated continuously. When those audiences encountered the Web, a natural question emerged: “Can a web page update itself as events happen?”

From a web API history standpoint, that question is crucial. It signals a shift from “HTTP as file transfer for hypertext” toward “HTTP as an application interface,” where the response might represent not a static document, but an evolving state.

What did “streaming” mean before SSE existed?

It’s tempting to retroactively label every early workaround as SSE. But SSE is a specific design: text-based events, standardized formatting, automatic reconnection, and a browser API. None of that was standardized in 1990–1994.

Instead, early “streaming updates” on the Web were a set of experiments and approximations—ways to approximate continuity over a protocol that usually expected completion.

1) Client pull: refresh as a primitive polling API

The earliest and simplest pattern was essentially: “ask again.” A page could be reloaded manually by the user, or refreshed automatically using HTML behaviors that became common in the early web era. This created a crude polling loop:

• Browser requests a page.
• Server returns the newest snapshot of a value or status.
• Browser repeats after a delay.

In web API terms, this is polling before we called it polling: repeated GET requests as a way to emulate a subscription. It’s inefficient, but it fits the early model perfectly: discrete documents, discrete responses.

2) Early dynamic gateways: CGI as “API glue”

As servers became more capable, early dynamic techniques—most famously CGI—turned HTTP into an interface to programs. While CGI itself wasn’t “streaming,” it mattered because it reframed HTTP endpoints as programmable interfaces, not just static content.

By the early 1990s, popular server implementations and documentation made CGI-style scripting a practical way to return dynamic output. That’s a key step toward modern APIs: once the server response is computed on demand, developers naturally ask if it can also be computed continuously.

3) Holding the connection open (without a strong standard)

One of the most historically revealing ideas is also the simplest: don’t end the response.

If a server can keep the TCP connection alive and keep writing bytes, the client can keep reading. Today we take for granted that protocols and intermediaries understand streaming responses. In the early Web, that was much less standardized and less reliable. Proxies, servers, and browsers weren’t consistently built for long-lived HTTP responses. Still, the concept was attractive because it inverted the interaction: the browser asks once, and the server can keep sending updates.

This is the conceptual ancestor of SSE: a single request that becomes a stream.

4) MIME multipart: early framing ideas that hinted at event streams

Another important ingredient existed in adjacent standards: MIME. MIME introduced structured content types and multipart messages, which made it possible (at least in principle) to frame multiple “parts” inside one logical response.

Within the 1990–1994 window, MIME was already part of the broader internet standards conversation. While the Web didn’t instantly become a streaming platform because of MIME, multipart framing planted an idea that streaming needs: boundaries—a way for the client to know where one update ends and the next begins.

That idea—“a long response containing a series of clearly separated messages”—is very close to the mental model of an event stream, even if the Web hadn’t yet converged on a single approach.

Why early HTTP made SSE-like behavior hard

To understand why SSE took a long time to become a standard, it helps to see what the early Web optimized for.

• Simplicity over richness: early HTTP was intentionally small, and the ecosystem prioritized “it works everywhere” over specialized features.
• Completion semantics: many systems assumed a response finishes, which affects buffering and rendering.
• Intermediaries: even early on, gateways and caches shaped what “normal” HTTP behavior looked like.

Streaming is not just a server feature. It requires a whole path—server, network, client, and often intermediaries—to agree that a response can remain open and meaningful over time. In 1990–1994, that agreement hadn’t formed yet.

The historical throughline: from “documents” to “events”

So what does this era contribute to the history of web APIs if SSE itself wasn’t there?

It contributes the problem definition and the first attempts:

1. The Web proved a universal interface could spread quickly.
2. Wider adoption created demand for immediacy and continuous updates.
3. Developers experimented with polling, dynamic gateways, and long responses.
4. Those experiments clarified requirements that later standards would meet: reconnection, message framing, low overhead, and compatibility.

In other words, 1990–1994 is when the Web learned that “request/response” is a fantastic baseline—and that some applications need more than a baseline.

If you want a modern reference point for what SSE eventually became, MDN’s documentation is a solid overview of the API and its behavior: Server-sent events (MDN Web Docs).

And if you’re exploring automation and modern API behaviors (including streaming patterns) from a practical engineering perspective, you may also like this internal resource: AutomatedHacks.com.

What to remember from 1990–1994 (Chapter 29 takeaways)

This slice of time is small, but it’s the seedbed for streaming APIs:

• The Web began as a document system, and its earliest HTTP interfaces reflected that.
• “Live updates” were an immediate desire once browsers popularized the medium.
• Polling and refresh were early, crude API patterns for change notification.
• Keeping a connection open was conceptually obvious but operationally difficult without ecosystem-wide support.
• Framing ideas (like multipart content structures) hinted at how continuous updates could be packaged.

SSE, when it arrived later, didn’t appear out of nowhere. It formalized a need the Web had felt since its earliest public growth: a lightweight, server-to-browser stream for updates that feel immediate without turning every page into a constant series of reloads.

FAQ: Server-Sent Events and the early Web

Did Server-Sent Events exist in 1990–1994?

No. SSE as developers know it today (with the EventSource API and standardized event formatting) arrived later. This chapter focuses on the early Web conditions and experiments that made SSE a clearly needed pattern.

How did early websites approximate real-time updates?

Mostly through repeated requests: manual reloads and automatic refresh-style behaviors. Some early systems also experimented with keeping HTTP responses open, but it wasn’t consistently supported across browsers and servers.

Why not just use a different protocol for live updates back then?

Other protocols existed for “live” communication, but the Web’s advantage was universal reach through browsers and URLs. The push to make HTTP handle updates came from the desire to keep everything inside the same widely deployed interface.

What’s the key historical idea that connects early HTTP to SSE?

The key idea is shifting from “a response is a finished document” to “a response can be an ongoing stream of messages.” Early developers wanted that behavior long before browsers standardized it.