Optimistic UI feels fast but can lie
Aliases: optimistic update · local-first write · fake success
What it is
A like lights at once, a comment appears at once, a switch flips at once — the interface mutates locally on the bet that the request will succeed, and the network result follows. That bet is an optimistic update. What it buys is responsiveness: action and consequence still code as one event. What it owes is a divergence window: the world on screen and the world on the server are briefly not the same. Inside the window, something the user treats as done may never have been written.
This leaf is the trade. Whether the pattern belongs on irreversible acts, and how to speak after a failure, are other leaves.
Why it happens
In human–computer dialogue, feedback later than about a tenth of a second splits action from result; later than a second, the thread of thought starts to break. Networked writes almost always miss both seams, so products paint the “already written” pixels first and fill the gap from local state. The server reply is a second beat: confirm and the window closes, screen and truth coincide; reject and the window becomes a debt — words the screen already said have to be taken back.
Harm from the window scales with how true the lie was treated as. A like that lights may be tapped again; cheap. A thread that already shows “sent” lets the person leave and start the next job; later decisions now sit on a false fact. Optimism holds when the failure rate is low enough that divergence feels like a rare glitch, not the system’s standing lie. Raise the failure rate and distrust erases the responsiveness account.
Where it stops holding
Read-only refreshes, search suggestions, scroll position have nothing to be optimistic about. Operations the device can settle alone (pure UI collapse, an unsynced draft) are truly local, not optimistic. Strongly consistent ledgers, a stock of one, several people editing the same cell: failure is not rare, and optimism postpones the collision until the user has already walked away. On a weak link or an admitted offline, “write it down first” is expected, and divergence reads as a queue rather than deceit — provided the interface admits the server has not been reached, rather than painting arrival.
Applying it
- Optimistically write only what fails rarely, can be taken back, and does not trigger a later irreversible decision: likes, read receipts, reorder, short comments.
- Keep optimistic and confirmed visually distinct for anyone who has to check (e.g. “sending” versus “delivered”). Do not paint both as the same success.
- Measure the true failure rate. If it sits above a few percent, fix the network or the permission, rather than papering latency with optimism.
- How to check: pin the write endpoint to error and tap an action that “should succeed”. If the UI paints success and later reverts with no account, responsiveness was bought with divergence and the trade does not hold — either drop optimism or treat the fork as an event. Then a slow network: the press-to-pixel change should still sit inside the instant window; the round trip may follow.