The Predecessors of WebSocket: The Past and Present of Short Polling and Long Polling

Network

23 days ago1832 words·10 min read

What You'll Learn

Understand how Short Polling and Long Polling work under the hood
Implement both polling mechanisms from scratch using Node.js
Grasp the trade-offs between the two approaches and when to use each
Understand the HTTP protocol characteristics that make Long Polling possible

Prerequisites

Basic understanding of the HTTP request-response model
A rough idea of the TCP/IP layered architecture (no deep dive needed)
Basic experience with Node.js and front-end JavaScript

Starting From a Real Scenario

Imagine you're building an online customer support system. When a user sends a message, the other side needs to see it instantly. Your first instinct might be: "What if I just make the browser send a request every second asking the server for new messages?"

That's a valid starting point — but is polling every second really good enough? Is there a better way? Before WebSocket came along, front-end developers relied on these "low-tech" tricks to achieve near-real-time communication. In this article, we'll retrace that evolution from the ground up.

Short Polling

The Intuition

Picture yourself waiting for an important package, but the courier won't notify you when it arrives. You have to walk downstairs every few minutes to check your mailbox — that's short polling in a nutshell.

txt

Client: "Any new messages?"
Server: "Nope."
Client: (waits 1s) "Any new messages?"
Server: "Yes! Here you go."
Client: (waits 1s) "Any new messages?"
...

The core idea is dead simple: the client sends HTTP requests on a fixed interval, and the server returns data if there is any, or an empty response if there isn't. No special protocol needed — plain HTTP does the job.

A Minimal Implementation

Let's start with the smallest working version. The server randomly simulates new data arriving; the client asks every second.

Server-side (Node.js):

import http from "http";

const server = http.createServer((req, res) => {
  if (req.url === "/poll") {
    // Simulate: 30% chance of "new data"
    const hasNewData = Math.random() < 0.3;

    if (hasNewData) {
      res.writeHead(200, { "Content-Type": "application/json" });
      res.end(JSON.stringify({ message: "Server has new data!" }));
    } else {
      res.writeHead(204); // No Content
      res.end();
    }
  }
});

server.listen(3000, () => {
  console.log("Short polling server running on http://localhost:3000");
});

Client-side:

html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Short Polling Demo</title>
</head>
<body>
  <h1>Short Polling Demo</h1>
  <div id="messages"></div>

  <script>
    function poll() {
      fetch("http://localhost:3000/poll")
        .then((res) => {
          if (res.status === 200) return res.json();
          if (res.status === 204) return null;  // No new data
        })
        .then((data) => {
          if (data?.message) {
            const div = document.getElementById("messages");
            div.innerHTML += `<p>${data.message}</p>`;
          }
        })
        .catch((err) => console.error("Poll error:", err))
        .finally(() => setTimeout(poll, 1000)); // Ask again in 1 second
    }

    window.onload = poll;
  </script>
</body>
</html>

Two key details worth noting:

204 No Content: When there's nothing new, the server returns 204 rather than 200 with an empty body. This is semantically more precise and saves bandwidth.
Recursive scheduling in finally: The poll continues regardless of success or failure. A single network hiccup won't kill the polling loop.

The Good and the Bad

Advantages:

Dead simple to implement, compatible with every browser and HTTP server.
No long-lived connections to maintain; server load is predictable.

Disadvantages:

Massive resource waste: Even when 99% of requests yield nothing, the client keeps firing them. Most bandwidth and CPU cycles are spent on empty round-trips.
Unpredictable latency: There's up to one full interval's worth of delay between data arriving and the next poll picking it up. If you shorten the interval to 100ms for lower latency, you just multiplied your request volume by 10.

Here's a metaphor: you go downstairs to check your mailbox every 5 minutes. The package might arrive right after you just checked. If you switch to checking every 30 seconds, latency improves — but now you're running yourself ragged.

What if the courier could proactively notify you, instead of you running downstairs on repeat?

That's exactly what Long Polling sets out to solve.

Long Polling

Flipping the Script: Let the Server Wait

Long polling inverts the logic: the client sends one request, and if the server has nothing new, it holds the connection open instead of replying immediately — only responding when data arrives or a timeout fires. The client then immediately issues the next request, forming a "request → wait → respond → request" loop.

txt

Client: "Any new messages?"
Server: ... (holding, waiting for data)
Server: "Yes! Here you go."
Client: (immediately) "Any new messages?"
Server: ... (holding again)

The critical difference: in short polling, the client does the waiting (via setTimeout); in long polling, the server does the waiting (by holding the connection).

A Minimal Implementation

Let's build a simple chat room where messages arrive "instantly" via long polling.

Server-side:

import http from "http";

let clients = [];   // Pending client connections waiting for a response
let message = null; // Message to broadcast

const server = http.createServer((req, res) => {
  // CORS
  res.setHeader("Access-Control-Allow-Origin", "*");
  res.setHeader("Access-Control-Allow-Methods", "GET, POST");
  res.setHeader("Access-Control-Allow-Headers", "Content-Type");

  // Long polling endpoint: clients come here to wait
  if (req.url === "/poll") {
    clients.push(res);

    // Clean up when the client disconnects
    req.on("close", () => {
      clients = clients.filter((c) => c !== res);
    });
  }

  // Send endpoint: broadcast a message to all waiting clients
  if (req.url === "/send" && req.method === "POST") {
    let body = "";
    req.on("data", (chunk) => (body += chunk.toString()));
    req.on("end", () => {
      // Notify every waiting client
      clients.forEach((client) => {
        client.writeHead(200, { "Content-Type": "application/json" });
        client.end(JSON.stringify({ message: body }));
      });
      clients = [];    // Clear the waiting queue
      res.end("OK");   // Reply to the sender
    });
  }
});

server.listen(3000, () => {
  console.log("Long polling server running on http://localhost:3000");
});

Client-side:

html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Long Polling Chat Room</title>
</head>
<body>
  <h1>Long Polling Chat Room</h1>
  <div id="messages"></div>
  <input id="msgInput" type="text" placeholder="Type a message..." />
  <button onclick="send()">Send</button>

  <script>
    // Long polling: fire the next request as soon as a response arrives
    function poll() {
      fetch("http://localhost:3000/poll")
        .then((res) => res.json())
        .then((data) => {
          if (data.message) {
            document.getElementById("messages").innerHTML +=
              `<p>${data.message}</p>`;
          }
          poll(); // Immediately ask again after receiving data
        })
        .catch((err) => {
          console.error("Poll error:", err);
          setTimeout(poll, 5000); // Retry after 5s on error
        });
    }

    function send() {
      const input = document.getElementById("msgInput");
      fetch("http://localhost:3000/send", {
        method: "POST",
        body: input.value,
        headers: { "Content-Type": "text/plain" },
      })
        .then(() => (input.value = ""))
        .catch((err) => console.error("Send error:", err));
    }

    window.onload = poll;
  </script>
</body>
</html>

A few design decisions worth highlighting:

Respond-then-request: poll() calls itself recursively inside .then(), not via setTimeout. As soon as data arrives, the next waiting cycle begins immediately — minimal latency.
The server holds a clients array: Each long-poll request's res object is saved. When a message arrives, the server calls end() on all of them at once. This leverages Node.js's event-driven, non-blocking model.
close event cleanup: When a client disconnects (tab closed, network drop), its res must be removed from the array. Otherwise you get a memory leak.

Short Polling vs. Long Polling: At a Glance

Dimension	Short Polling	Long Polling
Request frequency	Fixed interval, independent of data	Data-driven, only responds when there's data
Latency	Up to 1 full interval	Near-real-time in theory
Server overhead	Many wasted requests	Holding connections; heavier with many clients
Implementation complexity	Trivial	Moderate — must manage a connection queue
Best for	Low-frequency updates (e.g., system status)	Medium real-time needs (chat, notifications)

Going Deeper: Why Does Long Polling Even Work?

A natural question arises: HTTP is a stateless request-response protocol — how can the server just "hold off" on replying?

The answer is that while HTTP defines the request-response model, it does not mandate how quickly the server must respond. RFC 7230 defines no mandatory request timeout. Timeout handling is entirely up to the client and server implementations.

In the browser, fetch has no built-in timeout by default (though browsers may impose a very long one internally — Chrome's is around 300 seconds). If you need explicit timeout control, you can do this:

function fetchWithTimeout(url, options = {}, timeout = 5000) {
  return Promise.race([
    fetch(url, options),
    new Promise((_, reject) =>
      setTimeout(() => reject(new Error("Request timeout")), timeout)
    ),
  ]);
}

// Usage: error out if no response within 5 seconds
fetchWithTimeout("/api/long-poll", {}, 5000)
  .then((res) => res.json())
  .catch((err) => console.error("Timeout or network error:", err));

This flexibility is the key. Upon receiving a request, the server can choose not to call res.end() immediately. Instead, it stashes the response object and only finalizes the response when data becomes available. The underlying TCP connection stays open throughout, and TCP itself guarantees reliable data delivery — even if the connection lingers, no packets are lost.

So long polling isn't black magic. It simply exploits two properties of HTTP:

HTTP has no mandatory response deadline.
TCP provides a reliable, persistent channel underneath.

Hands-On Practice

Basic Exercises

Run the short polling example above, then change the interval from 1 second to 100ms. Observe the request volume using your browser's DevTools Network panel.
Run the long polling example, open it in two browser tabs, send a message from one, and watch the other receive it in near real-time.

Advanced Challenges

Add a timeout mechanism to the long polling server: if a client waits 30 seconds with no new message, proactively return { timeout: true } so the client reconnects. This prevents proxy servers or load balancers from killing idle connections.
Extend the long polling server to support multi-room chat: different URL paths (e.g., /poll/room1) map to different rooms, each with its own independent clients array.

Summary & Key Takeaways

Short Polling = client asks on a timer, server answers immediately. Simple but wasteful.
Long Polling = client asks once, server holds until there's data. More efficient but requires connection management.
HTTP imposes no mandatory response deadline — this is the protocol-level foundation that makes long polling possible.
Both approaches are "transitional technologies" from the pre-WebSocket era, but understanding them clarifies exactly what problem WebSocket was built to solve.

Keywords: Short Polling, Long Polling, HTTP 204, connection holding, real-time communication

The Predecessors of WebSocket: The Past and Present of Short Polling and Long Polling

What You'll Learn

Prerequisites

Starting From a Real Scenario

Short Polling

The Intuition

A Minimal Implementation

The Good and the Bad

Long Polling

Flipping the Script: Let the Server Wait

A Minimal Implementation

Short Polling vs. Long Polling: At a Glance

Going Deeper: Why Does Long Polling Even Work?

Hands-On Practice

Basic Exercises

Advanced Challenges

Summary & Key Takeaways

Further Reading & Next Article Preview