Long Polling & Server-Sent Events

Think about an app showing live cricket scores, or an order tracking page on Amazon that updates by itself. Like, you’re just staring at the screen and the number changes without you touching anything. So here’s the puzzle:

• Normal HTTP works one way. The browser asks, the server answers, done.
• But here the new data is on the server’s side. The browser doesn’t know when it’s coming.

So how does fresh data reach you without you hitting refresh? There are a few answers, and two simple ones are long polling and Server-Sent Events. Let’s understand the problem first, then each fix.

🤔 The Problem With Normal Requests

With a normal request, the browser has to ask before it can get anything. The server can’t speak first. So if you want live updates, your only basic option is to keep asking, again and again. This is called polling.

Polling works, but it’s wasteful. Here’s why:

• The browser asks “any updates?” every few seconds, even when nothing changed.
• Most of those requests come back empty. That’s wasted network and wasted server work.
• And there’s still a delay. If news arrives right after you asked, you wait for the next round to hear it.

So plain polling is the clumsy version. Long polling is the smarter cousin.

⏳ Long Polling

Long polling changes one thing: instead of the server answering an empty “nothing yet” right away, it holds the request open and waits until it actually has something to send.

Here’s how one cycle goes:

• The browser sends a request: “tell me when there’s an update.”
• The server doesn’t reply immediately. It just holds the line open.
• The moment new data appears (a new score, a new message), the server replies with it.
• The browser gets the data, then immediately sends a fresh request to wait again.

So the connection is mostly “waiting”, not “asking over and over”. Way less wasted traffic, and updates arrive almost instantly.

📡 Server-Sent Events (SSE)

Server-Sent Events take a cleaner approach. The browser opens one long-lived connection, and the server keeps sending updates down it whenever it wants. One connection, many messages, all flowing from server to browser.

The key things to know about SSE:

• It’s one-way only: server to browser. The browser can’t send data back on this connection.
• The connection stays open. The server pushes a new message each time there’s something new.
• It’s built into browsers with a simple tool called EventSource, and it reconnects on its own if the connection drops.

So SSE is great when updates flow in one direction, from the server out to the user. Live scores, a news ticker, a notification feed, a progress bar. All one-way, all perfect for SSE.

Here’s the tiny bit of browser code that listens for updates. Notice how little there is.

// Open a one-way stream from the server
const stream = new EventSource("/live-scores");

// Runs every time the server pushes a new message
stream.onmessage = (event) => {
  console.log("New update:", event.data);
};

Reading that:

• new EventSource("/live-scores") opens the long-lived connection to the server.
• onmessage runs each time the server sends something, with the data in event.data.

That’s it. No looping, no re-asking. The server just pushes, and your code reacts.

📊 Long Polling vs SSE vs WebSockets

You’ve also met WebSockets, which keep a full two-way connection open. So how do these three compare? Here’s the picture.

🧭 When to Use Which

A simple way to choose:

• Need a quick fix that works on almost any old server? Long polling.
• Updates only flow from server to user, like scores or notifications? SSE. It’s the cleanest fit.
• Both sides need to send constantly, like a chat or a multiplayer game? WebSockets.

⚠️ Common Mistakes and Misconceptions

A few things to keep straight:

• “Polling and long polling are the same.” No. Plain polling keeps asking and gets lots of empty answers. Long polling waits, so the server answers only when there’s real data.
• “SSE can send data both ways.” It can’t. SSE is server-to-browser only. If the browser also needs to send a live stream, you want WebSockets.
• “WebSockets are always best for live data.” Not true. They’re best for two-way live data. For one-way feeds, SSE is lighter and easier.

🧩 What You’ve Learned

Good stuff. Here’s the recap:

• ✅ Normal HTTP is one-way: the browser must ask before the server can answer.
• ✅ Long polling holds the request open and replies only when there’s new data, so it beats plain polling.
• ✅ SSE keeps one connection open and lets the server push updates, but only one way (server to browser).
• ✅ WebSockets are the choice when both sides need to send data live.
• ✅ Prefer the lighter tool: one-way feeds suit SSE, two-way needs WebSockets.

🚀 What’s Next?

You’ve now seen the gentle ways to get live updates. Let’s connect them to the full-power option.

• WebSockets Explained is the two-way live connection these compare against.
• Choosing the Right Protocol pulls all of these together into one decision guide.

Get these down and you’ll always know how to move live data the right way.