Optimistic and Pessimistic UI Rendering

In our current technological phase, speed is no longer a feature but a requirement. Developers know Longer wait times lead to users experiencing negative feelings and the impression that the website or app is unreliable. Hence, the chances of losing a user in the app are highly likely. The introduction of AJAX has been a significant addition to the rich user experience. The user can interact with the page even though other tasks run in the background.

The ability to render content without having to refresh has become a UI standard that users have come to expect. However, users demand more fluidity from their apps and for their content to appear instantly. This is because processing requests and returning content to the user takes a specific period.

This scenario is where the optimistic and pessimistic approaches come to play. While they begin at the same place, how they treat the AJAX request differs.

For the example let's suppose we have a list of users displayed on the screen, and we want to update the screen as the user are deleted.

Pessimistic Approach

The Pessimistic approach updates the UI once the API call is completed and the data or state has been confirmed. This approach prioritizes consistency and reliability over instant feedback to the user.

The typical pessimistic flow for the above example is as follows:

• A user clicks on the delete button

• A request is sent to the server for deleting the user

• The server sends back either a successful response, or an error message in case of failure

• According to the response sent by the server the client-side application either updates the content or displays the failure message

All while this is happening, the user is waiting to see changes in the UI. Even though this might take only a few seconds, it has a noticeable effect on the user experience. A pessimistic approach can result in a slower and less responsive user experience.

Example

deleteButton.addEventListener("click", function (event) {
  //Server call begins
  deleteUser(api_url)
  .then(response => response.json())
  .then(json => pessimisticUserUpdate(json))
  .catch(error => console.error(error))
  //Server call ends
})

// a helper function that updates the user list 
function pessimisticUserUpdate(json){
  updateUser();
}

In the above example, first, the delete button is clicked, then the request is sent to the server; once the server sends the response, the user list is updated and rendered onto client-side

Optimistic Approach

In the Optimistic approach, the UI is updated immediately with the new data or state before the API call is completed. This approach prioritizes instant feedback to the user over consistency and reliability.

The typical Optimistic flow for the above example is as follows:

• A user clicks on the delete button

• The state of the content changes update

• A request is sent to the server for deleting the user

• The server sends back an error message in case of failure

• According to the error sent by the server the error is displayed on the client app and the state is changed to the original state

Example

deleteButton.addEventListener("click", function (event) {
  optimisticallyUpdateUser();
  //Server call begins
  deleteUser(api_url)
  .then(response => response.json())
  .then(json => console.log("user deleted successfully"))
  .catch(error => {
    console.log("Something went wrong while deleting the 
    user");
    revertOptimisticChange();
  })
  //Server call ends
})

// a helper function that updates the user list 
function optimisticallyUpdateUser(json){
  updateUser();
}

In the above example, first, the user clicks on the delete button, then the state changes and the updated user list is rendered on the client side. After that, API is called; if the API request fails, the user state is updated back to its original form.

Conclusion

The optimistic approach is generally preferred for cases where speed and responsiveness are essential and where the risk of displaying inconsistent data is low. However, in cases where data consistency is critical (such as financial transactions or medical records), the pessimistic approach may be more appropriate.