WebSockets.
Leaving the phone line open instead of redialling before every sentence.
Ordinary web requests are like a phone call where you dial, say one sentence, hang up, then redial for the next. It works, but all that dialling is wasteful — and the other side can never call you, it can only answer.
A WebSocket keeps the line open. After one quick setup, you and the server hold a single connection where either side can speak at any time. That is what makes live chat, multiplayer games, and streaming dashboards feel instant.
- Calling… again.1
Plain HTTP redials for every exchange: ask, answer, hang up. Repeat.
- 2
A WebSocket starts with a quick handshake that upgrades the connection to stay open.
- 3
Now the line is held open — and either side can speak whenever, both ways.
- New message!4
The server can push to you unprompted — no need to keep asking “anything new?”
- 5
That is why chat, games, and live dashboards use it: instant, two-way, no redial.
- 6
The cost: an open line ties up resources, and dropped lines need reconnect logic.
Why not just ask repeatedly
Before WebSockets, “live” pages faked it by polling — asking the server “anything new?” every few seconds. That wastes requests when nothing changed and still feels laggy. A WebSocket flips it: the server speaks the instant something happens, over a connection that is already open, so there is no per-message setup cost.
What you give up
An open connection is stateful: the server holds one per client, which is more to manage and scale than stateless requests. Connections also drop — phones change networks, laptops sleep — so production code needs heartbeat checks and automatic reconnection. For request/response work that is not live, plain HTTP is still simpler and better.