3 ms·

> The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverti

> The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. 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.

read_if_gay_ 6y ago
Network roundtrip is still going to introduce noticeable latency even assuming everything else is literally instant.
Wohlf 6y ago
>I'm just not sure why engineers don't insist of fixing things the right way. That's like saying "just fix global warming", it's more complicated than that.
mike_d 6y ago
> 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. https://en.wikipedia.org/wiki/Tachyonic_antitelephone https://en.wikipedia.org/wiki/Tachyonic_antitelephone
NikolaNovak 6y ago
>>It's easier than making the UI and server faster for sure 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...