When developers talk about real-time web communication today, the conversation quickly lands on the WebSocket API: a persistent, low-latency channel that lets browsers and servers exchange messages without the overhead of repeated HTTP requests. But the WebSocket API itself arrived much later than the era we’re covering here.

So why discuss WebSockets in a 1995–1998 chapter of web API history? Because the problems WebSockets solve were already obvious in the mid-1990s. The web’s earliest “APIs” were not polished JavaScript interfaces; they were patterns built from HTML forms, CGI scripts, cookies, and early browser scripting. These pieces created a web that could simulate interactivity, but not sustain a true two-way live connection.

This chapter follows a chronological angle: the rise of browser scripting, CGI, forms, and early dynamic integration (roughly 1995 to 1998) and how these technologies carved the path that ultimately demanded something like WebSockets.

1995: Forms + CGI as the Original “Web API Surface”

In the mid-1990s, dynamic web experiences were largely built on a simple transaction model: the browser submits a request, the server generates a response, and the page reloads. HTML forms were the primary client-side interface for sending structured data. On the server side, CGI (Common Gateway Interface) connected the web server to scripts and programs that could read request parameters and output HTML.

Functionally, this acted like an early web API pattern: parameters in, content out. But the “API” was coupled to HTML rendering. There was no concept of a client calling an endpoint just to receive a compact payload and update a small part of the UI. Every interaction was a full document navigation.

This mattered for real-time communication because “real time” implies the UI changes as new information arrives. In 1995, the web’s core model made new information arrive only when the user explicitly triggered a navigation or submission.

1996: Browser Scripting Appears—and the Web Starts Asking for Live Data

As JavaScript (and related DOM capabilities) began appearing in browsers in the mid-1990s, the browser started to look like a programmable runtime rather than a static document viewer. Scripts could validate form input, swap images, and react to user events. This didn’t create real-time server communication, but it changed expectations: if the page can react instantly to user actions, why can’t it react instantly to server events?

At this point, a key historical tension formed in web API history:

• The browser could execute logic continuously (timers, event handlers, UI updates).
• HTTP communication remained discrete and document-oriented (request/response, navigation, reload).

The gap between those two realities is the gap WebSockets would later close.

1996–1997: Frames, Hidden Iframes, and “Server Push” Workarounds

As teams tried to build chat-like experiences, live dashboards, and rapidly changing pages (think: sports scores, auctions, market tickers), the constraints of the old request/response model became painful. Developers reached for clever layouts and browser behaviors.

Frames were one of the earliest integration hacks that resembled a modern single-page app layout. A page could be split into regions, and one region could reload without forcing the entire page to navigate. This wasn’t an API in the formal sense, but it was an architectural move: “refresh a part of the UI.”

From there, the industry experimented with techniques that were sometimes described as “push,” even though the server wasn’t truly initiating new messages to the browser in the modern WebSocket sense. Two common patterns emerged:

• Periodic refresh: the browser reloads a frame or page every N seconds. This provides near-real-time updates at the cost of wasted requests and visible flicker.
• Long-lived responses (early “server push” ideas): the server keeps an HTTP response open and streams content over time. This existed in various server/browser-specific forms, but it was not a standardized, reliable cross-browser API.

These patterns were early indicators that developers wanted a communication channel that stayed open. But because they were built on top of HTTP semantics meant for document transfer, they were fragile. Proxies, timeouts, and browser limitations often interfered.

1997–1998: Cookies, Sessions, and the “State Problem” in Real-Time Attempts

Real-time systems are not just about pushing bytes; they’re also about maintaining shared context. In the mid-to-late 1990s, web state was frequently approximated using cookies and server-side sessions. This allowed the server to recognize a returning client across separate HTTP requests.

For pseudo-real-time approaches (polling, refresh loops), cookies and sessions were essential: without them, each update request looked like a brand-new visitor. But this also amplified overhead. Every “check for updates” request had to carry cookies, session identifiers, and often triggered server-side page generation logic that output full HTML.

From a web API history perspective, this is a major stepping stone. The industry began to separate concerns:

• Identity and continuity (cookies/sessions)
• Transport (HTTP requests that weren’t designed for frequent, low-latency messaging)
• Presentation (HTML as the default response format)

WebSockets would later benefit from this separation, offering a more efficient transport for frequent messaging once identity, security expectations, and browser runtimes matured.

Why WebSockets Didn’t Exist Yet (and What Had to Evolve First)

It’s tempting to look back and wonder: if the need was obvious, why didn’t the WebSocket API appear in 1997 or 1998? A careful answer is that several prerequisites were still developing:

1. Standardized, widely implemented browser APIs: In the late 1990s, cross-browser scripting was inconsistent. A real-time API is only useful if most users can rely on it.
2. Security and sandboxing expectations: Persistent connections expand the attack surface. The web needed years of lessons around origin boundaries, scripting risks, and secure transport practices.
3. Infrastructure readiness: Proxies, load balancers, and hosting stacks of the era were optimized for short HTTP requests, not large numbers of open, long-lived connections.
4. Developer mental models: The dominant model was “submit form, render page.” Moving to event-driven, message-based thinking took time—and demanded better tooling and documentation.

In other words: the late 1990s provided the pressure and the prototypes, but not the stable platform.

Connecting the Dots: 1995–1998 Patterns That Echo in WebSocket Design

Even though WebSockets arrived much later, several mid-1990s ideas map directly to how we understand real-time APIs today:

• Forms as structured client input → Modern message payloads (often JSON) sent over a socket.
• CGI as a server integration point → Modern application servers handling events rather than page renders.
• Frames and partial refresh → Modern partial UI updates driven by messages rather than navigations.
• Streaming-ish “server push” hacks → The desire for a durable channel that doesn’t require repeated handshakes.

If you want a concise modern reference for what the browser-side WebSocket interface looks like today, the canonical starting point is the developer documentation: MDN’s WebSocket API reference.

And if you’re thinking about how real-time communication affects automation, monitoring, or integration workflows, you may also find practical ideas at AutomatedHacks.com, especially as you connect historical constraints to modern implementation choices.

Takeaway: The Late 1990s Built the “Problem Statement” WebSockets Solved

From roughly 1995 through 1998, web development became increasingly dynamic—but real-time communication remained an awkward fit. Browser scripting made pages feel alive, while CGI and forms kept the server interaction anchored to full-page transactions. Frames and streaming hacks tried to bridge the gap, but the web platform and infrastructure weren’t ready for a standardized, persistent, bidirectional channel.

In the timeline of web API history, this era is where the need for a WebSocket-like capability became unmistakable. The web learned, through experimentation, that “interactive UI” and “request/response documents” were not enough for live systems. The rest of the story—standardization, security models, and practical deployment—would unfold in later chapters.

FAQ

Did WebSockets exist between 1995 and 1998?

No. The WebSocket API is a later development. This chapter explains the mid-to-late 1990s technical patterns and limitations that created demand for a persistent, message-based communication channel.

How did websites approximate “real time” in the late 1990s?

Common approaches included timed refreshes, reloading frames, and in some cases keeping HTTP responses open to stream updates. These solutions were often browser- or server-specific and lacked a consistent, standardized API surface.

Why were CGI and forms important in web API history?

They established the early transaction model for browser-to-server communication: send parameters, receive a generated response. This pattern shaped expectations and exposed inefficiencies when developers tried to build interactive, continuously updating experiences.

What’s the key difference between polling and WebSockets?

Polling repeatedly makes new HTTP requests to ask for updates. WebSockets keep a single connection open so the server and browser can exchange messages without repeating the request/response setup each time.