Frameworkismus bezeichnet die Haltung, für jedes Problem ein Framework einzusetzen, auch dort, wo einfache Mittel reichen würden. Das Wort ist eine kritische Prägung aus der Entwicklung und zielt auf den Umgang mit der Technik: Die Werkzeugfrage steht vor der Sachfrage, entschieden wird sie, bevor jemand weiß, was die Seite leisten soll.
- Frameworkismus
Die Haltung, für jedes Problem ein Framework einzusetzen, auch wo einfache Mittel reichen.
Beispiel: „Hinter dem zähen Relaunch stand Frameworkismus: Jede Frage wurde zur Werkzeugfrage.“Das Ergebnis dieser Haltung: Software, die mit jeder zusätzlichen Schicht komplexer wird und mehr Rechenzeit verlangt.
Beispiel: „Der Frameworkismus zeigt sich erst im Betrieb, wo jede zusätzliche Schicht Rechenzeit kostet.“Auch: Frameworkism. Englisch framework heißt wörtlich Gerüst; den englischen Begriff hat Alex Russell im November 2024 geprägt.
Zur Wortbildung: Die Endung -ismus macht aus einer Sache eine Lehre oder ein Dogma. Gemeint ist eine Praxis, der jemand auch dort folgt, wo sie nichts mehr beiträgt, so wie beim Aktionismus.
Abgrenzung zum Framework: Das ist ein Werkzeug und für viele Aufgaben das richtige. Frameworkismus beschreibt die Haltung, mit der es gewählt und verteidigt wird.
Was dem Frameworkismus vorgeworfen wird
Vier Punkte, die in der Debatte immer wiederkehren:
Überbau: ein großes Gerüst für eine Landingpage, die mit HTML, CSS und etwas JavaScript auskäme.
Abhängigkeit: Wer das Framework beherrscht und die Sprache darunter nur in Umrissen kennt, steht beim nächsten großen Versionssprung ohne Werkzeug da.
Ballast: Mitgeliefert wird auch der Teil, den das Projekt nie benutzt. Das landet dort, wo der Code ausgeführt wird, und zeigt sich in Ladezeit und Rechenlast.
Mode: Die Wahl folgt dem, was gerade besprochen wird, und nicht der Aufgabe.
Den englischen Begriff geprägt hat Alex Russell, Entwickler bei Google und seit Jahren eine Stimme in der Performance-Debatte, im Beitrag If Not React, Then What? auf seinem Blog Infrequently Noted. Er beschreibt darin eine Debatte, die sich im eigenen Ökosystem dreht, und sieht den Schwerpunkt bei React.
Zusammen ergibt das eine Rechnung, und bezahlt wird sie überall dort, wo der Code läuft: im Browser des Besuchers, auf dem Server des Betreibers und in einer App auf dem Gerät, die dadurch träger reagiert und nebenbei mehr Strom zieht. Jede Schicht erleichtert die Arbeit am Code und kostet Rechenzeit. Auf einem neuen Gerät fällt das kaum auf, auf einem fünf Jahre alten Telefon entscheidet es darüber, ob die Anwendung benutzbar bleibt.
Woran du Frameworkismus im Projekt erkennst
An der Richtung der Antworten. Die Seite lädt langsam, und besprochen werden eine andere Bibliothek, ein anderer Bundler, ein Wechsel auf Server-Komponenten. Was die Seite tatsächlich ausliefert und wie viel davon der Browser ausführen muss, kommt in dieser Runde nicht vor.
Das zweite Zeichen ist der Aufwand, der in der Werkzeugkette wächst, während sich an der Ladezeit nichts bewegt. Wer den Verlauf seiner Messwerte neben die Liste der eingeführten Werkzeuge legt, sieht es in zwei Minuten.
Was der Verzicht auf Schichten messbar bringt
GitHub hat im September 2026 die Laufzeit von Copilot von Node.js auf Rust portiert und die Messwerte veröffentlicht: Der zusätzliche Speicherbedarf für zehn parallele Sitzungen fiel von 1.383 MB auf 126 MB, ein Durchlauf aus Start, einem Zug und Abbau von 5,25 Sekunden auf 292 Millisekunden, der Durchsatz stieg von 7,6 auf 120 Sitzungen je Sekunde. Der Bericht nennt die Zahlen samt Messaufbau und schränkt sie selbst ein: gemessen ohne Modellinferenz und ohne Netzlatenz, und im selben Zeitraum sind weitere Änderungen eingeflossen.
Der zweite Fall liegt weiter zurück und ist größer. Cloudflare hat 2022 seinen Proxy auf einen eigenen, in Rust geschriebenen Dienst namens Pingora umgestellt, der den NGINX-Stack ersetzt. Bei gleicher Last braucht er rund 70 Prozent weniger CPU und 67 Prozent weniger Speicher, und die Zeit bis zum ersten Byte sank im Mittel um 5, im 95. Perzentil um 80 Millisekunden. Cloudflare beschreibt den Umbau im Detail.
Beide Fälle liegen auf dem Server und betreffen keine Oberfläche im Browser. Übertragbar ist deshalb die Richtung und nicht der Faktor: Wer eine Schicht entfernt, die er nicht braucht, gewinnt an mehreren Stellen zugleich. Für eine Website heißt das meist schlicht weniger JavaScript.
Warum die Rechnung trotz schnellerer Geräte nicht aufgeht
Den Effekt kennt jeder vom eigenen Telefon: Es ist beim Kauf schnell und drei Jahre später zäh, obwohl an der Hardware nichts gealtert ist. Was wächst, ist die Software darauf. Niklaus Wirth hat das 1995 in seinem Aufsatz „A Plea for Lean Software“ in der IEEE-Zeitschrift Computer beschrieben, und der Satz dazu ist seither als Wirthsches Gesetz bekannt: Software wird schneller langsamer, als die Hardware schneller wird. Die Beobachtung selbst schreibt Wirth seinem Kollegen Martin Reiser zu.
Auf dem Server wird aus dem Effekt eine Rechnung mit Betrag. Wer eine Anwendung betreibt, bezahlt jede überflüssige Schicht in Maschinen, Strom und Kühlung, und zwar jeden Monat aufs Neue. Die Frage, ob sich die Infrastruktur halbieren lässt, wenn die Anwendung effizienter gebaut wird, hat damit eine Antwort in Euro.
Drei Entwicklungen schieben diese Abwägung gerade in dieselbe Richtung: Energie wird teurer, Hardware wird teurer, und das Schreiben von Code wird billiger, seit KI-Werkzeuge einen großen Teil davon übernehmen. Das klassische Argument für das Gerüst war die gesparte Entwicklungszeit. Aus unserer Sicht verliert genau dieses Argument an Gewicht, während die Betriebskosten an Gewicht gewinnen.
Wann ein Framework die richtige Wahl ist
Wenn die Aufgabe es trägt. Bei großen Anwendungen mit viel Zustand im Browser, bei Teams, die über Jahre an derselben Oberfläche arbeiten, und überall dort, wo einheitliche Strukturen und geprüfte Sicherheitsmechanismen mehr wert sind als ein paar Kilobyte. Dafür sind Single Page Applications gebaut.
Für eine Seite, die Inhalte ausliefert, reichen dagegen oft Templates und wenig JavaScript. Den Maßstab liefern die Core Web Vitals: Sie messen, was beim Besucher ankommt, und ändern sich nicht, weil ein Repository populär ist. In unseren über 2.500 Projekten war die wirksamste Maßnahme fast immer dieselbe, nämlich weniger auszuliefern.