Websites herunterladen, die Angular Material nutzen

Über Angular Material

Frontend-Bibliotheken sind umso sichtbarer, je weniger modern der Build ist, und Angular Material ist ein klares Beispiel dafür. Die Kopien, die wir von außen sehen, sind in der Regel jene, die eine Seite als einfache Datei lädt, während Kopien, die eine aktuelle Toolchain in ein Anwendungs-Bundle kompiliert, kaum etwas hinterlassen, das sich als Fingerabdruck eignet.

Der Anbieter Google veröffentlicht die Komponentenbibliothek seit 2014 unter der Lizenz MIT und liefert Angular-Teams Buttons, Formularelemente, Dialoge, Tabellen und Navigation, die Material Design samt seinen Regeln zur Barrierefreiheit folgen. Wer sie einsetzt, entscheidet nach dem Zeitaufwand, nicht nach Geschmack. Ein Team, das ein internes Admin-Tool, ein Dashboard oder ein Kundenportal ausliefert, will keinen Datumswähler von Grund auf entwerfen, und ein gepflegtes Komponentenset beendet die Diskussion, bevor sie beginnt.

Die Versionsdaten machen das Sichtbarkeitsproblem greifbar. Wir verzeichnen 41 verschiedene Versionen im Einsatz, und am häufigsten melden Installationen Version 1.1.0-rc2, eine Linie aus der Zeit, als die Bibliothek direkt in eine Seite eingebunden und nicht in ein Bundle kompiliert wurde. Eine Fragmentierung dieses Ausmaßes ist keine Fluktuation innerhalb aktueller Projekte. Sie bedeutet, dass der sichtbare Bestand zu alten Installationen hin verzerrt ist: langlebige Intranets, Portale, Backoffice-Masken und Admin-Panels, die einmal gebaut wurden, noch funktionieren und seitdem nicht neu gebaut wurden.

Stand Oktober 2026 erkennen wir Angular Material auf 328 Websites, und die Zahl sollte man eher als Stichprobe eines viel größeren Bestands verstehen denn als Vollerhebung. In ein Bundle kompilierte und minifizierte TypeScript-Quellen lassen sich nur an Fragmenten erkennen, die den Build überstehen, und ein Team, das Module umbenennt oder ungenutzten Code konsequent entfernt, taucht überhaupt nicht auf. Die Untererfassung ist hier systematisch und nicht zufällig, und sie trifft gerade die neuesten und am besten gepflegten Anwendungen.

Die Bibliothek ist zudem ein Indikator für etwas Größeres als sie selbst. Angular wird meist auf Abteilungsebene gewählt und nicht für ein einzelnes Projekt, in der Regel dort, wo eine langlebige interne Anwendung von denjenigen gepflegt werden muss, die im nächsten Jahr im Team sind. Ein Eintrag der Komponentenbibliothek in den Daten steht deshalb im Allgemeinen für eine ganze Framework-Entscheidung dahinter. Wer den Markt für Angular-Tools, Schulungen oder Auftragsarbeiten abschätzt, wird die Komponentenbibliothek leichter beobachten können als das Framework selbst, was sie zu einem praktischen Zugang zu einem Bestand macht, der sich sonst in Bundles versteckt.

Eine Einzelabfrage für eine Domain befriedigt bloß die Neugier. Die Liste ist ein Inventar von Legacy-Frontends. Anbieter von Entwicklertools nutzen eine solche Datei, um die Zielgruppe für Migrationstools und alternative Komponenten abzuschätzen. Agenturen finden damit Portale, deren Neubau überfällig ist, denn eine Seite, die noch ein frühes Release einer Komponentenbibliothek ausliefert, hat lange niemand mehr angefasst. Sicherheits- und Compliance-Teams nutzen sie in umgekehrter Richtung und prüfen, ob ihr eigener Bestand oder der eines Zulieferers noch eine ungepflegte Frontend-Abhängigkeit öffentlich ausliefert.

Kombiniert man die Versionsspalte mit den Spalten für Land und Endung, klärt dieselbe Datei eine Frage, an die keine Prüfung einzelner Domains heranreicht: nicht, ob eine einzelne Website im Rückstand ist, sondern welcher Anteil einer Branche im Rückstand ist, und ob der Anteil alter Releases von einem Snapshot zum nächsten sinkt oder einfach unverändert bleibt.