Optimistic Frontend Development

In the world of web and mobile apps, there's a lot of planning, designing, and decision-making, even mid-development. When you already have a complex system in place, new features can break the app's UX, your code, or its performance.

Let's consider an example.

We need to add a “favorite” feature to our posts. After a user saves a post as a favorite, three other actions have to run. We trigger an email, send a push notification, and update the recommendation algorithm. A favorite feature seems as easy as it gets. But the logic behind it can take a long time. It can even break after the user has already waited for the response. This is where we have to make a decision. And it's as much a UX decision as an implementation one.

Many other scenarios lead to the same choice. Think of multiple microservices, where the favorite action travels through quite a few of them. Or an email that fires when someone favorites your post.

To go deeper and give you something visual, I also prepared a short video.

The app

Our app is simple, but very important to our customers, which is currently just me. It's a feed of meme templates. I was lucky to find Imgflip's API and built a simple feed. It fetches a number of meme templates and shows the title and image. It also adds a favorite button to each post. At Wolfpack Digital, we mostly use Vue or Nuxt (here's why), so I went with the same stack.

The like/favorite button was set up like a booby trap. I always made the user wait 3.5 seconds. After that, the action had a 50-50 chance to fail. This let us reproduce both success and error behaviour and see how the app reacts in each case.

The natural first thought that doesn't really work

My first thought for actions that might take a while is to add a loader. Working with mobile apps has shaped this habit a lot. The idea is to update the UI only when the action succeeds. If the action is quick, that's great. But what if it takes a long time? I'd need to block the user from pressing the same button again while it loads. I'd also want to load only that one item, so the rest of the UI stays usable for such a minor action.

Error handling is another big issue. The user hits like on a post, sees the loader, but keeps scrolling. Two seconds later, or after liking ten other posts, an error message says the action failed. That's confusing and frustrating.

Optimistic rendering: I got 99 problems but stopping the user ain't one

Optimistic updates, also called optimistic UI, is a pattern common in frontend and UX development. Different actions update the interface instantly, without waiting for confirmation from the server.

GitHub is one of many companies that do this. You'll see similar behaviour on Twitter, Facebook, and Instagram. When I hit the star icon, the UI updates and the API call starts. The UI shows the change long before the response comes back.

So let's update our code. It's simple. Instead of updating the UI inside the .then after the awaited API call, we update it before we even call. All that's left is error handling and rolling the UI back if the action fails. Modern frameworks make this even easier: React 19, for example, ships a built-in useOptimistic hook for exactly this pattern, though the underlying idea stays the same across Vue, Nuxt, and any other stack.

The result makes much more sense from a UX standpoint.

Error handling

You've just read about how we update the UI and assume it will work. But we still need code to know if something failed.

The video below shows what I'd call bad UX, and the biggest weakness of this pattern: how to show a failed action. The user usually moves on and scrolls further. Showing an error then just makes everyone wonder which action failed and why they're pulled out of their flow for something that happened seconds ago.

This doesn't mean we skip error handling. It means we choose our behaviour carefully:

• Log the error and never show a visual failure to the user.
• Show a clear but subtle error message, so you know which action failed.
• Offer a retry, such as a small button for the area that failed.
• Update the UI back to the correct state as soon as you learn a call failed, with no heart icon left behind.
• Use silent retries, but set a limit.

Important decision-making

This pattern isn't great in every situation. It swaps one bad experience, waiting too long, for one that may be worse but happens far less often. That's why we need to choose wisely. Here are some good points to weigh during the decision:

• Avoid it for destructive or constructive actions, such as deleting, creating, or editing an entry, especially at the end of a long flow.
• It works great with boolean actions, like marking or unmarking a favorite, or liking and unliking.
• Apply it only to reliable API calls. For a small binary action with a success rate of just 50 percent, this is not a good option.
• The same is true if the API is always slow. We're trying to be optimistic, but letting the user fire off many actions with a successful UI update, before the earlier ones are confirmed, is risky.
• Sometimes a delay is expected, such as a change in permissions, where it's better to wait for confirmation.

Conclusion

This pattern needs a high level of communication with the design team, since it affects the UX of the whole app. The core idea assumes a reliable and ideally binary action will complete, so we update the UI before the confirmation arrives.

You'll see similar optimistic patterns in multiplayer games and in concurrency, where multiple locks are managed with the hope they won't interfere with each other.

I hope this article helps you make better decisions. If you build with these stacks, take a look at our Vue.js development and Nuxt.js development services, or see how our web development team works. And if you'd like to keep learning, check out our guide to understanding business logic as a QA specialist. You'll find plenty of decision-making tips there too.