Hacker News Reader

Comment by JoshMnem | Hacker News Reader

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

View on HN

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.

It's just... what's the point of talking to anyone who will listen about how HTML was designed for hypertext? Yes, we all know that. Today the world's most-popular Web sites include YouTube and Facebook. We aren't going back.

This a (mostly) solved problem. With Server Side Rendering the html payload delivers what the client side is would have rendered. The client side js takes over rendering after it loads.

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!

> I can mention several online stores that do this

I would like to hear which ones they are, that I may try them.

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.

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

Reply on news.ycombinator.com