Learn WebSocket - History of the Real-Time Web: From Polling to WebSocket

#Introduction

Before understanding WebSocket, you must understand the problem it solves. WebSocket did not appear out of thin air — it is the answer to decades of developer effort to make the web "communicate in real-time".

Episode 1 takes you through that evolution step by step: static web pages that could only be reloaded, wasteful short polling, long polling that is smarter but still heavy, and one-way Server-Sent Events. By the end of the episode you will see why none of these approaches were enough — and that is the gap WebSocket fills.

#The Early Static Web Era

#The Request-Response Model

In the early days of the web, every interaction followed a single pattern: the browser sends a request, the server returns a response, and the page finishes loading. If there is new data on the server, the browser will not know until you press the refresh button.

This model works well for documents and pages that rarely change. Problems arise when an application needs constantly updated data — for example, stock prices, match scores, or chat notifications. HTTP is a stateless protocol: every request stands alone, and the server does not keep context between requests.

As a result, the simplest idea that occurred to early developers was: ask the page to reload periodically.

#Short Polling: Asking Over and Over

#Basic Concept

Short polling is the most naive approach: the client asks the server for data every few seconds, for example every 5 seconds, regardless of whether there is new data or not.

Short polling simulation

setInterval(async () => {
  const res = await fetch("/api/status");
  const data = await res.json();
  render(data);
}, 5000);

The code above asks the /api/status endpoint every 5 seconds. setInterval(async () => {...}, 5000) is the core of short polling — a timer that triggers requests repeatedly with no stopping condition.

#The Problems It Creates

Short polling works, but at a high cost:

• High latency: new data is only detected at the next interval, delayed on average by half an interval.
• Network overhead: every request carries full HTTP headers, most of which are useless.
• Server load: thousands of clients mean thousands of empty requests per minute.
• Wasted resources: electricity, bandwidth, and CPU are spent on questions whose answers are already known.

Imagine 10,000 clients polling every 5 seconds: the server receives 120,000 requests per minute just to say "nothing new".

#Long Polling (Comet): Holding the Connection

#Basic Concept

Long polling fixes the main problem of short polling. Instead of closing the connection after a response, the server holds the response open until there is data truly ready to be sent.

The flow: the client sends a request, the server holds it, and only sends a response when new data becomes available. After the data is received, the client immediately creates a new request to "reconnect".

Long polling simulation

async function longPoll() {
  const res = await fetch("/api/events");
  const event = await res.json();
  render(event);
  longPoll();
}
longPoll();

The longPoll() pattern that calls itself after receiving an event mimics Comet behavior. The server holds the fetch("/api/events") request open for as long as possible.

#Pros and Cons

Long polling is far more responsive than short polling: data is sent almost instantly when it becomes available. But other problems appear:

• Header overhead: every event still requires a full HTTP round-trip.
• Connections constantly created and torn down: repeated TCP handshake costs.
• Timeout and reconnection: the server and client must agree on timeouts, or the connection breaks mid-way.
• High complexity: maintaining state across alternating connections is tricky.

Long polling was a big leap, but still far from an ideal solution.

#Server-Sent Events (SSE): Better but One-Way

#Basic Concept

Server-Sent Events (SSE) arrived with HTML5 and leverages an existing protocol: an ordinary HTTP connection left open. The key difference — the server pushes data to the client over a single long-lived connection, without the client asking repeatedly.

SSE consumer in the browser

const sse = new EventSource("/api/stream");
 
sse.onmessage = (event) => {
  render(JSON.parse(event.data));
};

With new EventSource("/api/stream"), the browser establishes a persistent connection. sse.onmessage is invoked every time the server sends data. SSE also has automatic reconnection and event IDs for position recovery — two features polling does not have.

#SSE Limitations

SSE solves the server-to-client direction, but not fully:

• One-way: the client cannot send data over the same connection; it needs a separate HTTP request.
• Connection limits: browsers limit around 6 connections per domain over HTTP/1.1 — 6 stream tabs and the quota is exhausted.
• Text format: SSE is designed for text, not binary.
• One-way connection with HTTP overhead: still based on upgraded requests, not a standalone protocol.

SSE remains a good choice for notifications and live feeds, but for two-way chat it is not enough.

#The Birth of WebSocket

#The Unmet Needs

From the journey above, a consistent set of needs emerges:

• Full-duplex: both parties can send at any time without waiting.
• Low latency: data is delivered in milliseconds, not seconds.
• Minimal overhead: no repeated HTTP headers per message.
• Binary and text: support for audio, images, and binary data.

#WebSocket as the Answer

WebSocket satisfies all of those needs with a single persistent TCP connection. It began as just a browser proposal, then was standardized as RFC 6455 in 2011. Today WebSocket is the backbone of real-time applications: chat, multiplayer games, document collaboration, live dashboards, and trading platforms.

refresh manual → short polling → long polling → SSE → WebSocket

The flow refresh manual → short polling → long polling → SSE → WebSocket is a mental summary that will stay with you throughout this series.

#Closing

Episode 1 shows that WebSocket is the result of an evolution, not a sudden invention. Each previous approach solved one problem but created another: short polling is wasteful, long polling is complex, and SSE is one-way.

Key takeaways:

• The early web was static: new data was only visible after a manual refresh.
• Short polling wastes latency, bandwidth, and server resources.
• Long polling is more responsive but still based on HTTP round-trips.
• SSE is good for one-way, but limited in the number of connections and does not support binary.
• The needs for full-duplex, low latency, and minimal overhead gave birth to WebSocket.

In the next episode we will dissect the WebSocket protocol itself — the RFC 6455 standard, the ws:// and wss:// schemes, and a comparison of WebSocket with SSE and HTTP/2 Server Push. You will begin to see the inner workings of the protocol you are learning.