Die versteckten Kosten des Zusammenspiels

Da kenne ich das Gefühl nur zu gut. Man hat sich für ein Server-Framework entschieden, eine ORM, eine Validierungsbibliothek, ein Frontend, einen Build-Tool. Alles klingt auf dem Papier perfekt. Und dann merkt man: Die Validierungsbibliothek versteht nicht ganz, welches Format das ORM zurückgibt. Das Server-Side-Rendering des Frontend-Frameworks verträgt sich nicht mit dem Middleware-System des Servers. Die Session-Behandlung trifft Annahmen, die beim Deployment an den Edge komplett zusammenbrechen.

Jedes einzelne Tool für sich ist großartig. Aber die Schnittstellen dazwischen? Albtraum.

Wie es dazu kam

Die JavaScript-Welt hat schon immer Komponierbarkeit über Zusammenhalt gestellt. Das ist nicht grundsätzlich falsch – die UNIX-Philosophie hat uns jahrzehntelang gute Dienste geleistet. Das Problem ist nur: Webanwendungen sind keine Pipelines mit isolierten Datentransformationen. Sie sind verdrehte Netze aus geteilten Annahmen über Request-Formate, Validierungsgrenzen, Authentifizierungsflows, Rendering-Kontexte und Deployment-Ziele.

Als Django 2005 aufkam, hat es auf etwas gesetzt: Entwickler würden etwas Flexibilität gegen ein kohärentes System tauschen. Man konnte zwar immer noch aus dem Stack ausbrechen, wenn es nötig war. Aber innerhalb des Systems war alles darauf ausgelegt, zusammenzuarbeiten. Diese Eigenverantwortung bedeutete weniger Überraschungen.

PHP-Frameworks haben das genauso verstanden. Laravel, Symfony, Yii – sie alle vermittelten dieses "aus einem Guss"-Gefühl. Man wusste genau, was zum offiziellen Territorium gehörte und wo die Wildnis anfing.

Dann hat JavaScript den Server erobert – und wir haben das größtenteils verloren.

Die Meta-Framework-Falle

Moderne Meta-Frameworks haben einiges verbessert. Next.js, Nuxt, SvelteKit – sie haben uns wieder einen kohärenten Stack gegeben. Aber sie haben das erreicht, indem sie unsere Wahlmöglichkeiten eingeengt statt erweitert haben.

Was ich meine: Next.js ist ein tolles React-Ökosystem. Aber wenn man sich in die Performance von Solid oder die Einfachheit von Svelte verliebt, tauscht man nicht einfach die View-Layer aus. Man adoptiert ein komplett anderes Meta-Framework mit anderen Konventionen, anderen Routing-Mustern, anderen Backend-Annahmen. Man lernt die gleichen Probleme nochmal, nur mit anderer Syntax.

Das schafft eine absurde Situation. Die Frontend-Welt innoviert ständig, aber zwischen verschiedenen Ansätzen zu wechseln erfordert fast einen Neuanfang. React-Entwickler und Svelte-Entwickler lösen dieselben Backend-Probleme unabhängig voneinander, in leicht verschiedenen Varianten – für immer.

Das Runtime-Lotteriespiel

Und dann gibt es noch die Runtime-Fragmentierung. Node.js, Deno, Bun – das sind alles fähige Plattformen. Aber die meisten Frameworks sind praktisch laufzeit-spezifisch. Wenn ein Framework "Deno-Support" verspricht, bedeutet das oft nur "Deno kann unseren Node-Code ausführen." Das ist etwas völlig anderes, als wenn das Framework von Grund auf für Denos native APIs und Ausführungsmodell designt wäre.

Das ist wichtiger, als es vielleicht klingt. Die Runtime beeinflusst Performance-Eigenschaften, Deployment-Ziele und Sicherheitsmodelle. Sich in ein Framework einzuschließen, das nur auf einer einzigen Runtime wirklich funktioniert, schränkt die Möglichkeiten ein, während sich das Ökosystem weiterentwickelt.

Was wir wirklich brauchen

Die Sache ist: Webanwendungen haben natürliche Schichten, die nicht gekoppelt sein müssen.

Frontends beschreiben Browser-UI. Backends kümmern sich um Requests, Daten und Anwendungslogik. Runtimes sind Ausführungsziele. Diese Bedenken sollten sich unabhängig voneinander verändern können.

Stellt euch vor: Ihr baut eine Route mit React, weil ihr das Ökosystem an Komponenten braucht. Eine andere Route mit Svelte, weil Performance dort wichtiger ist. Eure Node.js-Routen laufen heute, aber eure TypeScript-Routen deployed ihr auf Bun, wenn ihr die Geschwindigkeit braucht. Alles in der gleichen Anwendung, mit dem gleichen Backend-Modell, der gleichen Validierung, den gleichen Sessions.

Das ist kein Wunschdenken. Das ist, Probleme als das zu behandeln, was sie sind: separate Anliegen. Und genau so wurde gute Software schon immer gebaut.

Das Framework sollte die Schnittstellen im Griff haben

Ich fordere nicht, dass ein Framework alles beherrscht. Ich fordere, dass ein Framework die Verantwortung dafür übernimmt, seine Einzelteile zusammenarbeiten zu lassen. Man sollte weiterhin aus dem offiziellen Stack ausbrechen können, wenn nötig – niemand liefert perfekte Voreinstellungen für jeden Anwendungsfall. Aber wenn man innerhalb des Frameworks bleibt, sollten die Schnittstellen das Problem des Frameworks sein, nicht das des Entwicklers.

Ein Framework, das einen zwingt, über Routing, Validierung, Datenzugriff und Rendering als separate Probleme nachzudenken, die man selbst zusammenkleben muss – das ist kein Framework. Das ist ein Vorschlag.

Die besten Frameworks geben einem Eigentum an der Business-Logik, während sie alles andere übernehmen.

Bei NameOcean haben wir gesehen, wie Hosting-Komplexität explodieren kann, wenn der Stack fragmentiert ist. Ein Framework zu wählen, das Trennung der Anliegen respektiert – das einem erlaubt, Teile auszutauschen, ohne alles neu zu schreiben – macht Deployment, Skalierung und Wartung deutlich einfacher.

Die Frage ist nicht, ob man ein Framework nutzen sollte. Die Frage ist, ob das Framework für einen arbeitet oder nur eine weitere Schicht von Entscheidungen hinzufügt, die man gar nicht treffen musste.

Was würde es bedeuten, die nächste Anwendung mit einem Tool zu bauen, das die Schnittstellen im Griff hat? Das lohnt sich, darüber nachzudenken, bevor man das nächste Projekt anlegt.