Webentwicklung: Eingebundene JavaScript-Libraries werden so gut wie nie aktualisiert
Der CDN-Anbieter Cloudflare thematisiert ein Phänomen, das Entwicklern nicht neu sein dürfte. Haben Entwickler erforderliche Bibliotheken wie jQuery einmal im Head der jeweiligen Website verlinkt, bleiben sie in der verlinkten Version dauerhaft in Betrieb. Eine Update-Strategie gibt es in der Regel nicht.
Der statische Zustand gängiger JS-Bibliotheken
Cloudflare konnte das anhand der jQuery-Bibliothek und der Animations-Library Tweenmax über den Hosting-Service CDNJS belegen. Bei beiden Bibliotheken zeigte sich, dass alte, auch sehr alte Versionen nach wie vor in nennenswertem Umfang Requests erhalten.
Zwar konnte Cloudflare stets auch steigende Nutzungszahlen für die jeweils aktuellen Versionen feststellen, mit diesen steigenden Zahlen gingen jedoch keine sinkenden Werte bei alten Versionen einher. Das bestätigt den Eindruck, dass einmal implementierte Bibliotheken auf ewig, zumindest bis sie aus anderen Gründen dysfunktional werden, im Projekt verbleiben.
Erklärungen bietet Cloudflare nicht, die folgenden Faktoren könnten aber ausschlaggebend für das Phänomen sein.
jQuery: Omnipräsente JavaScript-Bibliothek. (Screenshot: t3n)
Die 3 Möglichkeiten, eine JS-Bibliothek einzubinden
CDNJS (also Content-Delivery-Network für JavaScript) ist ein Alternativangebot etwa zum Google-CDN. Der Unterschied besteht in der Vielfalt gehosteter Bibliotheken, die bei CDNJS größer ist.
Das CDNJS erlaubt es Entwicklern, beliebte JavaScript-Bibliotheken über einen Link zum CDNJS einzubinden. Dabei werden jedoch alte Versionen nicht gegen neue ersetzt, sondern die Versionshistorie bleibt insgesamt verfügbar.
Die Alternative zu einem CDN besteht darin, die erforderlichen Bibliotheken auf dem Webserver des Projekts abzulegen und von da einzubinden oder per Link auf das offizielle Repository der Bibliothek zuzugreifen, was indes nicht jede Bibliothek erlaubt oder überhaupt vorsieht.
Das Problem: Set it and forget it
Die dargestellten Optionen zeigen bereits das Problem. Einmal eingebundene JavaScript-Bibliotheken sind statisch verknüpft. Wenn die Bibliotheks-Entwickler nun ein Update herausgeben, werden die teils millionenfach eingebundenen Libraries nicht automatisch aktualisiert. Vielmehr müsste sich der Webmaster selbst darum kümmern.
Geringe Update-Motivation aus 2 Gründen verständlich
In klassischen Erstellungsprozessen kommt es dabei im Wesentlichen zu zwei Problemen. Häufig wird der Entwickler für die Bereitstellung einer Website bezahlt. Einmal fertig und übergeben, kümmern sich weder Kunde noch Entwickler darum.
Das zweite Problem besteht darin, dass es im Zuge des Updates von JS-Bibliotheken durchaus zu sogenannten Breaking Changes kommt. Das bedeutet, dass die aktualisierte Bibliothek weitere Änderungen an der Website erforderlich machen würde, damit sie wie zuvor funktioniert.
Gerade dieser zweite Punkt lässt sich Kunden zumeist nicht begreiflich machen. Sie haben für eine Website bezahlt, die funktioniert und sollen nun für Anpassungen dafür bezahlen, dass sie weiterhin funktioniert wie zuvor. Der Entwickler seinerseits ist auch nicht übermotiviert, Änderungen vorzunehmen, die zu seltsamem Verhalten vormals funktionaler Prozesse führen können.
Nachteile von CDN und anderen Dritt-Hostern
Für die Einbindung per CDN (Content Delivery Network) oder über das offizielle Projekt, sofern dieses das überhaupt zulässt, entscheiden sich Entwickler, die im Kundenauftrag arbeiten, ebenso ungern. Denn ein CDN oder sonstiger Hoster ist immer ein Dritter, für dessen reibungslose Funktionalität keine Gewähr besteht. Wieso sollte der Entwickler dieses Risiko eingehen, zumal die gängigen JavaScript-Bibliotheken von ihren Größen her den CDN-Einsatz in keiner Weise nahelegen?
Für den Entwickler sogar der schlimmste Fall wäre dabei eine automatische Einbindung der jeweils aktuellsten Version einer Bibliothek. Damit verliert er jede Kontrolle über die Uptime-Prognose der von ihm betreuten Websites. Wer will schon vom Kunden nachts um drei aus dem Bett geklingelt werden, weil dessen Onlineshop den Geist aufgegeben hat?
Aktuelle Bibliotheken nur bei Groß- und Eigenprojekten auf der Agenda
Anders sieht all das aus, wenn Entwickler ihre eigenen Projekte betreuen oder als Angestellte für den Betrieb einer oder mehrerer Websites zuständig sind. Auch hier wird eine externe Einbindung schon wegen der zusätzlichen Requests, der nicht zu kontrollierenden Latenz und der möglichen Sicherheitsproblematik nicht die erste Wahl sein.
Aber auf der To-do-Liste wird ganz sicher stehen, dass die eingesetzten Bibliotheken zumindest in definierten zeitlichen Abständen auf Aktualität geprüft und im Zweifel angepasst werden.
Wie geht ihr mit dem Thema um?
Passend dazu: Konkurrenz für JavaScript? W3C erklärt Web Assembly zum Web-Standard
Exakt die bei „Geringe Update-Motivation aus 2 Gründen verständlich“ genannten Gründe sind dafür verantwortlich. Und wie auch geschrieben, für Entwickler keine überraschende Nachricht.
Abseits davon bin ich mir aber auch unschlüssig, was ich von der immer mehr zunehmenden Updateflut halten soll, sowohl in der Webentwicklung als auch sonst im Leben. Es ist zwar schön, wenn Software regelmäßig weiterentwickelt wird. Aber wenn man dann gefühlt eine lebenslange Verpflichtung zu Zeitaufwand für Updates eingeht, überlegt man es sich irgendwann zweimal, ob man das wirklich will.
Seitdem es beim npm nach jedem install/update den audit gibt, achte ich zumindest darauf, dass hier keine Vulnerabilities verbleiben. Das betrifft dann natürlich auch nur Projekte, an denen ich aktiv etwas mache oder die ich betreue. Für PHP gibt es den https://github.com/sensiolabs/security-checker, den man via Cronjob regelmäßig laufen lassen kann. So kann man sich per E-Mail informieren lassen, wenn ein package verwundbar ist. Das ist insbesondere für Custom-Entwicklungen, bei denen es keine regelmäßigen Updates der Codebasis gibt, wichtig. Vielleicht sollte ich mir soetwas auch für die npm dependencies einrichten
Ich habe in den letzten Wochen im Rahmen einer dieser unbeliebteren Wartungsaktionen das (bei mir immer statische) Custom jQuery durch das von WP mitgelieferte ersetzt da dort die Versionen mittlerweile neuer sind. Leider ist aber ein extra Request für jQuery Migrate dabei, das ich im Frontend nicht benötige.
Prinzipiell sehe ich bei manchen rein Funktionalen Libs wie jQuery (je nach verwendeten Funktionen) weniger dringenden Bedarf für Updates als bei API-Libs zu Drittanbieter-Services. Da hier mehr sensible Daten unterwegs sind.
Ein Punkt der in dem Artikel vergessen wurde, ist das Thema Datenschutz. Bei der Einbindung von externen Librarys muss man das in der Datenschutzerklärung aufnehmen, die Einwilligung des Users einholen (IP als personenbezogene Daten) und dann gehen sie Daten oft in die USA. Also eher nicht empfehlenswert.