Tech: Optimistic vs. Pessimistic UI Rendering

Julie Andrews never actually played Ensign Nellie Forbush, USN (the character who sings “Cockeyed Optimist” ) as far as I can tell, but she has the most popular recording of the song currently on You Tube.

“When the sky is a bright canary yellow
I forget ev’ry cloud I’ve ever seen,
So they called me a cockeyed optimist
Immature and incurably green.”

‘A Cockeyed Optimist’ from South Pacific, 1958

Since we are currently studying JavaScript, and UI rendering in particular, we are encountering something of a controversial topic: Pessimistic or Optimistic rendering? What is the difference between the two, and when are either of them appropriate?

So…great topic for a blog post, right? Apparently a lot of other folks on this site thought so too. When I started my research, the first 10 search returns were all posts on Medium.

I looked at a few of these articles to get a feel for how people were using OR vs. PR, and it was pretty much 95% in favor of OR. It all has to do with something called “user experience”. In the early days of the internet, some folks who know an awful lot about human psychology determined that there is a lot of psychological *stuff* you have to be aware of if you want your users to have a pleasant experience. If you aren’t aware of this *stuff* and your competitor is, it won’t matter how much better the widget you’re trying to sell is. Your competitor is going to get the business because your terrible storefront website drove all the customers away and his….didn’t.

One of the biggest elements of the “user experience” of a website is the response time to user input. The faster the response, the better the experience — up to a point. That point is roughly 100 ms, the point at which the human mind perceives the reaction to be instantaneous; any effort to improve beyond that is wasted. One might think that with modern computing power and processor speeds 6 orders of magnitude faster than that, that achieving a <100 ms response time from even the slowest, most carelessly designed website would be a piece of cake.

This turns out not to be the case; when you get routers and switches, multiple hops and remote servers (that may be dealing with 1000s of GET requests a second) involved, 100 ms starts to look at least very ambitious, if not downright impossible. This is a tracert I just executed on my computer to check the connection time between it and arguably the most powerful and advanced website on Earth:

Tracert run from an AT&T connected computer in Houston, TX to the nearest Google data center. Google doesn’t generally give out the exact locations of their data centers for security reasons, but I believe this one is located in Midlothian, TX, just outside Dallas.

Add it up and its double the target response time, and that’s just for a simple SNMP request. Add in server response time, load balancer response time, local security appliance response time, and you can start to see that we’re a long way from being able to completely disregard when (and how often) we send our GET, POST and PATCH requests.

This is where Optimistic Rendering comes into play. This type of design assumes a very high probability of a successful transaction with the remote server and updates the DOM immediately, before any AJAX actions are taken. In this way, the user sees the result of their input immediately. The code is executed before the server request even takes place, then afterward the server is updated with the user’s input:

At line 16 the function is called to modify the DOM, then starting at line 18 the PATCH is done on the server.

So, if OR is so great and necessary for almost every application, why even teach PR at all? Because some applications require Six-Sigma reliability, 97% isn’t good enough. Banking and other security operations are good examples of this; the client needs to be absolutely certain their data is delivered and verified before rendering it to the display, and doesn’t mind a bit of extra delay for this security. In this instance the fetch is completed, then the modification to the DOM is made. The code is exactly the same, just the order of execution changes.

Imagine how rich the guy who first wrote this app is today…

BUT, this is I think where a lot of the discussion on the topic stops. Developers already have a lot on their plates, and worrying about things like network latency and load balancing aren’t among them. They have Systems engineers to do all that sordid “content delivery to the user” work. But by using OR (even if they may not fully understand why) they are making the lives of those people much easier by building in easier scalability. Everyone hopes to create the next Angry Birds and have 100 million users, but if you design your apps at the outset to be kind to the servers they require to operate, you’ll be more ready to handle that hoped-for gigantic future workload.