Show HN: Kage – Sombra cualquier sitio web en un único binario para verlo sin conexión

Artículo original ↗ Discusión en Hacker News ↗

Una nueva herramienta llamada Kage busca “sombrear” sitios web completos en archivos sin conexión, produciendo carpetas HTML estáticas, archivos ZIM para Kiwix o binarios autocontenidos que agrupan un rastreo impulsado por Chrome y un visor ligero. Los comentaristas la comparan con utilidades antiguas como HTTrack, el espejado con wget y “Guardar como” del navegador, así como con SingleFile y flujos de trabajo basados en WARC/ZIM, centrándose en qué tan bien maneja sitios con mucho JavaScript, la recursión, la compresión y la legibilidad a largo plazo. Hay gran interés por casos de uso como wikis, documentación técnica y vuelos sin conectividad, junto con preocupaciones sobre la carga del servidor, las banderas de seguridad, la distribución basada en binarios y el README generado por IA del proyecto.

Propósito e idea central

  • La herramienta refleja sitios web completos (no solo páginas individuales) en paquetes aptos para uso sin conexión.
  • Captura el DOM renderizado después de la ejecución de JS, elimina los scripts y reescribe los recursos para que las instantáneas funcionen sin acceso a la red.

Comparaciones con herramientas existentes

  • Se la ve como una alternativa moderna a HTTrack/wget para sitios con mucho JS (p. ej., SPA, Next.js).
  • Se compara con frecuencia con SingleFile/SingleFileZ y archiveweb.page:
    • Se elogia SingleFile por sus guardados de una sola página de alta fidelidad y su empaquetado en base64.
    • SingleFile ya admite rastreos recursivos acotados; algunos sugieren tomar prestadas sus técnicas para funciones complejas (shadow DOMs, iframes, websockets, deduplicación).
  • También se menciona junto con grab-site, browsertrix, Kiwix/ZIM, gwtar, mhtml, Teleport Pro, curl y “Print to PDF”.

Formatos de salida y distribución

  • Actualmente genera:
    • Carpeta HTML estática.
    • Archivos ZIM (para lectores Kiwix en múltiples plataformas).
    • Ejecutables autocontenidos que integran una webview y el archivo.
  • Sugerencias:
    • Un único HTML autocontenido con enrutamiento del lado del cliente.
    • Un archivo autoextraíble que se abra en el navegador del usuario (tipo CHM).
    • Carpeta Markdown para usar con herramientas como Obsidian/Logseq; exportación a EPUB.

Casos de uso

  • Lectura sin conexión de blogs, documentación, wikis de empresa, Confluence y documentación de desarrollo (p. ej., documentación de Apple, Snowflake).
  • Escenarios de viaje/sin conexión (vuelos, trenes, sitios sin conectividad).
  • Archivos personales de largo plazo y acceso para investigación.

Comportamiento técnico y limitaciones

  • Usa Chrome/Chromium; se recomienda Docker para una configuración más sencilla.
  • Vacíos/peticiones actuales: limitación de velocidad para reducir la carga del sitio, exclusión de imágenes/vídeos, rastreos parciales, soporte para cookies/autenticación, manejo de muros de pago y vídeos incrustados.
  • Servir mediante un servidor HTTP local evita las peculiaridades de CORS/origen de file://; hay cierto debate sobre cuán restrictivos son los navegadores en este modo.

Preocupaciones de seguridad y confianza

  • Se cuestionó el uso de --no-sandbox con Chrome en Docker; más tarde se restringió a Docker mediante variables de entorno/banderas.
  • Algunos desconfían de almacenar archivos como binarios; prefieren HTML/ZIM para compartir.
  • Se informó de un falso positivo de antivirus para un binario relacionado.
  • A unos pocos lectores les desagrada mucho el estilo del README, al que llaman “LLM slop”, y cuestionan si la calidad del código coincide.

Ecosistema de archivado y preocupaciones a largo plazo

  • Debate sobre WARC frente a capturas con mitmproxy, HTTP/2/WebSockets y posibles nuevos formatos de archivado.
  • Interés en la compatibilidad con formatos establecidos (WARC, ZIM) y preguntas sobre si lo de “guárdalo durante una década” se sostiene con el tiempo (no está claro).