HN user

ers35

607 karma

Eric R. Schulz (ers35)

https://www.ers35.com/

Posts7
Comments86
View on HN

I've been focusing on reading, but it looks like there is interest in writing too. The HN API doesn't support writing, so the username and password has to be stored. It's important that reading keeps working even if HN changes their backend in a way that breaks writing. I'll think about it.

HN itself is fast, but the comparison I'm making is with readers that use the HN API. See how getting each comment requires an additional API request: https://hacker-news.firebaseio.com/v0/item/22481199.json?pri...

It's more about the consistency of operating on data local to the user. For example, see this comment referencing how HN paginates threads at 250 comments for performance reasons: https://news.ycombinator.com/item?id=22231055 A local database does not have that issue.

There have been many HN related websites posted over the years, but a lot end up as dead links. A self-hosted version does not depend on a third party. Another reason is to minimize the round trip latency of contacting a central server. Consider users without a good connection to the server.

I prototyped this in Qt 2 years ago: https://ers35.com/files/hackernews-qt.png

1) It is possible to keep the whole site offline. A database from 2017 is 9 GB: https://archive.org/details/hackernews-2017-05-18.db I think a 2020 DB could be less than 20 GB.

2) My focus is on reading, not writing. Local favorites make sense. Maybe with importing public favorites. A user can set their name without logging in.

3/4) SQLite does the heavy lifting here.