Hacker News Reader

Comment by tjarratt | Hacker News Reader

Actually I don't think that's necessary - I'd much rather they focus on making individual loads very fast, instead of pre-loading data. 9 times of out 10, I'm not going to peruse the ENTIRE directory structure even one level deep, so it should only get the data I want.

Also, they would need to store that, and I don't necessarily want my browser storing my entire directory structure (and possibly file contents) for any amount of time other than when I'm actually browsing it.

Try it out, it really is very fast without having to eagerly load anything at all.

View on HN

They could build a page-transition graph: for each page, what are the links that people are most likely to click? This could let them figure out what the top one or two most common next-pages are, and those could be pre-loaded.

That would be more work for the GitHub guys, but I'm pretty sure it would work.

Good idea, but _lots_ of work to implement it the right way.

Not to mention that the vast majority of Github repositories don't have enough traffic to properly build such a graph.

A reasonable fallback would be to look at the proportion of commits that touch files under each directory - the more active a directory is, the more likely it is to be of interest. Still probably not worth it in the majority of cases though.

I like that idea quite a bit, actually- I'm envisioning a sort of "heat map" UI, where each entry in a directory listing's background color is determined by its commit frequency.

The individual load still takes a full HTTP round trip, which is going to be slow no matter how you slice it. Comparatively, storing several layers of a directory structure (all you need is file/directory names in a JSON tree) is pretty tiny.

Have you actually tried the feature? (I'm honestly curious). Sounds like you're throwing around a lot of what-ifs for a problem that doesn't exist.

Yes, I've used the feature--I spend a lot of time every day using Github. At my office, where I have a fast connection, it works very well and I like it. At home, where I have a shitty connection, it's hardly faster than the old method.

I'm just pointing out that since they've changed the arrangement (e.g. no page reload when navigating between directories), they could take advantage of it to get a huge performance gain rather than a small performance gain.

Reply on news.ycombinator.com