Hacker News Reader

Comment by jedberg | Hacker News Reader

Great! Now if only they would implement allowing HEAD requests and support for any of the various headers that would allow me to get a 304.

The reason I ask is because every time my Safari crashes, if I have 50 HN tabs open (as I often do on by Friday [1]) I'll get IP banned from HN because Safari will do a GET request on each page, but it can't pass any of the headers necessary to get back a 304, because HN doesn't support it.

[1] The way I consume HN is I load up HN once or twice a day, open up all the interesting links and their comment pages in new tabs, and then go back to work. Then when I have some downtime (most of which is on the weekend) I read through all the open tabs.

View on HN

> The way I consume HN is I load up HN once or twice a day, open up all the interesting links and their comment pages in new tabs, and then go back to work.

By that time most pages are probably updated, so you wouldn’t get any 304s anyway.

Since recent update, Firefox behavior is to only reload restored tabs on demand. This avoids that issue.

https://blog.mozilla.org/blog/2012/06/05/firefox-has-a-redes...

The behaviour has been built in and accessible since Firefox 4 (initially through about:config, later through the Preferences), but has only been enabled by default later on. I've personally been using it since it appeared, and it's great if you literally have hundreds of tabs open, or use tabs as temporary bookmarks.

For pinned/app tabs, it can be enabled by setting browser.sessionstore.restore_pinned_tabs_on_demand preference to true in about:config.

> By that time most pages are probably updated, so you wouldn’t get any 304s anyway.

Actually, quite the opposite. HN comment pages seem to peter out at about 12 hours in most cases, and after that you'll rarely see a new comment, so really the content stops changing after about a day.

That behavior shouldn't get you banned, but some of your requests will get dropped if you make too many too quickly.

You will see 304s for static resources, like images and CSS. Efficiently handling HEAD requests for dynamically generated pages is actually painful, and many frameworks support it by handling the request like a GET and just omitting the body. In our case, most pages contain fnids and will never be the same twice anyway.

It can get you banned and here is the fix:

https://news.ycombinator.com/item?id=4761102

Well, it drops every request I make for about 12 hours, so that's equivalent to a ban. :)

And I'm aware of how painful it is to handle HEAD requests for a dynamic page, having had to deal with it on reddit. There are some easy hacks to make it work pretty well. One is to just keep a cache of the last update time of each page, and then use that cache when you get a HEAD request.

I'm not sure what an fnid is, but if you have something on the page that changes so quickly that the hash changes when the content doesn't, then I'd contend you're doing something wrong.

PG and friends are using Continuations ( http://en.wikipedia.org/wiki/Continuation ), which are supported first-class in Racket, as the pattern underlying HN.

Their specific implementation of continuations means that each time a page is generated, each user-specific/authenticated link off of the page (Flag, Voting, Delete) is evaluated as a possible continuation of the user's state and the user-and-action specific hash "fnid" (Function ID) is cached and interpolated into the HTML.

Hence, the hash absolutely changes for every logged-in user every page load.

Lots of older sites still use continuations to great effect; Continuations were popular in the WebObjects days but since they require lots of user state information to be stored server-side they're comparatively difficult to scale.

Continuations are a really cool pattern to study, since most hacking in HTTP-backed web services comes from the inherently stateless nature of the protocol, and continuation-based programming helps prevent the inverted control flow that page-based programming lends itself to.

Actually, it does get one banned. It happened to me once and it was the most nerve wracking experience trying to figure out what exactly happened and why i was separated from my favorite site.

I came up with the following simple :-) hack: When there is a need to open a bunch of HN links (either saved tab sessions or more importantly when restoring a crashed browser session), I disconnect the network connection. Once all the tabs are launched, I turn the network connection back on and refresh each tab when i get around to reading it.

Isn't that how everyone uses HN?

Maybe. In which case, all the more reason to do it!

It seems much more sane, even when my machines have 8GB+ of RAM to simply have a "read later" bookmark folder on your bookmark bar^. I have my bookmark bar shown with single icon hot shortcuts, a blank folder with all my bookmarks and a simply "revisit" folder with articles, youtube videos, whatever to read during downtime. (I guess quite simply I don't trust my browser or session recovery enough to do that).

Plus, Chrome Sync means I get those free on my mobile too. Nice for when I'm stuck a waiting room or something.

Also, isn't there a whole class of "read it later" type services? Seems a bit much overhead for me.

^ tip, you can drag the padlock/favicon next to the URL right onto/into your "revisit" bookmark folder too, in case you didn't know

Chrome Sync also gives you all the open tabs from another browser (which is one of many reasons I love Chrome for iOS)

I use those "Read Later" services, but I only put something in one once I've read the first paragraph and am sure it's actually something I want to read. Preceding that, I open everything in a bunch of tabs, in the same way you'd put a pile of resumes in an inbox. If my browser crashes, I ideally want them discarded, not saved.

An alternate mechanism for the same thing would be to make an HN extension that works more like StumbleUpon: have the browser history function as the "tabs", and just advance through the things you're reviewing (seeing both the HN thread and the original article at once) by clicking either "Save" or "Discard".

This is why tldr.io is useful. I can get my HN lazy-tabs down to 40 per visit.

Too bad that is chrome only at the moment and the commenter is using safari.

And for the too lazy to copy paste: http://tldr.io

No. I come here because it's an entertaining distraction, but there are few articles I feel I have to read. So I normally visit every few hours, open a bunch of interesting articles and comment threads on the homepage, start reading one or two, realise I have better things to do than read said articles, close half of them without looking at them, and read/skim the one or two that remain, if they look especially interesting. I also often use the "mark all as read" feature in my RSS reader to get rid of a backlog of articles.

Similar experience here. I use Chrome and made this extension yesterday: https://chrome.google.com/webstore/detail/comments-on-hn/ehj...

With this extension, I can open all of the article tabs (skip the comment threads), and jump to the comment thread when needed. It's very much WIP.

You said Safari, but if there's any Chrome users with the same problem (I know I had), I recommend the OneTab extension.

Is your job so stressful that you don't have time to read HN at all during normal workdays?

Reply on news.ycombinator.com