HackerBooks y Bun: los libros que recomienda Hacker News

Toda buena discusión en Hacker News tiene a alguien diciendo "lee Designing Data-Intensive Applications", y tú guardas la pestaña para no abrirla nunca más. HackerBooks apareció en un Show HN para resolver eso. La propuesta cabe en el título del post: es HackerTube, pero para libros mencionados en HN.

Un aviso antes de seguir. Este texto parte del anuncio, no de la implementación de HackerBooks, así que no voy a inventar stack ni números del proyecto. El código de aquí es un esbozo mío con Bun, todavía sin probar contra la API real. Tómalo como punto de partida.

¿Qué es HackerBooks?

Es una capa de descubrimiento de libros construida sobre lo que cita la comunidad de HN. La idea es la misma de HackerTube, que apareció en el blog de Andrej Karpathy: quitarle la decisión a un algoritmo comercial y dársela a gente que discute el tema.

Este patrón se está volviendo un género. Primero videos, ahora libros. Y, sinceramente, el libro me parece un caso incluso mejor.

Un video lo pruebas en cinco minutos. Un libro técnico cuesta semanas de lectura. Cuanto más caro el error, más vale un buen filtro.

Por qué una recomendación de libro en HN vale más que un top 10

Las listas de "10 libros que todo dev debe leer" suelen reciclar los mismos títulos. Muchas viven de enlaces de afiliado. Las reseñas de tienda tienen otro problema: miden a quien compró y le gustó, no siempre a quien lo usó en el trabajo.

Una mención en un comentario tiene contexto. Casi nadie cita un libro en el vacío. La persona está resolviendo una duda sobre replicación, compiladores o gestión de equipos, y el libro entra como respuesta.

Ese contexto es el verdadero valor. Saber que un libro se citó 300 veces ayuda. Leer por qué alguien lo recomendó para un problema parecido al tuyo ayuda mucho más.

Un libro citado en una discusión real viene con prospecto.

Pero HN sigue siendo HN:

• El sesgo es fuerte: inglés, startups, sistemas y nostalgia.
• Citar no prueba haber leído. Hay clásicos más citados que leídos, y SICP lo sabe bien.
• Parte de las menciones son críticas. El conteo no separa elogio de queja.

Por qué un libro es más difícil de extraer que un video

Aquí está la parte técnica divertida. Un video de YouTube tiene un ID en la URL. Extraes ese ID y listo.

Un libro no tiene eso. La misma obra aparece como enlace de Amazon, enlace de Goodreads, "DDIA", "el libro de Kleppmann" o "aquel libro del cerdo en la portada". Un humano lo entiende. Una regex, no tanto.

Y los identificadores también engañan. La edición impresa suele tener un ISBN, la nueva edición tiene otro y la versión Kindle recibe un ASIN que empieza con B. Un libro, tres IDs. Si no juntas todo, tu ranking reparte los votos del mismo título.

Hay un detalle más. Las stories de HN tienen puntos públicos, pero la puntuación de los comentarios no se expone. Por eso no sabes si esa recomendación fue aplaudida o enterrada. Necesitas otra señal.

Yo usaría personas distintas. Una persona que cita el mismo libro 40 veces es un fan. Cuarenta personas que lo citan una vez son un indicio mucho mejor.

Cómo montar tu versión con Bun

Voy a seguir el camino perezoso: tomar solo los enlaces de Amazon con ISBN e ignorar el resto. Pierdes las menciones en texto plano, pero ganas un dato limpio en una tarde.

Bun encaja bien porque ejecuta TypeScript directo y ya trae fetch y SQLite. Sin npm install, sin configuración.

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

const db = new Database("libros.sqlite");
db.run(`CREATE TABLE IF NOT EXISTS mencion (
  isbn TEXT, autor TEXT, comentario TEXT, creado_en INTEGER,
  PRIMARY KEY (isbn, comentario)
)`);

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 respondió ${res.status}`);
const { hits } = await res.json();

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

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

Ejecútalo con bun recolecta.ts. La clave primaria compuesta permite correrlo de nuevo sin duplicar nada, lo que combina con un cron.

Fíjate en el replaceAll. El texto del comentario puede venir con la barra codificada como /, y entonces la regex no coincide. Y el patrón \d{9}[\dX] descarta a propósito los ASIN de Kindle, porque no son ISBN.

El ranking se vuelve una consulta:

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

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

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

for (const libro of top) {
  const res = await fetch(`https://openlibrary.org/isbn/${libro.isbn}.json`);
  const titulo = res.ok ? (await res.json()).title : "título desconocido";
  console.log(`${libro.personas} personas: ${titulo} (${libro.isbn})`);
}

Open Library resuelve el título sin clave de API. No conoce todos los ISBN, por eso el fallback.

Trampas antes de confiar en el ranking

Tres cosas van a aparecer pronto:

• Paginación: la búsqueda no entrega todo el historial de una vez. Divide por período usando created_at_i en numericFilters.
• Falsos positivos: no todo enlace de Amazon es un libro. El ISBN filtra buena parte, pero la query amazon.com también trae muchos comentarios sobre la propia empresa, y esos solo gastan tu ventana de resultados.
• Ediciones separadas: agrupar por ISBN todavía parte a los clásicos con varias ediciones. Puedes usar el identificador de obra (works) que devuelve Open Library y agrupar por él.

Para capturar las menciones sin enlace, la salida es pasar un LLM por los comentarios y pedir título y autor en JSON. Funciona, pero cuesta dinero y puede inventar libros. Yo solo iría por ese camino después de ver que el dato simple da resultado.

Un cuidado ético: si publicas la lista, deja claro cuándo hay enlaces de afiliado. Un proyecto que nace de la desconfianza hacia las listas patrocinadas no debería volverse una de ellas.

Qué cambia en tu flujo de trabajo

No vas a leer más libros por esto. Lo siento. La pila sobre la mesa sigue ahí, juzgándome.

La ganancia es otra: decidir mejor el siguiente. Antes de comprar, abre las discusiones donde apareció el libro. Busca a quien no está de acuerdo. Mira para qué problema lo recomendaron. Diez minutos ahí pueden ahorrarte un mes de lectura equivocada.

El patrón también sirve para tu equipo. Cambia los comentarios de HN por el historial de Slack y descubres qué libros y artículos recomienda de verdad la gente. Es un onboarding mucho más honesto que una wiki parada desde 2023.

¿Vale la pena usar HackerBooks?

Vale como brújula, no como canon. Mi opinión firme: la parte más útil de un proyecto así es el enlace a la conversación original, no la posición en el ranking. Un número dice que mucha gente lo citó. Solo el comentario dice si te sirve a ti.

Y el género merece seguir. Video, libro, después paper, herramienta, curso. Lo que necesitamos aquí son buenas consultas sobre discusiones públicas, y eso cabe en un script. Si te gustan las herramientas pequeñas así, hay más en mis proyectos.

"Lee Designing Data-Intensive Applications." Casi todo buen hilo de Hacker News tiene esa frase, y la pestaña guardada no se vuelve a abrir.

HackerBooks nació para resolver eso: descubrir libros por lo que la comunidad cita de verdad, no por una lista de afiliados.

Un mal video cuesta cinco minutos. Un libro técnico equivocado cuesta semanas. Cuanto más caro el error, más vale un buen filtro.

Para mí, lo mejor de un proyecto así no es el ranking, es el enlace a la conversación original. Un número dice que mucha gente lo citó. Solo el comentario dice si te sirve a ti.

En el artículo esbocé cómo montar tu versión con Bun y SQLite en una tarde, contando personas distintas en lugar de menciones. Una persona que lo cita 40 veces es un fan. Cuarenta personas que lo citan una vez son un indicio.

¿Qué libro técnico leíste por la recomendación de un comentario y nunca olvidaste?

#HackerNews #Bun #TypeScript #DesarrolloDeSoftware #Libros