Optimistic UI

While a press waits on a server response, the screen looks frozen. Six hundred milliseconds is short as a number and long under a fingertip. Rename a document and a loading state, the spinner that says something is being fetched, turns briefly before the new name appears — and someone renaming five documents in a row waits through five of them.

Most of that waiting bought nothing. A rename request fails fewer than once in a hundred times. Every user waits on every response for the sake of the other ninety-nine. Worse, someone who sees a spinner often decides nothing happened and presses again.

So the order got reversed. If something will almost certainly succeed, showing the successful state first and rolling back on the rare failure is the better trade.

It runs in three steps.

1. When the user acts, the request goes to the server while the screen changes to its successful state immediately. Rename something and the new name appears in the list right there; press like and the count goes up at once.
2. When a successful response arrives, nothing happens on screen. The correct state is already displayed.
3. When a failure arrives, the screen rolls back to its previous state and an error state, which says something went wrong, goes in its place. Roll back silently and the user has no idea why what they did disappeared.

Step 3 requires holding the pre-change value. The name before the rename, the count before the like, gets kept somewhere so a failure has something to restore. Where the server generates a value, that slot gets a temporary one and swaps it after the response.

Two conditions decide where it belongs. Failure has to be rare, and rolling back has to cost the user nothing. Payments, deletions, and sending mail fail the second condition. Show something as sent and then undo it, and the user has already believed it arrived — that trust is far more expensive than 600 milliseconds of spinner.

"Make rename optimistic. If it fails we just roll it back."

Failure is rare here and rolling back costs nothing.

"Don't use optimistic for delete. Showing it gone and having it come back is worse."

The rollback itself is the cost to the user.

"On failure it just reverts. We have to say why it didn't work."

Reverting without explanation makes users doubt their own action.

At Pagedeck, Noa and Theo split the list screen's actions in two. Rename and favorite went optimistic and lost the wait entirely, while document deletion still waits for the server response before the row leaves the list.