Technik mit begründetem Nutzen
Weniger Abhängigkeiten. Mehr Kontrolle über die eigene Website.
Externe Bibliotheken, Pakete und Frameworks können Entwicklung beschleunigen und sinnvolle Funktionen bereitstellen. Sie werden jedoch Teil des Projekts und bringen eigene Versionen, Abhängigkeiten und mögliche Risiken mit.
Abhängigkeiten verstehen
Installiert ist mehr als der sichtbare Paketname
Die Prüfung unterscheidet, welche Technik direkt gewählt wurde und welche weiteren Bestandteile dadurch in Build oder Browser gelangen.
| Kriterium | Ebene | Prüffrage |
|---|---|---|
| Direkte Abhängigkeit | Ein Paket wird ausdrücklich im Projekt eingebunden. | Welche konkrete Aufgabe erfüllt es? |
| Indirekte Abhängigkeit | Ein gewähltes Paket lädt weitere Unterabhängigkeiten nach. | Welche zusätzlichen Versionen und Risiken entstehen? |
| Build-Abhängigkeit | Werkzeug wird nur zur Erzeugung der fertigen Dateien benötigt. | Ist der Build reproduzierbar und dokumentiert? |
| Browser-Code | Code und Verbindungen erreichen jeden Besucher. | Welche Daten, Dateigrößen und Laufzeitkosten entstehen? |
Paketprüfung
Nutzen, Pflege und Auswirkung gemeinsam beurteilen
Nicht die bloße Existenz eines Pakets ist das Problem. Entscheidend sind Aufgabe, Zustand und Folgen für das konkrete Projekt.
- direkte und automatisch nachgeladene indirekte Abhängigkeiten erfassen
- veraltete oder nicht mehr gepflegte Pakete erkennen
- kleine Funktionen auf native HTML-, CSS- und Browseralternativen prüfen
- Auswirkungen auf Build, Wartung und Sicherheit bewerten
- Bindung an das Ökosystem eines Frameworks berücksichtigen
- Produktionsabhängigkeiten auf den benötigten Umfang begrenzen
Werkzeuge ohne Lagerdenken
Astro, React, Vue und Node.js können richtig sein
Diese Technologien sind nicht grundsätzlich schlecht. Sie lösen unterschiedliche Aufgaben und können für interaktive Anwendungen, große Inhaltsmodelle oder komplexe Entwicklungsabläufe gut geeignet sein.
Eine kleine Unternehmenswebsite benötigt sie jedoch nicht automatisch. Der Einsatz muss durch Funktionen, Pflege oder Weiterentwicklung begründet sein.
KI-generierte Vorschläge
Installationsbefehle sind noch keine Architektur
KI kann Pakete vorschlagen, ohne alle Folgen für Build, Browser und Wartung zu kennen. Solche Vorschläge werden nicht blind ausgeführt.
Zuerst wird geprüft, ob die Aufgabe bereits mit nativen Webfunktionen oder der bestehenden Projektstruktur gelöst werden kann.
Reproduzierbarer Betrieb
Vom Quellstand zum überprüfbaren Build
Ein dokumentierter Build reduziert Überraschungen zwischen Entwicklungsumgebung und Produktion.
Versionen festlegen
In Projekten mit Paketverwaltung halten Lock-Dateien den aufgelösten Abhängigkeitsstand fest. Dieses Projekt kommt ohne Paketmanager aus.
Build und Ausgabe trennen
Werkzeuge dürfen während des Builds helfen, ohne automatisch als JavaScript an Besucher ausgeliefert zu werden.
Sicherheitsprüfungen wiederholen
Verwendete Pakete und Werkzeuge werden regelmäßig mit passenden Audit- und Versionsprüfungen betrachtet.
Ergebnis kontrollieren
Fertige Dateien, interne Links, Metadaten, Struktur und Browser-Code werden im Produktionsbuild geprüft.
Ich behaupte nicht, jede einzelne Zeile einer umfangreichen externen Bibliothek manuell zu prüfen. Ich entscheide aber bewusst, welche Abhängigkeiten überhaupt benötigt werden, reduziere ihre Anzahl und prüfe den für das Projekt relevanten Code und Build.
Nächster Schritt
Technische Grundlage besprechen
Ich prüfe, welche Funktionen das Projekt benötigt und welche Abhängigkeiten dafür einen echten Nutzen liefern.