Ein Installationsbefehl dauert drei Sekunden. Was danach im Projektverzeichnis liegt, sind nicht das eine Paket, das Du wolltest, sondern oft hunderte weitere, die es seinerseits mitbringt. Du hast eine Entscheidung getroffen und dabei dutzende fremde Entscheidungen übernommen, von Menschen, die Du nicht kennst, deren Code Du nie gelesen hast und dessen Pflege trotzdem ab sofort Dein Problem ist.
Die drei Erfolgskriterien von Guideline 3.12
Verwaltung von Abhängigkeiten: Überprüfe Abhängigkeiten regelmäßig und entferne ungenutzte Bibliotheken und Frameworks. Deinstalliere Pakete, die nicht benötigt werden.
Notwendigkeit von Abhängigkeiten: Beschränke den Einsatz externer Bibliotheken und Frameworks auf das Notwendige, denn das verringert die Menge an Code, die der Browser herunterladen und auswerten muss. Bevorzuge schlichten eigenen Code, wo das möglich ist. Prüfe die Paketgröße und bewerte, ob sich einzelne Module statt ganzer Bibliotheken einbinden lassen oder ob eine leistungsfähigere Alternative infrage kommt. Ersetze etablierte und vertrauenswürdige Sicherheitsbibliotheken nicht durch eigene Implementierungen, denn das erhöht die Angreifbarkeit und kann sich negativ auf die Nachhaltigkeit auswirken.
Aktualisierung von Abhängigkeiten: Halte alle Abhängigkeiten durch regelmäßige Überprüfung und Pflege aktuell.
Meine Einordnung
Das zweite Kriterium oben nennt den technischen Kern: Jede Bibliothek ist Code, den der Browser herunterladen und auswerten muss. Aber die eigentliche Rechnung steht im dritten Kriterium, und sie hat kein Ende. Eine Abhängigkeit ist keine einmalige Ausgabe, sondern ein Abonnement. Sie muss aktualisiert werden, ihre Änderungsprotokolle wollen gelesen, ihre Sicherheitsmeldungen verfolgt und ihre Bruchstellen bei größeren Sprüngen repariert werden. Und das gilt nicht nur für die Pakete, die Du bewusst ausgewählt hast, sondern für den ganzen Baum darunter.
Auf datensm.art halte ich diese Liste bewusst extrem kurz. Für den Bau der Website gibt es genau eine Abhängigkeit, nämlich die Suchindizierung. Sonst nichts. Kein Framework, keine Hilfsbibliothek, kein Baukasten. Meine Werkzeuge in der Toolbox, der KGMID-Check und der Green Check, sind in schlichtem JavaScript geschrieben, ohne fremde Bausteine. Das ist keine Sparsamkeit aus Prinzipienreiterei. Es ist die Erkenntnis, dass ich diese Website allein betreibe und jede Abhängigkeit Zeit kostet, die ich lieber in Inhalte stecke.
Was mich an dieser Guideline überzeugt, ist ihre Ehrlichkeit an einer Stelle, an der viele Nachhaltigkeitsratgeber schweigen. Sie sagt ausdrücklich: Ersetze etablierte Sicherheitsbibliotheken nicht durch eigenen Code. Das ist die Grenze der Reduktion, und sie ist gut begründet.
Wo ich weiter gehe
Denn genau hier stößt mein sonstiges Prinzip an sein Limit, und das gehört ausgesprochen. Bei Bildern, Skripten oder Datenbankabfragen gilt: weniger ist immer besser. Bei Verschlüsselung, Anmeldeverfahren oder Eingabeprüfung gilt das nicht. Eine selbst gebaute Lösung ist dort fast nie leichter, sondern nur ungeprüft. Eine Sicherheitslücke, die zu einem Datenabfluss führt, hat eine Umweltbilanz, gegen die ein paar eingesparte Kilobyte lächerlich wirken: Untersuchungen, Benachrichtigungen, Neuaufbau, im Zweifel juristische Aufarbeitung.
Deshalb formuliere ich die Regel anders als die Guideline. Sie sagt: Nutze Abhängigkeiten sparsam. Ich sage: Entscheide bei jeder einzelnen, ob Du das Problem wirklich besser lösen kannst als die Menschen, die sich seit Jahren damit beschäftigen. Bei einer Datumsformatierung lautet die Antwort meistens ja, ein paar Zeilen eigener Code genügen. Bei Kryptografie lautet sie so gut wie immer nein.
Dein erster Schritt heute
Verschaff Dir zuerst einen Überblick darüber, was tatsächlich in Deinem Projekt liegt. Meistens ist es deutlich mehr als gedacht.
npm ls --depth=0 anzeigen, was Du direkt eingebunden hast, und geh die Liste Zeile für Zeile durch. Kannst Du bei einem Eintrag nicht sofort sagen, wofür er da ist, ist das ein Kandidat zum Entfernen. Danach npm outdated und npm audit für den Pflegezustand. Und für die Zukunft eine Gewohnheit, die viel spart: Schau vor jeder neuen Installation nach, wie groß das Paket ist und wie viele weitere es mitbringt. Das entscheidet sich in einer Minute vorher, nicht in Stunden hinterher.Bei einem Redaktionssystem gilt dasselbe mit anderen Worten: Deine Plugins sind Deine Abhängigkeiten. Jedes einzelne bringt fremden Code, eigene Aktualisierungen und eine eigene Angriffsfläche mit.
Die Abhängigkeit, die Du nicht eingehst, musst Du auch nie wieder aktualisieren.
Quelle: W3C-Fassung von Guideline 3.12