Télécharger les sites web qui utilisent Catberry.js

À propos de Catberry.js

Faire le rendu du même JavaScript sur un serveur et dans un navigateur était un problème ouvert au milieu de la décennie précédente, et plusieurs projets Node s’y sont attaqués avant que les frameworks dominants n’absorbent l’idée et n’en fassent une option de configuration.

Catberry.js fut l’une de ces tentatives. Le framework découpait une application en composants indépendants qui possèdent leur état et leur rendu, et il traitait le rendu côté serveur comme le mode par défaut plutôt que comme un ajout, si bien qu’une page arrivait sous forme de balisage avant de reprendre la main dans le navigateur. Les travaux remontent à 2014, à l’époque où l’étiquette isomorphe désignait encore un problème d’ingénierie précis plutôt qu’une catégorie marketing. Publié sous licence MIT et écrit en JavaScript, le projet était hébergé sur npm et développé au grand jour, ce qui est la seule façon pour un framework sans entreprise derrière lui de rassembler des utilisateurs tout court.

En octobre 2026 l’exploration reconnaît Catberry.js sur 1 site. Un décompte aussi faible est la partie intéressante plutôt qu’une déception, parce qu’il consigne ce qui est arrivé à toute une génération de frameworks qui ont résolu un vrai problème avant d’être dépassés par des projets portés par plus de monde. Les sites qui portent encore la signature sont rarement des constructions récentes.

Pour un chercheur, la portée pratique d’une correspondance est le risque de maintenance. Une page encore servie par un framework qui n’est plus maintenu suppose une base de code que personne n’a reconstruite depuis longtemps, des dépendances figées sur d’anciennes versions de Node, et une équipe qui ne peut pas ou ne veut pas toucher au front-end. Les agences qui proposent des projets de replateformage, les chercheurs en sécurité à l’affût d’arbres de dépendances périmés et quiconque étudie le renouvellement des frameworks attendent tous la même chose d’une page comme celle-ci, à savoir les domaines plutôt que le total.

La détection est ici indirecte, et cela mérite d’être dit franchement. La signature que nous reconnaissons est un artefact côté client, si bien qu’un circuit de construction qui la renomme ou l’intègre au code masque complètement le framework, et qu’une application dont le rendu se fait uniquement sur le serveur peut s’en servir sans rien laisser qu’un robot d’exploration puisse voir. Le chiffre est donc une borne basse, et probablement une borne souple.

Une vérification domaine par domaine indique si un site que vous soupçonnez déjà utilise le framework. Une liste téléchargeable répond à la question qui compte vraiment pour une étude des interfaces vieillissantes, à savoir où se trouvent les installations restantes. Aucune vérification des domaines un par un ne reconstituera cela, parce que les domaines qui font tourner un framework obscur sont précisément ceux auxquels vous n’auriez jamais pensé.