Life Before WebSockets
Before WebSockets, the web didn’t talk — it waited.
Imagine opening a chat app and repeatedly tapping Refresh just to see if someone replied.
That’s not a bug. That was the design.
If a server had new data, it couldn’t notify the client.
The client had to keep asking:
“Any update now?”
“Now?”
“Still nothing?”
This one limitation quietly shaped how real-time systems were built for years.
Enter WebSockets (The Turning Point)
Today, things feel natural.
You send a message → it appears instantly.
A leaderboard updates → no reload.
A dashboard refreshes → in real time.
That’s because of WebSockets.
In simple terms, WebSockets create a persistent, two-way connection between the client and the server. Once connected:
The server can push data whenever it wants
The client can respond immediately
No repeated requests
No refresh button anxiety
All of this happens over a single TCP pipe, kept open as long as both sides need it.
Basic WebSocket architecture diagram :)
But this wasn’t always the case.
So… How Did Developers Survive Before WebSockets?
Here’s the interesting part:
Developers did build real-time-like systems before WebSockets existed.
But they had to bend HTTP into shapes it was never meant for.
It worked — but at a cost:
More server load
More network traffic
More complexity
More hacks
Let’s walk through the journey.
Short Polling: “Are We There Yet?”
Short polling was the most straightforward approach.
The client asks the server at fixed intervals:
“Do you have new data?”
“No.”
“Okay… how about now?”
“Still no.”
Eventually, one request gets lucky and receives the update.
The downside?
Too many HTTP requests
Every request carried full headers
Latency was unavoidable
It worked — but inefficiently.
Long Polling: “I’ll Wait Here”
Long polling tried to be smarter.
This time:
The client sends a request
The server waits
When new data arrives, the server responds
The client immediately sends another request
Fewer wasted calls. Better efficiency.
But still:
Connections stayed open
Updates weren’t truly instant
Server resources were heavily used
A clever workaround — but still a workaround.
Server-Sent Events: “I’ll Just Listen”
Then came Server-Sent Events (SSE).
With SSE:
The client opens a single connection
The server continuously pushes updates
Data flows only one way (server → client)
This was a big improvement.
Even today, SSE is used for:
Live cricket scores
Stock price updates
News feeds
But there was a catch:
- The client couldn’t talk back over the same channel
Why WebSockets Changed Everything?
Polling, long polling, and SSE were all clever attempts to simulate real-time behavior on top of HTTP — a protocol that was never designed for it.
WebSockets didn’t just optimize performance.
They changed the mental model.
The web stopped asking,
and finally started listening and speaking.
And once that happened, real-time applications stopped feeling like hacks — and started feeling natural.
Sometimes, the biggest breakthroughs aren’t about new features, they’re about removing old limitations.
