Comment by JoshMnem
7 years ago
That is one thing I dislike about sites that show no loading bar. On a slow connection it's impossible to tell if the page is still loading or already failed.
It's also one of the irritating things about "Material Design" websites, where responses to clicks are artificially delayed before speeding out with unnatural acceleration. "Nothing is happening. JUST KIDDING!" I'm not sure if that is to mask the slowness of mobile devices or if it's the cause of them. It's the animation spam[1] of the current generation of UIs.
* [1] "Let's make our website sparkle. It will be 'delightful'." http://dynamicdrive.com/dynamicindex3/snow.htm
That is one thing I dislike about sites that show no loading bar. On a slow connection it's impossible to tell if the page is still loading or already failed.
Web browsers have progress bars.
I think your complaint is with "sites" that just serve a JS payload and then load "the real site" entirely from requests made by JS. Turns out if you generate and serve actual HTML, you get a progress bar for free!
I don't know why every thread about Web applications needs someone to tell me that technically HTML was just designed to be a document format. OK, great, now it isn't just that.
First someone states that the way web sites work now sucks. Then the next person states, ‘Well we used to build sites this way and then it doesn’t suck’. And then the next person comes in saying ‘well that just isn’t the way we build sites now’.
If that isn’t the way we build sites now, either change the way we build sites or accept that it sucks. But this is Hacker News so we’re supposed to think about different ways to build sites than what we do now.
2 replies →
He did not say that. Generating the HTML for the initial page load server-side does not make HTML "just a document format". It improves loading and search-friendliness of your web site.
That’s true, but I can mention several online stores that do this. Even on a good network the site remains blank for seconds at times. If they at least served me a logo I’d know the site wasn’t dead!
1 reply →
I solved this in a react app I’m working on by overriding XMLHttpRequest.prototype.open to listen for the request lifecycle events and update a global “percent loaded” used to render a progress bar at the top of the page.
It’s far from perfect but is at least a good enough heuristic for the user to know when the page is loading a request.
Try to load an AMP page with JavaScript turned off. It can take many seconds, and there is no loading indicator.
JS lets you easily implement bars that do reflect progress.
Turn on the animation => start an async action (e.g. a database call) => end the animation. An error occured? Show the error. Here, simple and informative to the user - and much better than raw html.
> That is one thing I dislike about sites that show no loading bar. On a slow connection it's impossible to tell if the page is still loading or already failed.
To be fair, depending on how the progress bar is implemented, it might not be a guarantee.
Clicks have a 200ms (IIRC) delay on Android to give a chance to recognize other gestures. There are hacks to get ride of it, though. It may have to do with that.
It's on desktop websites too, like YouTube (add to watchlist), and the delays are longer than 200 ms.