Imagine the entire UI of an email client becoming inoperable, diplaying "loading..." and a spinner every time you send mail. We don't do it now nor did we do that when 300kbps connections were more common. Spinners are a crutch for undercooked, bad software.

From what I remember of Thunderbird and Outlook, they both showed a visual loading indicator somewhere in the UI.

Am I missing a detail of terminology here? By "loading spinner" I meant it in opposition to "do absolutely nothing for three full seconds and make me refresh the page with the network tab open." I didn't mean to suggest any particular indicator of a pending network request, only that there should be an indicator.

Yes see what you mean now. Sorry - I was imprecise with my wording. As a fellow Australian I feel the pain too by the way :)

> do absolutely nothing for three full seconds and make me refresh the page with the network tab open

This is what I was talking about. A pattern I see is papering over this deficiency with a massive “spinner”. Barely noticeable for the devs accessing the app on 127.0.0.1 on fancy machines - so frustrating for everyone else.

Absolutely agree indication of activity is important. Especially so considering how buggy many of these web apps are.

And ndriscoll is also unfairly generalizing. Which usually happens when you generalize because it's impossible to take all eventualities into account.

For example, I've worked on add-ons to other software. But it's cloud and you gotta make certain calls back to your "host" app. Said host app responds to most calls in more than the 150ms they claim is the max. Because of what guarantees our plugin makes to the user and despite us caching whatever we can we need to make multiple such calls to make our guarantees... well guarantees.

So what can we do? Of course we show spinners while we make those necessary calls and make absolutely everything we can get away with async.

But we can't get away from things potentially taking more than a second when something isn't in cache, the host app is slower than usual and under 150ms is impossible for anything that doesn't just hit our own database.

Until like a year ago, thunderbird froze the whole UI when fetching mail

Spinners don't have to replace the entire UI or make it inoperable. Classic email clients did indeed have a losding indicator when doing things like a "send and receive" operation.

Keep in mind that spinners can also be used (as well as other indicators) that something is being processed client side, e.g. rendering a video and if the total time can't be estimated a spinner is reasonable.

You didn't use email software with a blocking send and receive button? Usually with a somewhat informative progress bar, but still.

Processing should be more like 6 ms though (assuming basic CRUD), not 60. The TLS/TCP latency can be solved with a TLS terminating proxy in the region. After that, unless you want spinners on every data fetch (a miserable experience), you probably want a read replica if you're actually trying to serve the region. If you're a big company, you probably want a full read/write setup in the area (which is something for big companies to figure out anyway with newer data protection laws).

Slow server calls and daisy chained sequential operations are both people doing a bad job. My last job had backend calls that took over 1s to do basic CRUD on a low traffic service (bouncing around a dozen micro services on the backend). That should never happen.

Spinners are a lie. Nowadays, you hardly encounter a spinner that actually shows the progress of the action you started.

For this reason, they are mostly useless. Even worse than useless if errors aren't even propagated to the user.

It's pretty useful to indicate "network requests are in progress". I agree they lose their value if you don't handle errors.