WebSockets are frequently added to applications that don’t need them, and occasionally missing from applications that do. Understanding when real-time bidirectional communication is genuinely necessary prevents both over-engineering and feature gaps.
How HTTP Works (and Its Limitation)
Standard HTTP is request-response: the client sends a request, the server responds, the connection closes. For most web applications (load a page, submit a form, fetch data), this is perfectly adequate. The limitation: the server cannot push data to the client without the client asking. If you need the server to notify the client of changes (new message, updated price, live score), HTTP alone requires polling.
Polling vs. WebSockets
HTTP polling: the client asks “any updates?” every N seconds. Simple to implement, works everywhere, but generates unnecessary requests when nothing has changed and has latency limited by the polling interval. WebSockets: a persistent bidirectional connection — once established, either side can send data at any time. Zero latency beyond network delay; no wasted requests. The cost: more complex to implement, harder to scale (WebSocket connections are stateful and persistent), and requires WebSocket support in the infrastructure.
Server-Sent Events (SSE)
SSE is the often-overlooked middle ground: a one-way persistent connection where the server pushes to the client. Simpler than WebSockets, uses standard HTTP, and is sufficient for many “real-time” use cases: live feeds, progress updates, streaming AI responses (this is how ChatGPT’s streaming response works). Use SSE when you need server-to-client updates but not client-to-server real-time communication.
When to Use Each
HTTP: everything that isn’t real-time. SSE: live feed, progress bars, streaming text output, price updates. WebSockets: chat (bidirectional), multiplayer games, collaborative editing (Google Docs-style), live trading platforms. Most applications that think they need WebSockets actually need SSE.
