Hacker News new | past | comments | ask | show | jobs | submit login

My thought exactly. If your site is taking so long to load that you feel the need for a progress bar, it's time to trim the fat.

Youtube videos already have their own bar, why is the rest of the page so bloated that it needs bar? All the thumbnails? Maybe it's time to stop loading so many by default. Too many widgets for comments, ratings, favorites, etc.? Again, time to cut down on all the widgets.




I don't think so. As more sites move away from full page refreshes toward just changing the DOM (using Angular, Backbone, Turbolinks, etc.), I think we're going to see way more of these.

The problem is that you can never rely on a load being fast. If you trim the fat on the app side and get a pageload down to 100ms, it might load almost-instantly for you on a 100Mbit/s connection.

But it still won't for someone on a 768Kbit/s DSL connection. In that case, you can't just let them sit there for a second or two with no feedback. A loading indicator is necessary for those instances.

I agree that sites should trim the fat and make pages load as quickly as possible so that a loading bar isn't really necessary. But you have a) instances where you're not in control of load times, like when you're relying on an external API (like Facebook, for example) to return data, and b) even if your app is blazing fast, you're still subject to slow connections that necessitate a loading bar.


I think in cases where you are loading significant external data that may take several seconds a loading bar is appropriate; see for example the loading bar on a Youtube video. Perfectly legitimate. Or a loading indicator on a gallery of thumbnails. Appropriate uses.

But the page itself should not necessitate a page wide loading bar. That's a design flaw. Your page is bloated. Even a 768Kbit DSL should be able to load the page itself rapidly. If you're beyond that just for the basic page itself then you've failed in your job as a designer/developer, IMHO.

And I've designed web apps that never actually send you to a different page (just update the DOM), and in my experience they are extremely fast. Even making many API calls retrieving tons of records to a very modest server. That design is not in and of itself a reason to have load bars.


Agreed. The whole point of a client-side update mechanism is to do something better than a loading bar. And that thing should be (1) immediate and (2) particular to what the user did.


Medium really needs to trim the fat. I was scraping[0] and I noticed they send their content twice! Once in HTML and once as a Javascript object.

(0) http://mediumsearch.herokuapp.com




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: