Long Polling vs SSE vs WebSockets vs Comet in JavaScript

By the end of this page, you will understand what Long Polling, Server-Sent Events (SSE), WebSockets, and Comet are, how they send data from server to browser, and when each approach makes sense. You will also see why the server can "keep a connection open," how the browser receives new data, and why Node.js is often mentioned in real-time discussions even though PHP can also be used in some setups.

Real-time web communication is about reducing the delay between when something happens on the server and when the browser learns about it.

In classic HTTP, the browser sends a request and the server sends a response. After that, the connection usually ends. This works well for normal web pages, but it is not ideal for things like:

• chat apps
• live notifications
• stock price updates
• multiplayer games
• dashboards

To make updates feel instant, several techniques were created.

Long Polling

With long polling, the client sends an HTTP request and the server waits before responding. If there is no new data yet, the server keeps that request open. As soon as new data is available, the server sends the response. Then the client immediately sends another request and waits again.

So it looks like a continuous connection, but it is really a repeated cycle of request -> wait -> response -> new request.

Server-Sent Events (SSE)

SSE is a browser feature built on top of normal HTTP. The client opens a connection to the server, and the server keeps sending text-based event messages over that same response stream.

Important detail:

• communication is one-way: server -> client
• great for notifications, feeds, progress updates
• simpler than WebSockets when the browser does not need to send lots of real-time messages back

WebSockets

WebSockets start with an HTTP request, then upgrade the connection to a special protocol designed for ongoing two-way communication.

After the upgrade:

• client and server can both send messages at any time
• the connection stays open until one side closes it
• lower overhead than repeated HTTP requests

Think of each technique like a different way to receive updates from a restaurant kitchen.

Long Polling

You ask, "Is my order ready?" The staff does not answer right away. They wait until it is ready, then tell you. As soon as you hear the answer, you ask again.

That means you are repeatedly asking, but each question may stay open for a while.

SSE

You sit near a speaker that only the kitchen uses. The kitchen announces updates whenever something changes:

• "Order started"
• "Order ready"
• "Pickup now"

You only listen. You do not talk back through that speaker.

WebSockets

You and the kitchen are on a live phone call. Either side can speak at any time.

That makes it perfect for back-and-forth communication.

Comet

Comet is like the older collection of tricks restaurants used before they had better communication systems. Long polling is one of those tricks.

Long Polling Example

Client side JavaScript:

async function poll() {
  try {
    const response = await fetch('/poll');
    const data = await response.json();

    console.log('Received:', data);
    document.getElementById('output').textContent = data.message;
  } catch (error) {
    console.error('Polling error:', error);
  } finally {
    poll(); // start waiting again
  }
}

poll();

Server idea:

• wait until new data exists
• respond with JSON
• client immediately opens the next request

SSE Example

Client side JavaScript:

const source = new ();

source. =  () {
  .(, event.);
  .(). = event.;
};

source. =  () {
  .(, error);
};

Trace Example: Long Polling

Client code:

async function poll() {
  const response = await fetch('/poll');
  const data = await response.json();
  console.log(data.message);
  poll();
}

poll();

Server behavior:

• if no new message exists, keep the request open
• when a new message appears, return { "message": "New update" }

Step by step

1. poll() runs for the first time.
2. The browser sends GET /poll.
3. The server receives the request.
4. If no new event is ready, the server waits instead of responding immediately.
5. A new event happens on the server.
6. The server sends back JSON like:

{ "message": "New update" }

Long Polling

Useful when:

• WebSockets are unavailable
• older environments need support
• update frequency is low or moderate
• implementation simplicity matters more than efficiency

Examples:

• job status updates
• simple notification systems
• admin dashboards with occasional changes

SSE

Useful when:

• the server mainly sends updates to the browser
• the client does not need constant two-way messaging
• you want simple browser support with HTTP semantics

Examples:

• live news feeds
• deployment logs
• progress bars for long-running tasks
• live monitoring dashboards

WebSockets

Useful when:

• both client and server must send frequent messages
• low latency matters
• you need persistent two-way communication

Examples:

• chat applications
• multiplayer games
• collaborative editors
• trading platforms
• live cursor or presence updates

Comet

Useful mostly as historical understanding.

Examples:

• older real-time web apps before modern browser APIs
• legacy systems still using long polling or streaming hacks

In real projects, developers rarely think only in terms of the protocol. They think in terms of message flow, fallbacks, server limits, and user experience.

Common patterns

Guard clauses for connection state

if (socket.readyState !== WebSocket.OPEN) {
  return;
}

socket.send(JSON.stringify({ type: 'chat_message', text: 'Hello' }));

This avoids sending data before the connection is ready.

Parsing structured messages

Real apps usually send JSON, not raw strings.

socket.onmessage = (event) => {
  const message = JSON.parse(event.data);

  if (message.type === 'notification') {
    showNotification(message.text);
    return;
  }

  if (message.type === 'chat_message') {
    (message., message.);
  }
};

1. Assuming all real-time techniques are the same

They are not.

• Long polling: repeated HTTP requests
• SSE: one-way server -> client stream
• WebSockets: two-way persistent connection
• Comet: older umbrella term

2. Using WebSockets when SSE is enough

Broken decision pattern:

// Using WebSockets for a simple one-way notification feed

If users only need live notifications from the server, SSE may be simpler.

3. Forgetting to reconnect

Connections can fail.

Broken example:

const source = new EventSource('/events');
// no handling for errors or app state changes

Better:

source.onerror = (error) => {
  console.error('Connection issue', error);
};

4. Sending before the socket is open

Broken code:

const socket = new ();
socket.();

SSE vs WebSockets

Quick definitions

• Long Polling: client sends request, server waits, responds when data is ready, client repeats.
• SSE: browser opens an EventSource; server streams events over HTTP.
• WebSockets: browser opens a WebSocket; both sides send messages anytime.
• Comet: older umbrella term for server-push techniques like long polling.

Client APIs

// Long polling
fetch('/poll')

// SSE
const source = new EventSource('/events');

// WebSocket
const socket = new WebSocket('ws://localhost:3000');

When to use what

• Use Long Polling for compatibility or simpler fallback behavior.
• Use SSE for one-way live updates.
• Use WebSockets for true two-way real-time communication.
• Know Comet mainly as historical terminology.

Key rules

• Long polling is not the same as a permanent socket.
• SSE is one-way.
• WebSockets are two-way.
• The browser needs JavaScript event handlers to use incoming data.
• Real-time systems should handle reconnects and errors.

What is the difference between long polling and WebSockets?

Long polling uses repeated HTTP requests that stay open until data is ready. WebSockets use one persistent two-way connection.

Is SSE better than WebSockets?

Not generally. SSE is better when you only need server-to-client updates. WebSockets are better when both sides need to communicate in real time.

Is Comet the same as long polling?

Not exactly. Long polling is one Comet-style technique. Comet is a broader, older term for browser push workarounds.

How does the server keep a connection open?

It simply delays finishing the response, or in the case of WebSockets, keeps the upgraded connection alive for future messages.

Can PHP be used for WebSockets or real-time apps?

Yes, but usually not with the most traditional request-per-page PHP setup. Real-time PHP often uses specialized libraries or separate services.

Why is Node.js often used for real-time apps?

Because its event-driven model and ecosystem made it popular for handling many simultaneous connections efficiently.

Should I use WebSockets for notifications?

Only if you also need two-way communication. If the server just sends updates to the browser, SSE is often simpler.

Do I still need JavaScript on the client?

Yes. The browser receives events, but your JavaScript code must decide what to do with the data.

• HTTP request-response — the foundation that long polling and SSE build on.
• AJAX — often used to implement long polling in older and modern apps.
• Event-driven programming — real-time APIs trigger callbacks when data arrives.
• JSON — a common format for messages sent over SSE or WebSockets.
• Socket.IO — a popular library that simplifies real-time communication patterns.
• Node.js event loop — relevant because Node.js is often used for connection-heavy real-time apps.
• Concurrency — important when many clients keep connections open at once.
• Load balancers and proxies — can affect long-lived HTTP and WebSocket connections.