I hate the phrase "I'm a realist not a pessimist" as much as the next person, but isn't this actually "realistic rendering"?
"Optimistic" often means "assume X, perform or calculate something, change the result if X turns out to be false".
"Pessimistic" often means "assume not-X, perform or calculate something, maybe change the result if X turns out to be true".
This comes up in other domains.
For example in compilers (and reverse engineering decompilers ;-) there are optimistic and pessimistic analyses.
An optimistic analysis might initially assume a particular variable has a specific value at a particular location, or a branch is always taken. Then trace through the program paths, using that assumption (which limits those paths). If it loops back to the location with a different value in the variable or different value for the branch condition, broaden the assumption and update the trace.
A pessimistic analysis might initially assume the variable at a particular location could have any value because it hasn't yet traced everywhere to find out the possibilities, or initially assume both directions at the branch could happen and include them both in the trace. By the time it finishes tracing all paths and values, those assumptions may turn out pessimistic and it can start pruning away unused options.
These two strategies can yield different answers, and for some analyses the optimistic strategy gives more accurate results than the pessimistic strategy.
So which one is more "real"? :-)
FYI, Signal has used this paradigm for quite some time (I'm not sure which software predates the other on this feature), it's two checkmarks which remind me of the old "open Apple, closed Apple" keyboard keys - message bubble is shown with two open checkmarks right away, a single closed checkmark means the server has received, the second closed checkmark means the other end has received (assuming read receipts are enabled, Signal allows them to be turned off for privacy reasons).
You post a message, it looks good, you move on.
Then later on you come back to it and it was never sent.
The only way I found to know that your message has been received is to have an ack from your interlocutor.
Viber had a similar thing long before FB's messenger: single gray check mark character if the message is sent, double gray check mark if it is received by the recipient and double check mark in purple if it is seen.
The only issue is with the purple color of the "seen" as it can sometimes blend into an image behind it (if the message was consisting of an image).
It's easier than making the UI and server faster for sure, I'm just not sure why engineers don't insist of fixing things the right way.
Einstein figured out why in 1907, and most of us have just been going along with the assumption that superluminal communication just isn't possible.
In majority of cases, I assume network latency will be the dominant factor, and that is outside the control of the engineers.
I happen to use slack from hardwired gigabit ethernet to a gigabit fiber internet connection. But I maintain some awareness that some others may use it from their older android phone with 2 bars of service, or on a laptop with 27 open blasting wifi spots, etc etc etc.
I will therefore put forward that assumption you can ensure instant communication, is the wrong wrong wrong way for engineers to write code...
The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly showing a loading spinner in the interim).
Facebook Messenger has the best UX paradigm for this I've seen, since it's most graceful in handling the edge case failures while still presenting as optimistic. Your message immediately appears as a conversation bubble, with an icon displaying if the server has received it, an 'X' if it fails (clicking the icon gives you options: re-send, delete, etc), and a read receipt for when the other party views the message. It's a fantastic way of handling the lifecycle.
Slack fails because it doesn't communicate that pending, the-server-hasn't-received-it-yet status, and the fallback isn't as graceful.