Optimistic and Pessimistic UI Rendering Approaches

Alejandro Belgrave
May 16, 2019 · 3 min read

In our current phase with technology, speed is no longer a feature but a requirement. Web developers know that you have on average 15 seconds to capture a user to have them stay on your app. There is even less time to retain a user if there is no content appearing on the screen. The introduction of AJAX requests in development helped alleviate blocking due to undeterminably long requests from our programs, allowing users to interact with the page while those tasks are being done in the background. These changes, however, were not enough, as the rapid adoption of AJAX in code bases shifted from being a feature to becoming the expected standard. This is where Optimistic and Pessimistic approaches come into play.

Optimistic and Pessimistic UI rendering are simply two different approaches to displaying information to the user. While they begin at the same place, the way in which they treat the AJAX request differs. The remainder of this post will explain how these two approaches differ. For an example, I will use the liking feature used in many social media web applications. When a user clicks a like button, the button changes to show that the content has been liked.

Pessimistic Flow

With the introduction of Web 2.0 and AJAX requests, we could make a page more dynamic by rendering specific content after certain events, while doing all of the work in the background. The typical (pessimistic) flow is as follows:

  • A user clicks the like button of a post they like
  • A call is sent to the sever registering the information
  • The server sends back a Response to the page
  • Based off of the Response, the state of the button and page changes

Here is what this would look like in vanilla JavaScript.

As we can see from the code snippet above, the important part to note about the pessimistic approach is it allows us signify changes made by user when we are certain of the the result. Also, because it is an asynchronous request, the user is able to interact with the app while we perform the server calls.

Optimistic Flow

The major downside of pessimistic rendering, and cause of wait time, is the fact that the program has to wait for a response from the server to continue to the rendering. Taking a leap of faith, the optimistic approach solves this by essentially cutting out the middle person. The typical flow is as follows:

  • A user clicks the like button of a post they like
  • The state of the button and page changes

Unlike the pessimistic approach, the optimistic approach does not wait for the server to trigger the event’s success state. Instead, it is optimistic about the success of the server call it will make and acts accordingly. This is because in reality from the standpoint of a developer, the flow is as follows:

  • A user clicks the like button of a post they like
  • The state of the button and page changes based on the click
  • A call is sent to the server registering the information
  • Most of the time, the call will be successful
  • In the off chance the call fails, then say something to the user

Here is what this would look like in vanilla JavaScript.

Here, the user click is immediately sent to a success state and only notifies the user if the server call actually fails.

Ultimately, optimistic approaches give the user more immediate feedback to their input, enabling them to feel more engaged with the web application.

Summary

It is important to note that one approach is is not universally better than the other; each one has their pros and cons. The best case scenario for using optimistic programming is when the actions are akin to simple binary actions where success and failure reactions are expected. However, if the cost of an action is significant, i.e. purchasing tickets or making a bank transaction, it is better to use pessimistic methods to ensure the user is presented the correct information.

Resources

https://medium.com/@duncandevs/ui-rendering-optimistic-vs-pessimistic-e8e0f4df264

https://www.crazyegg.com/blog/why-users-leave-a-website/

Alejandro Belgrave

Written by

Technologist specializing in Software Engineering. Diving deeper into how things work and why. Just sharing my questions and discoveries in real time.

More From Medium

More from Alejandro Belgrave

More from Alejandro Belgrave

.then(what?!)

Related reads

Also tagged Programming

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade