Lecture
Modern web applications stopped being just "forms with buttons" long ago. Users expect the interface to react instantly, data to update smoothly and everything to keep working reliably even on an unstable network. That is precisely why the approach to updating the UI has become a key part of frontend architecture.
There are several strategies that determine when the interface is updated, where the data comes from and how the system behaves when there are network problems. Among them are the optimistic and pessimistic approaches, caching based on the stale-while-revalidate model, real-time updates over WebSocket, and offline-first architecture.
Understanding these approaches lets you do more than just "update the data" — it lets you design a UX that feels fast, reliable and modern.
The main approaches to updating the UI
Show the result immediately, without waiting for the server
Key idea: "assume everything will succeed"
Server first → then the UI
Key idea: "until the server says so, we change nothing"
Show the cache → refresh in the background
Typical in:
Key idea: "old first, then new"
The data arrives on its own
Key idea: "we don't request — it gets pushed to us"
The UI may be temporarily "inaccurate"
Key idea: "it's OK to be imperfect for a while"
Works without an internet connection
Key idea: "the server isn't required right now"
Show a loading state
Key idea: "we honestly show that you're waiting"
The server controls the UI
Key idea: "the UI logic is not on the frontend"
This can be boiled down to 3 global strategies:
In practice a combination is almost always used:
Optimistic UI is a frontend approach in which the interface immediately shows the successful result of the user's action without waiting for a response from the server.
Usually:
Optimistic UI:
Let's say we are liking a post:
// optimistic update
setLiked(true);
setLikes(prev => prev + 1);
try {
await api.post('/like');
} catch (e) {
// rollback
setLiked(false);
setLikes(prev => prev - 1);
}
Here are the main alternatives and related patterns:
The opposite of the optimistic approach
How it works:
setLoading(true);
await api.post('/like');
setLiked(true);
setLoading(false);
First we show the old data, then we update it
Popular in the libraries:
How it works:
The server controls the state of the interface
Data arrives on its own (without a request)
Technologies:
Used in:
The UI tolerates temporary inconsistency
Often together with:
We show a skeleton instead of a spinner
{loading ? : }
The user sees the structure in advance → better UX
The app works without an internet connection
Used in:
| Scenario | Approach |
|---|---|
| Likes, chats | Optimistic UI |
| Money, transactions | Pessimistic UI |
| Frequent updates | SWR |
| Online data | Real-time |
| Poor internet connection | Offline-first |
Optimistic UI is not just "speeding things up", it is a contract with the user:
"We assume everything will go through successfully — and we show that straight away"
But you are obliged to:
Approaches to updating the UI are not mutually exclusive options, but a toolkit that you combine depending on the task. Real applications rarely use just one of them: most often it is a mix of optimistic UI, caching, background synchronisation and real-time events.
The key idea is not picking the "right" approach, but understanding the trade-offs:
By combining these strategies wisely, you can build an interface that is not only functional but also feels fast, alive and resilient to any network conditions.
Comments