Kage – Ein Tool zum Entfernen von JavaScript von Websites und zur Offline-Archivierung

• Rendert Seiten mit Headless Chrome, erstellt einen Snapshot des finalen DOM, wie ihn ein Mensch sehen würde, entfernt anschließend sämtliches JavaScript und lädt CSS, Bilder und Schriftarten in lokale Pfade herunter, um eine statische Kopie zu erzeugen, die ohne Code funktioniert
• Löst das Problem, dass per „Save As“ gespeicherte Seiten mit der Zeit kaputtgehen und nur noch einen leeren Bildschirm, einen eingefrorenen Spinner oder fehlgeschlagene Verbindungsversuche zu verschwundenen Analytics-Servern zeigen
  • Bietet .html-Dateien, die sich direkt von der Festplatte öffnen lassen – ohne Tracking, Netzwerkaufrufe oder unerwartetes Verhalten
• Verwendet Breadth-First-Crawling, liest robots.txt, nimmt sitemap.xml als Ausgangspunkt und bleibt beim Seed-Host
  • Dank Idempotenz wird dieselbe Seite nur einmal geholt, unabhängig davon, ob sie per http oder https aufgerufen wird oder ob ein Trailing Slash vorhanden ist
  • Speichert bei Ctrl-C den Fortschritt, setzt ihn beim erneuten Start fort, rendert mit --refresh neu und startet mit --force von vorn
• Bietet Flags zur Steuerung von Crawl-Umfang und Verhalten wie --max-pages, --max-depth, --scope-prefix, --subdomains, --scroll und --workers
• Mit kage pack lässt sich die Kopie in eine einzelne Datei packen – wahlweise als ZIM-Archiv oder als eigenständige ausführbare Datei, die selbst als Website fungiert
  • ZIM ist mit dem Kiwix-Ökosystem kompatibel und kann auch in kiwix-serve sowie in den Kiwix-Desktop- und Mobile-Apps angezeigt werden
  • Für das eigenständige Binary muss der Empfänger nichts installieren; mit --base lässt sich zudem ein Viewer für andere Betriebssysteme erzeugen (ca. 13 MiB + Größe der Website)
• Durch deterministisches Packing erzeugt dieselbe Kopie immer byte-identische Dateien; die Archiv-UUID wird aus dem Inhalt abgeleitet und ist sicher für Checksummen und Caches
• Beim Build mit dem Tag webview wird das OS-WebView (WKWebView, WebView2, WebKitGTK) verwendet, sodass die Seite in einem eigenen Fenster statt in einem Browser-Tab geöffnet wird
• Verarbeitungspipeline: Seed-URL → Rendering mit Headless Chrome → finaler DOM-Snapshot → JS entfernen → Assets lokalisieren → auf Festplatte speichern
• MIT-Lizenz

[GN⁺]

Hacker-News-Kommentare

• Ich fand es interessant, wie das Demo-GIF im README erstellt wurde, und habe nachgesehen: https://github.com/tamnd/kage/blob/01e75b87ecc893bbba7943c63...
  Es stellt sich heraus, dass dafür ein anderes Projekt desselben Autors verwendet wird: https://github.com/tamnd/ascii-gif
  Das im Demo verwendete Skript liegt hier: https://github.com/tamnd/kage/blob/01e75b87ecc893bbba7943c63..., und die Ausführung ist ebenfalls als Kommentar beschrieben: ascii-gif render docs/demo/kage.tape -o docs/static/demo.gif
  Sieht aus wie ein meinungsstarker Wrapper um https://github.com/charmbracelet/vhs

  • Habt ihr schon das Evangelium des Terminal-Retters asciinema gehört: https://asciinema.org/
  • Ich habe auch einige persönliche Binärdateien dieser Art in meinem $HOME/bin/. Dinge wie delete-all-npm, clean-rust-cache, download-youtube-playlist und get-markdown; es ist schön, sich die Befehle nicht merken zu müssen
    Manchmal findet ein Coding-Agent sogar selbst heraus, wie solche Tools aufzurufen sind
  • Statt eines GIFs könnte man auch ein animiertes SVG erzeugen, und da es nur aus Text-Keyframes besteht, ist es viel kleiner als ein GIF: https://github.com/vytskalt/pseudoc/blob/main/assets/factori...
  • Nur als Hinweis: Auf anderen Plattformen wie Windows/macOS ist LiceCAP ein großartiges Tool, um den Bildschirm als kleines GIF aufzunehmen. Es stammt vom Autor von Winamp und Reaper DAW: https://www.cockos.com/licecap/
  • VHS eignet sich hervorragend, wenn man die Erstellung von Kommandozeilen-Videos skripten will

• Das könnte nützlich sein, wenn man ein Unternehmens-Wiki auch offline leicht zugänglich machen möchte. Zum Beispiel könnte es auf einem Einsatzort ohne Mobilfunksignal hilfreiche Dokumentation im Wiki geben
  Dass sich eine ganze Website in eine einzelne Binärdatei bündeln lässt, ist cool, aber eine Version ohne separaten Serving-Prozess wäre besonders gut
  Es scheint auch möglich zu sein, das als eine Art einzelne HTML-Einstiegs-Shim mit etwas JavaScript umzusetzen, mit dem sich das archivierte Site-Content durchsuchen lässt, idealerweise in eingebetteter Form

  • Auf Hacker News zu posten war dafür genau der richtige Ort. Ich werde überlegen, die Idee umzusetzen
    Ich habe bereits ein Skript/Programm im Kopf, das HTML in Markdown umwandelt, also könnte man tatsächlich alles als Markdown-Dateiordner auf der Festplatte speichern und dann in ein Git-Repository committen

• Das ist großartig. Ich wollte schon länger den Prototypen von jemandem aus so etwas wie Lovable als Offline-Kopie herunterladen, um Versionierung und Teilen in einem einfacheren Format zu ermöglichen
  Unser Ansatz dazu steht hier: https://productnow.ai/blogs/extracting-html-from-ai-prototyp...
  Ich werde mir das jetzt ansehen und prüfen, ob ich Teile davon austauschen kann. Die Idee eines Offline-Mirrors gefällt mir, und Anwendungsfälle rund um Zusammenarbeit werden dadurch viel einfacher

• Dort steht kage serve $HOME/data/kage/paulgraham.com, aber wenn das Ergebnis statisch ist, verstehe ich nicht, warum ein Server nötig ist. Könnte man es nicht einfach direkt im Browser öffnen?
  Wenn zum Beispiel so etwas wie $ firefox $HOME/data/kage/paulgraham.com möglich wäre, könnte man das Ergebnis auch auf Rechnern ohne installiertes kage nutzen

  • Stattdessen könnte man vermutlich python -m http.server verwenden. Ich habe es noch nicht ausprobiert, aber es sollte funktionieren
    Tatsächlich besteht Kage aus zwei Teilen. Einer ist der Crawler, der nach dem Rendern durch Chrome/Chromium das DOM erfasst, die Seiten crawlt und in sauberes HTML umwandelt; der andere ist die Pack/Serve-Komponente, die das Ergebnis als ZIM-Datei für Kiwix oder als ausführbare Datei paketiert
  • Wenn man Seiten normalerweise auf diese Weise lädt, wird JavaScript blockiert
  • Dann läuft man vermutlich in eine Menge CORS-Probleme

• Ich halte SingleFile [0] für eine deutlich robustere Version davon.
  Es entfernt auch sämtliches JavaScript, bündelt aber alles in einer einzelnen HTML-Datei, die sich leicht weitergeben lässt. Binäre Assets wie Webfonts oder Bilder werden als base64-Strings eingebettet.
  Es bietet auch eine Puppeteer-basierte CLI [1].
  [0]: https://github.com/gildas-lormeau/singlefile
  [1]: https://github.com/gildas-lormeau/single-file-cli

  • Dieses Repository scheint nur eine einzelne Webseite zu speichern.
    Was hier umgesetzt wird, ist das Spiegeln einer ganzen Website einschließlich Unterseiten, sodass man sie auch offline vollständig durchsuchen kann. Zum Beispiel alle Essays auf paulgraham.com.
  • Ich mag SingleFile wirklich sehr. Die Firefox-Erweiterung funktioniert ziemlich gut, wenn es darum geht, Seiten sauber zu speichern.
    Wenn Kage allerdings die Reproduktionsqualität von SingleFile mit einem HTTPTrack-artigen Spidering-Ansatz verbinden kann, wirkt das vielversprechend. Single-Page-Apps sind etwas knifflig zu archivieren, daher bin ich gespannt, wie gut Kage damit umgehen wird.
  • Danke für den Link. Ich werde versuchen, diese Einzel-HTML-Funktion umzusetzen. Das scheint eine sinnvolle Ergänzung zu sein.
  • Worin unterscheidet sich das von File -> Save as in einem beliebigen Webbrowser auf dem Computer?
  • Daran musste ich anfangs auch denken, und ich halte das für eine sehr elegante Lösung. Es ist auch nicht unnötig kompliziert.

• Ich habe versucht, eine HTTP-Seite, also keine HTTPS-Seite, zu klonen, aber bekam navigation failed: net::ERR_NAME_NOT_RESOLVED. Auch wenn ich das Protokoll explizit als http:// angegeben habe, war es dasselbe.

• Wenn ich im Flugzeug etwas aus einem Wiki lesen wollte, habe ich immer httrack(https://www.httrack.com) verwendet, um es herunterzuladen. Perfekt ist es nicht, aber besser als andere Dinge, die ich früher gefunden hatte.
  Das hier werde ich auch ausprobieren, und wenn die Ergebnisse gut sind, würde mich das wirklich freuen.

  • Das weckt Erinnerungen. Vor etwa 20 Jahren war Internet noch teures Einwahl-Internet, also bin ich ins PC-Café gegangen, habe mit HTTrack Websites und Comics heruntergeladen, alles auf einen damals riesig wirkenden 128-MB-USB-Stick kopiert und es dann mit nach Hause genommen, um es offline zu lesen.
  • Nur für Wikis betrachtet: Gibt es einen Grund, Kiwix nicht zu verwenden? Für alles, was keine „offizielle“ Veröffentlichung ist, ist es zwar komplizierter, aber es gibt Services, die ZIM-Dateien erzeugen. Die Desktop-Reader-App war meiner Erfahrung nach ziemlich gut.
    https://wiki.openzim.org/wiki/Build_your_ZIM_file
    EDIT: https://get.kiwix.org/en/solutions/applications/kiwix-reader...
  • https://github.com/archiveteam/grab-site oder browsertrix könnten für manche Leute leichter zu benutzen sein. Das sind Werkzeuge, die verwendet wurden, um viele data.gov-Inhalte zu sichern, bevor sie verschwanden.

• Ich habe über Jahre hinweg ziemlich viele Archive alter Websites gesammelt. Interessant ist, dass hässliche HTML-Dumps nützlicher waren als „perfekte“ Archive.
  Das ist auch einer der Gründe, warum ich RSS im Lauf der Zeit mehr zu schätzen gelernt habe. Zehn Jahre alte Feeds sind heute oft benutzbarer als sorgfältig konservierte, anwendungsartige Websites.

  • Ich arbeite an einem Projekt, das RSS-Feeds erzeugt und archiviert. Es bewahrt die gesamte Historie ab dem Zeitpunkt auf, an dem der Crawler startet.
    Ich will es noch etwas aufräumen und dann bald als Open Source veröffentlichen.

• Das hier scheint eine ziemlich große Last für eine Website erzeugen zu können. Gibt es Einstellungen, um die Klon-Geschwindigkeit zu drosseln oder Bilder/Videos zu vermeiden?
  Ich frage mich auch, ob es eine Möglichkeit gibt, nur Teile einer Website abzurufen.

  • Könntest du dafür ein neues Issue erstellen? Ich kümmere mich später darum. Es ist gerade 1 Uhr nachts in meiner Zeitzone, aber ich freue mich, dass sich überhaupt jemand dafür interessiert.
  • Tu einfach so, als wärst du ein AI-Crawler, dann ist das Problem gelöst.

• Sauberes Projekt, und die Idee gefällt mir.
  Beim schnellen Durchlesen ist mir aufgefallen, dass Chrome mit --no-sandbox gestartet wird — gibt es dafür einen besonderen Grund? Aus Sicherheitssicht ist das wahrscheinlich keine gute Idee. Falls es keinen guten Grund gibt, würde ich empfehlen, die Sandbox aktiviert zu lassen.
  Jedenfalls tolle Arbeit.

  • --no-sandbox wird in Docker benötigt. Vermutlich wurde einfach angenommen, dass es meistens in Docker ausgeführt wird, oder?