Half-full or half-empty? A quick look at Optimistic vs. Pessimistic Rendering
Quick confession… I’m a bit of a news addict. I’m not biased about it, I’ll read nearly any type, from news about my favorite sports teams to the latest updates on the upcoming election. I’ll even occasionally stray to topics on the very fringes of the “news” category, such as this BuzzFeed article about 18 Adorable Dog Posts To Spread The Good Vibe Gospel This Week.
Unfortunately and for no good reason, I all-too-frequently also find myself scouring the comments of these articles. This undoubtably means running across a pointless argument between two people who would never be this confrontational in person and clearly aren’t doing a good job of convincing anyone to come over to their side. Yet, again for no good reason, if I agree with one person and disagree with the other I’m always willing to tap that like or thumbs-up key as a tiny validation to the argument I support.
The point of this article is to examine what happens when I hit that like key. Frankly, the process is pretty uninteresting: I tap the like button and the webpage updates to display the new running total of “likes” and to offer the client an unlike option. That’s it. Generally, the client-experience in this situation boils down to speed. Therefore, if that like happens almost instantaneously, the client is satisfied. But this is 2020 so if it takes a few seconds, that can be enough to irritate the client and possibly push them away from your website. So how can a developer maximize speed and thus improve the client-experience? That’s where optimistic rendering comes in.
The easiest way to describe optimistic rendering is to first touch on its alternative: pessimistic rendering. When web-pages render pessimistically, they work like this:
1 — A client performs an action, such as a click, which sends an HTTP request to the server.
2 — The server processes the request and returns a response.
3 — The client’s application is changed based on this response.
To demonstrate how this looks, I’ll use the comment-liking action I mentioned earlier (as a note, “likes” would typically not render pessimistically because, again, that would cause an unwanted delay for the client). Here’s how it would look, however:
1 — I click “like” on a comment.
2 — My “like” is sent to the website’s server.
3 — Once the server processes the request and returns a response, the page is updated to reflect my additional like on the comment (assuming it was successful).
So that’s pessimistic rendering. What’s the difference, you ask? Well, essentially optimistic rendering removes the hold-up in the flow. Rather than calling to the server and forgoing future action until a response is received, the client’s application will render immediately and simultaneously with the call to the server. As the client makes a request, the client’s application will optimistically assume that that request was successful before it has received received a response from the server, eliminating the wait time that is caused by the call to the server. As compared to the pessimistic process, the optimistic process works like this (changes are in bold):
1 — A client (or user) makes a request to a page via an action, such as a click.
2 — The webpage is rendered to display the results of the client’s action. (I.e. adding and displaying an additional “like” and changing the button to an unlike option.)
3 — Based on the client’s action, a corresponding call is sent to the server.
4— The server processes the request and returns a response.
5 — If the request failed, the client’s page may again update or they may receive an error message.
There are appropriate times to use either optimistic or pessimistic rendering. While optimistic is often more client-friendly, there are certainly times when it is not a preferred option. For example, if a client is purchasing a ticket to a baseball game, it may not (or definitely wouldn’t) be a great idea to display “Your purchase was successful!” before the purchase has actually gone through. This preference for pessimism extends to almost any transaction on the web.
The moral of the story: in terms of a general approach to life, optimism is the way to go. When developing features for full-stack apps, however, I’d recommend allowing yourself a little more leeway to weigh the merits and drawbacks of optimistic vs. pessimistic rendering for your specific situation.
