Websites herunterladen, die Catberry.js nutzen

Über Catberry.js

Dasselbe JavaScript auf dem Server und im Browser zu rendern war Mitte des vergangenen Jahrzehnts ein ungelöstes Problem. Eine Reihe von Node-Projekten nahm es in Angriff, bevor die großen Frameworks die Idee übernahmen und daraus einen Konfigurationsschalter machten.

Catberry.js war einer dieser Versuche. Das Framework gliederte eine Anwendung in unabhängige Komponenten, die ihren eigenen Zustand und ihr eigenes Rendering verwalten, und behandelte serverseitiges Rendering als Standard statt als Zusatz. Eine Seite kam also als Markup an, und danach übernahm die Anwendung im Browser. Die Arbeit daran reicht bis 2014 zurück, als die Bezeichnung „isomorph“ noch ein konkretes technisches Problem beschrieb und keine Marketingkategorie. Unter der Lizenz MIT veröffentlicht und in JavaScript geschrieben, wurde das Projekt offen entwickelt und über npm verteilt, und auf genau diesem Weg gewinnt ein Framework ohne Unternehmen dahinter überhaupt Nutzer.

Stand Oktober 2026 findet der Crawl Catberry.js auf 1 Website. Eine so kleine Zahl ist eher das Interessante als das Enttäuschende daran, denn sie dokumentiert, was einer ganzen Generation von Frameworks widerfahren ist, die ein echtes Problem lösten und dann von Projekten mit mehr Leuten dahinter überholt wurden. Websites, die die Signatur noch tragen, sind selten neue Projekte.

Für die Forschung bedeutet ein Treffer in der Praxis ein Wartungsrisiko. Eine Seite, die noch von einem nicht mehr gepflegten Framework ausgeliefert wird, lässt auf eine Codebasis schließen, die lange niemand neu aufgebaut hat, auf Abhängigkeiten, die an alte Node-Versionen gebunden sind, und auf ein Team, das das Frontend nicht anfassen kann oder will. Agenturen, die Replatforming-Projekte anbieten, Sicherheitsforscher auf der Suche nach veralteten Abhängigkeitsbäumen und alle, die untersuchen, wie Frameworks kommen und gehen, wollen von einer Seite wie dieser dasselbe, nämlich die Domains und nicht die Gesamtzahl.

Die Erkennung beruht hier auf einem Rückschluss, und das sollte man offen sagen. Die Signatur, die wir abgleichen, ist ein clientseitiges Artefakt. Eine Build-Pipeline, die es umbenennt oder inline einbettet, verbirgt das Framework daher vollständig, und eine Anwendung, die nur auf dem Server rendert, kann es nutzen, ohne etwas zu hinterlassen, das ein Crawler sehen könnte. Die Zahl ist deshalb eine Untergrenze, und vermutlich eine unscharfe.

Eine Prüfung pro Domain zeigt, ob eine Website, die Sie ohnehin im Verdacht haben, das Framework nutzt. Eine herunterladbare Liste klärt die Frage, auf die es bei einer Untersuchung alternder Frontends wirklich ankommt, nämlich wo die verbliebenen Installationen sind. Durch noch so viele Einzelprüfungen lässt sich das nicht rekonstruieren, denn die Domains, auf denen ein obskures Framework läuft, sind genau jene, auf die man nie käme.