LoaderShip – CSS-Only Loaders • Hacker News Board

Re: LoaderShip – CSS-Only Loaders

#21

Post by kevincox » Fri, Jan 19, 2024, 11:40 AM UTC

mcny wrote: post #4

TekMol wrote: post #3

I wish loaders would provide some feedback on what is going on. So often, I look at a loader and think "How long will it take? Is it actually still doing something? Or should I try to reload the page?". Also, I often wonder why developers put tools like this on an extra domain instead of just putting it on a page or subdomain on their personal domain. Is there a reason for this that I am missing?

1. It gets worse. Often in aspdotnet we have programmers who will only remove loader on success so you could get a 500 internal server error response and the loader never goes away. 2. I think it makes it easier to get to your website without having to use search and it is easy to share like are we web yet dot org

Yeah, lack of error notification in general is a huge problem with many UIs.

It is worse than the other common problem of showing "no results" until the actual results load in.

Re: LoaderShip – CSS-Only Loaders

#22

Post by 9dev » Fri, Jan 19, 2024, 12:00 PM UTC

elaus wrote: post #20

Not specific to the submission, but I've basically lost all trust in loading spinners. Too many websites keep showing the loading animation indefinitely if anything unexpected fails (invalid response from backend, broken connection, …). It's not even a problem with the concept itself (binary is/isn't loading), it's just bad implementations that have ruined it for me subconsciously.

And it’s so easy:

    loading = true
    try { 
      await fetch(…)
    } finally {
      loading = false
    }

…while the error bubbles up to some global handler. This is such a low hanging fruit for the user experience…

Re: LoaderShip – CSS-Only Loaders

#23

Post by JimDabell » Fri, Jan 19, 2024, 12:03 PM UTC

This just ends up putting a stack of empty divs into your page. Use SVG instead of trying to abuse HTML to draw things. SVG is literally designed for this, you should use the right tool for the job.

Re: LoaderShip – CSS-Only Loaders

#24

Post by unkoman » Fri, Jan 19, 2024, 12:11 PM UTC

I would love to see old load-bars instead as well.

Re: LoaderShip – CSS-Only Loaders

#25

Post by teh_klev » Fri, Jan 19, 2024, 12:18 PM UTC

mcny wrote: post #4

TekMol wrote: post #3

I wish loaders would provide some feedback on what is going on. So often, I look at a loader and think "How long will it take? Is it actually still doing something? Or should I try to reload the page?". Also, I often wonder why developers put tools like this on an extra domain instead of just putting it on a page or subdomain on their personal domain. Is there a reason for this that I am missing?

1. It gets worse. Often in aspdotnet we have programmers who will only remove loader on success so you could get a 500 internal server error response and the loader never goes away. 2. I think it makes it easier to get to your website without having to use search and it is easy to share like are we web yet dot org

> Often in aspdotnet we have programmers

Pretty sure this is a problem across many other development platforms. Odd that you singled out aspdotnet programmers.

Re: LoaderShip – CSS-Only Loaders

#26

Post by rgmerk » Fri, Jan 19, 2024, 12:38 PM UTC

Heh. I saw “loader” and was expecting a reimplementation of the Ocean Loader:

https://youtu.be/njTxV8blffc?si=HxTbACcLCZYDmvig

Re: LoaderShip – CSS-Only Loaders

#27

Post by JoeyJoJoJr » Fri, Jan 19, 2024, 1:29 PM UTC

9dev wrote: post #22

elaus wrote: post #20

Not specific to the submission, but I've basically lost all trust in loading spinners. Too many websites keep showing the loading animation indefinitely if anything unexpected fails (invalid response from backend, broken connection, …). It's not even a problem with the concept itself (binary is/isn't loading), it's just bad implementations that have ruined it for me subconsciously.

And it’s so easy: loading = true try { await fetch(…) } finally { loading = false } …while the error bubbles up to some global handler. This is such a low hanging fruit for the user experience…

To be fair, it usually starts out that easy, until you require multiple fetch requests and conditional logic for separate CRUD operations.

Re: LoaderShip – CSS-Only Loaders

#28

Post by arnorhs » Fri, Jan 19, 2024, 1:34 PM UTC

Agree with some of the other commentors that I don't associate "loader" with progress indicators / spinners. The preferred term for these in my book is "loading indicator"

A lot of these terms are overloaded already. Android made it esp. bad by using "spinner" for a dropdown box, and then they used progress indicator for things that normally you'd use "spinner" for.

Ultimately a "spinner" isn't really a good term since not all loading indicators spin.

I might remember seeing the term "loader" in the jQuery days, but I haven't seen it used that way for a while.

Re: LoaderShip – CSS-Only Loaders

#29

Post by internetter » Fri, Jan 19, 2024, 1:37 PM UTC

JoeyJoJoJr wrote: post #27

9dev wrote: post #22

Earlier quoted context omitted.

And it’s so easy: loading = true try { await fetch(…) } finally { loading = false } …while the error bubbles up to some global handler. This is such a low hanging fruit for the user experience…

To be fair, it usually starts out that easy, until you require multiple fetch requests and conditional logic for separate CRUD operations.

I've worked in codebases where this bubbling is trivial, and ones where its impossible. The key is abstractions.

Re: LoaderShip – CSS-Only Loaders

#30

Post by internetter » Fri, Jan 19, 2024, 1:47 PM UTC

I feel like skeletons are much better than loaders. I never used them until recently (I have had the displeasure of using an API that takes 700ms+ per request for critical pathways) and the change was jarring until I used skeletons, now it feels 2x faster!