HackerBooks and Bun: the books Hacker News recommends

Every good Hacker News discussion has someone saying "read Designing Data-Intensive Applications", and you save the tab to never open it again. HackerBooks appeared in a Show HN to fix that. The pitch fits in the post title: it's HackerTube, but for books mentioned on HN.

A warning before we go on. This text is based on the announcement, not on how HackerBooks is built, so I won't guess its stack or numbers. The code here is my own sketch with Bun, and I haven't run it against the real API yet. Treat it as a starting point.

What is HackerBooks?

It's a book discovery layer built on what the HN community cites. The idea is the same as HackerTube, which appeared on Andrej Karpathy's blog: take the decision away from a commercial algorithm and hand it to people who discuss the subject.

This pattern is turning into a genre. First videos, now books. And honestly, books seem like an even better fit.

You can test a video in five minutes. A technical book costs weeks of reading. The more expensive the mistake, the more a good filter is worth.

Why a book recommendation on HN beats a top 10

"10 books every dev should read" lists tend to recycle the same titles. Many of them live off affiliate links. Store ratings have another problem: they measure who bought the book and liked it, not always who used it at work.

A mention in a comment has context. People rarely cite a book out of nowhere. Someone is working through a question about replication, compilers or managing a team, and the book comes up as the answer.

That context is the real value. Knowing a book was cited 300 times helps. Reading why someone recommended it for a problem like yours helps a lot more.

A book cited in a real discussion comes with directions for use.

But HN is still HN:

• The bias is strong: English, startups, systems and nostalgia.
• Citing doesn't prove reading. Some classics are cited more than they are read, and SICP knows it.
• Some mentions are criticism. A count doesn't separate praise from complaint.

Why books are harder to extract than videos

This is the fun technical part. A YouTube video has an ID in the URL. You extract that ID and you're done.

Books don't have that. The same work shows up as an Amazon link, a Goodreads link, "DDIA", "the Kleppmann book" or "that book with the pig on the cover". Humans get it. Regex, not so much.

The identifiers are misleading too. The print edition usually has one ISBN, the new edition has another, and the Kindle version gets an ASIN starting with B. One book, three IDs. If you don't merge them, your ranking splits the votes for the same title.

There's one more detail. HN stories have public points, but comment scores aren't exposed. So you can't tell if a recommendation was applauded or buried. You need another signal.

I'd use distinct people. One person citing the same book 40 times is a fan. Forty people citing it once is a much better signal.

How to build your own version with Bun

I'll take the lazy route: grab only the Amazon links with an ISBN and ignore the rest. You lose the plain text mentions, but you get clean data in an afternoon.

Bun fits well because it runs TypeScript directly and already ships with fetch and SQLite. No npm install, no configuration.

// collect.ts
import { Database } from "bun:sqlite";

const db = new Database("books.sqlite");
db.run(`CREATE TABLE IF NOT EXISTS mention (
  isbn TEXT, author TEXT, comment TEXT, created_at INTEGER,
  PRIMARY KEY (isbn, comment)
)`);

const url = new URL("https://hn.algolia.com/api/v1/search");
url.searchParams.set("query", "amazon.com");
url.searchParams.set("tags", "comment");
url.searchParams.set("hitsPerPage", "1000");

const res = await fetch(url);
if (!res.ok) throw new Error(`Algolia returned ${res.status}`);
const { hits } = await res.json();

const pattern = /amazon\.[a-z.]+\/(?:[^\s"<]*\/)?(?:dp|gp\/product)\/(\d{9}[\dX])/g;
const save = db.prepare("INSERT OR IGNORE INTO mention VALUES (?, ?, ?, ?)");

for (const h of hits) {
  const text = (h.comment_text ?? "").replaceAll("&#x2F;", "/");
  for (const [, isbn] of text.matchAll(pattern)) {
    save.run(isbn, h.author, h.objectID, h.created_at_i);
  }
}

Run it with bun collect.ts. The composite primary key lets you run it again without duplicating anything, which pairs well with a cron job.

Notice the replaceAll. Comment text can arrive with the slash encoded as /, and then the regex doesn't match. The \d{9}[\dX] pattern drops Kindle ASINs on purpose, because they aren't ISBNs.

The ranking becomes a query:

// ranking.ts
import { Database } from "bun:sqlite";

const db = new Database("books.sqlite");

const top = db.query(`
  SELECT isbn, COUNT(DISTINCT author) AS people, COUNT(*) AS mentions
  FROM mention
  GROUP BY isbn
  ORDER BY people DESC
  LIMIT 20
`).all() as { isbn: string; people: number; mentions: number }[];

for (const book of top) {
  const res = await fetch(`https://openlibrary.org/isbn/${book.isbn}.json`);
  const title = res.ok ? (await res.json()).title : "unknown title";
  console.log(`${book.people} people: ${title} (${book.isbn})`);
}

Open Library resolves the title without an API key. It doesn't know every ISBN, hence the fallback.

Pitfalls before you trust the ranking

Three things will show up right away:

• Pagination: the search doesn't return the whole history at once. Slice it by period using created_at_i in numericFilters.
• False positives: not every Amazon link is a book. The ISBN filters out a good part of them, but the amazon.com query also brings in plenty of comments about the company itself, and those just burn your results window.
• Split editions: grouping by ISBN still breaks up classics with several editions. You can use the work identifier (works) that Open Library returns and group by that.

To catch mentions without a link, the way out is to run an LLM over the comments and ask for title and author in JSON. It works, but it costs money and it can invent books. I'd only go down that road after seeing the simple data produce results.

One ethical note: if you publish the list, make it clear when there are affiliate links. A project born from distrust of sponsored lists shouldn't turn into one.

What changes in your workflow

You won't read more books because of this. Sorry. The pile on the desk is still there, judging me.

The gain is something else: choosing the next one better. Before buying, open the discussions where the book came up. Look for people who disagree. See which problem it was recommended for. Ten minutes there can save you a month of the wrong reading.

The pattern works for your team too. Swap HN comments for your Slack history and you'll find out which books and articles people really recommend. It's a much more honest onboarding than a wiki untouched since 2023.

Is HackerBooks worth using?

Yes, as a compass, not as a canon. My strong opinion: the most useful part of a project like this is the link to the original conversation, not the position in the ranking. A number tells you many people cited it. Only the comment tells you if it fits your problem.

And the genre deserves to keep going. Videos, books, then papers, tools, courses. What we need here are good queries over public discussions, and that fits in a script. If you like small tools like this, there are more in my projects.

"Read Designing Data-Intensive Applications." Almost every good Hacker News thread has that line, and the saved tab never gets opened again.

HackerBooks showed up to fix this: find books by what the community actually cites, not by an affiliate list.

A bad video costs you five minutes. The wrong technical book costs you weeks. The more expensive the mistake, the more a good filter is worth.

To me, the best part of a project like this isn't the ranking. It's the link to the original conversation. A number tells you many people cited it. Only the comment tells you if it fits your problem.

In the article, I sketched how to build your own version with Bun and SQLite in an afternoon, counting distinct people instead of mentions. One person citing a book 40 times is a fan. Forty people citing it once is a signal.

Which technical book did you read because of a comment and never forget?

#HackerNews #Bun #TypeScript #SoftwareDevelopment #Books