Three.js ist eine JavaScript-Bibliothek, mit der sich 3D-Grafik im Browser umsetzen lässt – also Szenen, Kameras, Licht und Materialien, ohne direkt auf die technischen Schnittstellen der Grafikkarte zugreifen zu müssen. Lange war das ein Werkzeug für eine überschaubare Gruppe von Spezialistinnen und Spezialisten: Produktkonfiguratoren, Datenvisualisierungen, experimentelle Kampagnenseiten. Nun meldet die Bibliothek wöchentliche Downloadzahlen im zweistelligen Millionenbereich.
Solche Sprünge lassen sich selten allein mit organischem Wachstum erklären. Als naheliegender Treiber gelten KI-Agenten, die auf Zuruf ganze Weboberflächen erzeugen und dabei offenbar bevorzugt zu einem begrenzten Set bekannter Bibliotheken greifen – Three.js gehört dazu.
Warum Modelle zu bestimmten Bibliotheken tendieren
Sprachmodelle schlagen das vor, was in ihren Trainingsdaten stark vertreten und gut dokumentiert ist. Three.js erfüllt beide Kriterien seit Jahren: viele Beispiele, viele Tutorials, ein stabiles, über lange Zeit kaum verändertes Grundkonzept. Für ein Modell ist das ein sicherer Pfad – der generierte Code läuft mit hoher Wahrscheinlichkeit beim ersten Versuch.
Hinzu kommt ein Verstärkungseffekt. Je häufiger Agenten eine Bibliothek einsetzen, desto mehr Code mit dieser Bibliothek landet in öffentlichen Repositories, Foren und Beispielsammlungen – und damit potenziell in künftigen Trainingsdaten. Technologieentscheidungen, die früher in Architekturrunden fielen, werden so zu einem Nebenprodukt statistischer Häufigkeit.
Downloadzahlen sind keine Nutzungszahlen
Eine Einordnung ist wichtig: Downloads aus einem Paketregister sagen wenig darüber aus, wie viele produktive Websites eine Bibliothek tatsächlich ausliefern. Jeder automatisierte Build, jede Testumgebung, jeder flüchtig erzeugte Prototyp zählt mit. Wenn Agenten im Minutentakt Projekte anlegen, verwerfen und neu bauen, entstehen hohe Zahlen ohne entsprechende Verbreitung im Livebetrieb.
Für die Bewertung einer Technologie heißt das: Downloadkurven taugen derzeit noch weniger als früher als Reifeindikator. Relevanter bleiben Fragen nach Releasezyklus, Breaking Changes, Größe der Maintainer-Gruppe und Eignung für den konkreten Anwendungsfall.
Was das für Performance heißt
3D im Browser ist nicht kostenlos. Eine Szene bringt zusätzliche JavaScript-Last, Texturen, Geometriedaten und dauerhafte Renderschleifen mit sich. Das kostet Ladezeit, Rechenleistung und auf Mobilgeräten Akku. Wenn ein Agent eine Startseite mit animiertem 3D-Hintergrund ausliefert, weil das in seinen Trainingsdaten die gängige Antwort auf „moderne Landingpage“ war, entsteht ein Aufwand, den niemand fachlich begründet hat.
Gerade im Mittelstand kollidiert das mit harten Zielgrößen: Core Web Vitals als Messwerte für Ladeverhalten und Interaktivität, Barrierefreiheitsanforderungen, Energie- und Hostingkosten. Bewegte 3D-Elemente können zudem Nutzerinnen und Nutzer ausschließen, die auf reduzierte Animationen angewiesen sind – ein Punkt, den generierter Code selten von sich aus berücksichtigt.
Wartbarkeit: Der eigentliche Kostenfaktor
Eine 3D-Komponente bringt eine eigene Begriffswelt mit. Wer sie später ändern soll, braucht Kenntnisse über Szenengraphen, Materialien und Renderpipelines – Wissen, das in vielen Teams nicht vorhanden ist. Code, der in Sekunden entsteht, kann über Jahre gepflegt werden müssen.
Das Muster ist nicht neu, bekommt durch Agenten aber eine neue Geschwindigkeit. Abhängigkeiten wachsen schneller, als Reviewprozesse sie aufnehmen können. Entscheidend ist deshalb weniger, ob KI-generierter Code eingesetzt wird, sondern ob er dieselben Prüfschritte durchläuft wie handgeschriebener.
Praktische Leitplanken
- Abhängigkeiten freigeben, nicht nachträglich entdecken: Neue Bibliotheken in generiertem Code gehören in ein explizites Review, inklusive Lizenz, Pflegestatus und Bundle-Größe.
- Budgets definieren: Feste Grenzwerte für JavaScript-Größe und Ladezeit machen sichtbar, wenn eine generierte Komponente den Rahmen sprengt.
- Vorgaben in die Prompts legen: Wer den eigenen Technologiestack, erlaubte Pakete und Barrierefreiheitsregeln als Kontext mitgibt, reduziert die Zufallsauswahl deutlich.
- Prototyp und Produktion trennen: Agenten sind stark beim schnellen Veranschaulichen. Für den Livebetrieb braucht es eine bewusste Entscheidung, ob der Prototyp-Stack übernommen wird.
- Angemessenheit prüfen: Ein Produktkonfigurator rechtfertigt 3D. Eine dekorative Hintergrundanimation auf einer Unternehmensseite selten.
Einordnung
Der Fall Three.js zeigt weniger ein Problem der Bibliothek als eine Verschiebung in der Entscheidungskette: Technologieauswahl wandert von der Architekturdiskussion in die Trainingsdaten generativer Werkzeuge. Für Web- und Softwareprojekte heißt das, Governance über Abhängigkeiten aktiv zu organisieren, statt sie dem Vorschlagsverhalten eines Modells zu überlassen. Wer Performance-Budgets, Freigabeprozesse und klare Stack-Vorgaben etabliert, nutzt die Geschwindigkeit von KI-Agenten, ohne sich technische Schulden einzukaufen, die erst in der Wartungsphase sichtbar werden.
