3 ms·
I do feel that this is a multifaceted problem. On one hand, yes, end-user expectations have gone up. Back in the early naughts it was perfectly fine to wait ~8
by seangrogg 6y ago
I do feel that this is a multifaceted problem.
On one hand, yes, end-user expectations have gone up. Back in the early naughts it was perfectly fine to wait ~8 seconds for an image to load block by block, kicking around the layout and content as it did so - and that was the status quo. It was fine. Nowadays if I don't get all icons and thumbnail-ready images near-immediately I assume something is wrong at some layer.
Another factor is how things are going over the wire. It's easy to point to web developers and say "Why not use SSR everywhere?" while they'll point back and say "Client-side rendering lets the server scale better". As with most such complaints, the truth is often somewhere in the middle - SSR should be aggressively used for static content but if you have a non-trivial computation that scales linearly it is worth considering offloading to the client, especially if you're running commodity hardware.
Then there's the question of what we're doing. It very much used to be the case that most everything I did was over an unsecured connection and virtually all interactions resulted in page navigation/refresh - never anywhere close to being below my perception. Nowadays, many actions are below my perception (or at least eagerly evaluated such that it seems they are) while non-trivial actions are often going through SSL, requests balanced across multiple app servers, tokens being authed, and eldritch horrors are invoked by name in UTF-8 and somehow it all gets back to me around the same time as those page refreshes were back in the day.
This most certainly isn't to say that we don't have room for improvement: we most certainly do. But like most systems, as the capabilities improve so, seemingly, do the requirements and interactions that need to be supported over it.