Pessimistic vs Optimistic UI Rendering in Javascript
“Three user interfaces (UIs) go to a pub. The first one orders a drink, then several more. A couple of hours later, it asks for the bill and leaves the pub drunk. The second UI orders a drink, pays for it up front, orders another drink, pays for it and so on, and in a couple of hours leaves the pub drunk. The third UI exits the pub already drunk immediately after going in — it knows how pubs work and is efficient enough not to lose time.”
— from https://www.smashingmagazine.com/2016/11/true-lies-of-optimistic-user-interfaces/
Learning javascript is an emotional rollercoaster. Some days go very well and others not so much. While it can be difficult, it is also incredibly rewarding to understand the flexibility inherent in the language. One of the concepts that I struggled to wrap my head around is the difference between Optimistic and Pessimistic UI rendering. As technology and people evolve, there is a concurrent evolution in people’s expectations surrounding their experiences with technology. Long gone (very long gone) are the days where people would tolerate load times on a page that last more than the blink of an eye; in fact, research shows that the optimal response time for a simple interaction is 100 milliseconds! Longer wait times lead to users experiencing negative feelings and the impression that the website or app is unreliable.
How does Javascript handle this need to appease the user? Through something called Optimistic Rendering of the UI. In this case, “optimistic” refers to the high level of confidence surrounding a particular response from a server to which a client is making a request. Because of this high level of confidence, the UI updates what the user sees before receiving confirmation from the server that, in fact, everything went smoothly.
All this is well and good, but what does it mean for our code? Well, in vanilla Javascript, in order to render information optimistically, it must be rendered before a post, patch or delete request is made to the server.
On line 27 of the above code snippet, a function to create and display a new element on the DOM is invoked before the post request is called to update the server with the information in that new element. This is essentially saying “I am between 97–99% confident that everything is in place to update the server accordingly…so I’m just gonna go ahead and show you this cool new dog right away.” Optimistic rendering is the preferred method of DOM updating for many websites. But then why don’t all apps use this method?
Well, there are cases in which you are handling sensitive data, where you want to be 100% sure that there have been no problems with the server and that the data displayed to the client has been verified to be accurate. Banking applications are excellent examples of this. When you want your app to wait to hear back from the server before rendering data, this is Pessimistic Rendering of the UI.
In this case, as seen in the code above, you would place the invocation of the function to create and display the new DOM element in a promise chain, so that it is waiting for the response from the server. It will then parse the json from the server, and finally create the element. This way, whatever data has been rendered to the page has been sent back from the server and has been “checked” to a certain degree.
Neither pessimistic or optimistic rendering can be said to be “the best” way of displaying information to users. It all depends on what an app is doing and how sensitive the data is. As developers, we need to make informed decisions as to how best to handle rendering requests.