4 ms·

> 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 fet

> 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.

zozbot234 6mo ago
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.
BoppreH 6mo ago
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.
- mlhpdx 6mo ago
  Perhaps an aside, but the things we do to compensate for the warts of TCP are staggering.
  - lelanthran 6mo ago
    This isn't a TCP problem, though. It's a fetch API problem. Even if fetch ran over UDP, or a direct serial connection, or IP over Avian carrier, it'd still be a poor API that doesn't allow progress indication.
hulitu 6mo ago
> 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.
reaperducer 6mo ago
As a result the loading indicator can only indicate in-progress or done. This is a failure of whatever framework the web dev is leaning on instead of actually programming the computer. It is perfectly possible to get real progress information other than yes/no. Web sites had it for years before lazy spinners took over.
- lelanthran 6mo ago
  >> 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. > This is a failure of whatever framework the web dev is leaning on instead of actually programming the computer. No, it's a failure of fetch.

zozbot234 6mo ago

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.

BoppreH 6mo ago

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.

mlhpdx 6mo ago
Perhaps an aside, but the things we do to compensate for the warts of TCP are staggering.
- lelanthran 6mo ago
  This isn't a TCP problem, though. It's a fetch API problem. Even if fetch ran over UDP, or a direct serial connection, or IP over Avian carrier, it'd still be a poor API that doesn't allow progress indication.

hulitu 6mo ago

> 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.

reaperducer 6mo ago

As a result the loading indicator can only indicate in-progress or done. This is a failure of whatever framework the web dev is leaning on instead of actually programming the computer. It is perfectly possible to get real progress information other than yes/no. Web sites had it for years before lazy spinners took over.

lelanthran 6mo ago
>> 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. > This is a failure of whatever framework the web dev is leaning on instead of actually programming the computer. No, it's a failure of fetch.