BYD TechThe short answer
WebSockets open a two-way connection where browser and server can both send messages at any time, which suits chat, collaboration and multiplayer features. Server-sent events, or SSE, are a simpler one-way stream from server to browser over normal HTTP, with automatic reconnection, which suits notifications, live dashboards and streaming AI responses. Polling, asking the server every few seconds, is the simplest of all and fine when updates are rare.
Key points
- WebSockets: two-way, for chat and collaboration.
- SSE: one-way from server, simpler, reconnects automatically.
- Streaming AI answers usually use SSE.
- Polling is fine for slow-changing data.
- Managed real-time services save running your own connection servers.
Side by side
| Polling | Server-sent events | WebSockets | |
|---|---|---|---|
| Direction | Client asks repeatedly | Server to client | Both ways |
| Protocol | Normal HTTP | Normal HTTP | Its own protocol after an HTTP handshake |
| Reconnection | Not needed | Automatic | You handle it |
| Data | Any | Text | Text or binary |
| Complexity | Lowest | Low | Higher |
| Good for | Data that changes every minute or so | Notifications, feeds, streaming AI output | Chat, collaborative editing, games |
Server-sent events
With SSE, the browser opens one request and the server keeps it open, sending events as they happen. MDN notes that it is a one-way connection, and that the browser reconnects by default if the connection drops. Without HTTP/2, browsers allow only six SSE connections per domain across all tabs, so serve it over HTTP/2.
AI chat interfaces commonly stream answers token by token this way, which is why text appears as it is written.
WebSockets
The WebSocket API opens a persistent, two-way session between browser and server. Either side can send at any moment with very little overhead, which is what chat, presence indicators, cursors in shared documents and multiplayer features need. The cost is more to manage: reconnecting, scaling many open connections across servers, and authenticating the connection.
How to choose
- Updates every minute or so, few users: polling.
- Server pushes updates, client rarely sends: SSE.
- Both sides send often, low delay matters: WebSockets.
- Do not want to run connection servers: a managed real-time service, such as Supabase Realtime, Pusher or Ably.
Whichever you choose, check permissions when the connection opens and for every channel a user joins. Serverless platforms limit long-lived connections, so check yours. See What is serverless?. Real-time features are part of web app development.
Sources
Checked when this guide was written.
