alt Hacker News> loading bars (replaced with throbbers)
There is a very practical reason for this; most GUI apps are webapps (whether local or not is irrelevant), and the fetch API was so poorly thought out that it was not possible to get an indicate of progress - all if gives you is inprogress or done (nothing in between).
As a result the loading indicator can only indicate in-progress or done.
There might have been worse ways to design the fetch API, but off-hand, I can't think of any - what came before it was immensely better for a user experience.
Replies
Most of the time you're fetching multiple things in parallel and you could show a progress of how many of those are done (perhaps weighted by estimated size). That's essentially the way many progress bars work.
> As a result the loading indicator can only indicate in-progress or done.
We used to have the cursor indicating this in the good old days.
With a better API we could have a progress bar that goes through the TCP/IP stack: advance when the domain is resolved, when a handshake is finished, when the request is sent, when the response starts streaming back, when the response finishes.
It'd be a very jumpy bar, but it helps develop intuitions. "The first part is always slower on this machine", "when it gets stuck on this spot I need to reset my router", "this part will be slow because the request is large", etc.