Why the ChatGPT Browser Conversation System Uses EventSource Instead of WebSocket

1. Introduction

When building a browser‑based real‑time chat system, developers often choose WebSocket for bidirectional communication. However, in some scenarios EventSource can be a viable alternative. This article explores why the ChatGPT conversation system opts for EventSource instead of WebSocket, providing code examples and detailed reasoning.

2. Overview of WebSocket and EventSource

2.1 WebSocket

WebSocket is a full‑duplex protocol over a single TCP connection, allowing the server to push data to the client without the client initiating a request each time.

2.2 EventSource

EventSource (Server‑Sent Events) is a lightweight, text‑based protocol built on HTTP. It provides one‑way server‑to‑client push; the client can only receive events.

3. Characteristics of the ChatGPT Conversation System

Unidirectional communication: Users send messages to the model, and the model replies – a one‑way flow.

Long‑polling: The system typically waits for the model’s response using a long‑polling pattern.

4. Advantages of EventSource

4.1 Simplicity

EventSource works over plain HTTP, requiring no handshake or complex initialization. In the browser you only need to create an EventSource object with the server URL.

4.2 Robust fault tolerance

If the connection drops, EventSource automatically attempts to reconnect, relieving developers from manual reconnection logic.

4.3 Broad compatibility

Most modern browsers natively support EventSource, whereas WebSocket may need extra handling for older browsers.

5. Why Choose EventSource Over WebSocket?

5.1 Unidirectional communication model

The ChatGPT system only needs server‑to‑client messages after the user’s request, so the bidirectional capability of WebSocket adds unnecessary complexity.

5.2 Long‑polling suitability

EventSource naturally fits the long‑polling pattern used by ChatGPT, whereas WebSocket offers no clear benefit here.

5.3 Simplified deployment and maintenance

Because EventSource relies on standard HTTP, there is no need to manage WebSocket handshakes, heartbeats, or additional server configuration, resulting in a cleaner architecture.

6. Code Example Using EventSource

6.1 Server‑side implementation (Node.js + Express)

const express = require('express');
const { v4: uuidv4 } = require('uuid');

const app = express();
const port = 3000;

const clients = new Map();

app.get('/events', (req, res) => {
  const clientId = uuidv4();
  const newClient = res;
  clients.set(clientId, newClient);

  req.on('close', () => {
    clients.delete(clientId);
  });

  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  res.flushHeaders();

  clients.forEach((client) => {
    client.write(`data: A new user joined!\n\n`);
  });
});

app.post('/send-message', express.json(), (req, res) => {
  const { message } = req.body;
  clients.forEach((client) => {
    client.write(`data: ${message}\n\n`);
  });
  res.status(200).send('Message sent successfully!');
});

app.listen(port, () => {
  console.log(`Server is listening at http://localhost:${port}`);
});

6.2 Client‑side implementation (Browser JavaScript)

const eventSource = new EventSource('http://localhost:3000/events');

eventSource.onmessage = (event) => {
  const message = event.data;
  console.log(`Received message: ${message}`);
};

document.getElementById('sendMessageBtn').addEventListener('click', () => {
  const message = prompt('Enter your message:');
  fetch('http://localhost:3000/send-message', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ message }),
  });
});

The client establishes an EventSource connection, listens for onmessage events, and sends messages via a simple POST request. The server broadcasts incoming messages to all connected clients.

7. Performance Considerations and Extensions

7.1 Performance

WebSocket generally offers lower latency and higher throughput because it maintains a persistent TCP connection. For simple, low‑real‑time‑requirement scenarios like the current ChatGPT UI, EventSource performance is sufficient and its simplicity is advantageous.

7.2 Future extensibility

The system could later add optional WebSocket support for use‑cases demanding ultra‑low latency, providing a flexible communication layer that adapts to different performance needs.

8. Conclusion

EventSource provides a straightforward, reliable, and widely compatible solution for the ChatGPT browser conversation system’s unidirectional, long‑polling communication pattern, while keeping deployment and maintenance simple. Developers can still extend the architecture with WebSocket if future requirements evolve.