Server, Browser oder Inseln: was euer Projekt verlangt
Die Frage ist nicht, was moderner ist, sondern welche eurer Anforderungen sich ohne einen laufenden Server nicht erfüllen lässt und was der Betrieb dieses Servers kostet.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Ein Meta-Framework löst Probleme, die viele Projekte gar nicht haben
In Angeboten und Ausschreibungen steht Next.js inzwischen fast reflexhaft, auch bei Anwendungen, die vollständig hinter einer Anmeldung liegen und deren Inhalte niemand indexieren soll. Der Preis dafür fällt nicht am ersten Tag an, sondern im Betrieb: Es läuft ab sofort ein Server, der aktualisiert, überwacht und abgesichert werden muss, und das Team lernt ein Zwischenspeichermodell, dessen Fehlerbilder nicht offensichtlich sind.
Umgekehrt gibt es den Fall, in dem eine öffentliche Seite als reine Browseranwendung gebaut wird und dann Sichtbarkeit fehlt. Das lässt sich nachträglich reparieren, aber selten günstig, weil Datenabruf, Routing und Zustand dann bereits auf den Browser hin gebaut sind. Wer vorher prüft, welche Anforderungen einen Server verlangen, spart sich beide Richtungen.
Dazu kommt eine Kostenposition, die in der Entscheidung fast immer fehlt: Ein Meta-Framework hat einen eigenen Aktualisierungsrhythmus und eigene Sicherheitsmeldungen. Belegbare Beispiele gibt es genug, etwa die als kritisch eingestufte Umgehung der Autorisierung in der Middleware vom März 2025 oder die Sammelveröffentlichung vom 22. Juli 2026 mit neun Meldungen zu Server Actions, Rewrites und Bildauslieferung. Das ist kein Argument gegen das Werkzeug, aber eines dafür, die Zeit für das Nachziehen einzuplanen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Drei Wege an fünf Entscheidungsfragen
Die Bewertungen beziehen sich auf den jeweiligen Normalfall: eine React-Anwendung, die mit Vite gebaut und als statische Dateien ausgeliefert wird, Next.js im App Router und Astro mit einzelnen interaktiven Inseln.
React-App im Browser
mit Vite gebaut, als statische Dateien ausgeliefert, Routing und Daten im Browser
Next.js
Rendern auf dem Server, Server Components, eigene Zwischenspeicherlogik, laufender Prozess
Astro
inhaltsorientiert, liefert HTML aus und belebt nur einzelne Inseln mit JavaScript
| Entscheidungsfrage | React-App im Browser | Next.js | Astro |
|---|---|---|---|
| Stehen die Inhalte im ausgelieferten HTML? | Schwäche Ausgeliefert wird ein leeres Gerüst, der Inhalt entsteht erst durch JavaScript. Für Vorschaubilder in Messengern und sozialen Netzen reicht das in der Regel nicht. | Stärke Seiten werden auf dem Server gerendert oder vorgebaut, Inhalt und Metadaten stehen im HTML, bevor JavaScript läuft. | Stärke Liefert HTML aus und schickt für nicht interaktive Bereiche gar kein JavaScript mit, was die Frage von vornherein erledigt. |
| Wo liegen Zugangsdaten für fremde Dienste? | Schwäche Alles, was die Anwendung kennt, kann jemand auslesen. Für geheime Schlüssel braucht es zusätzlich ein eigenes Backend, das ihr dann ebenfalls betreibt. | Stärke Datenabruf und Aktionen laufen auf dem Server, Schlüssel bleiben dort. Genau dieser Punkt spart in vielen Projekten ein separates Backend. | Stärke Serverseitiger Code und Aktionen sind vorgesehen, sobald ein Adapter eingerichtet ist. Für rein statische Seiten stellt sich die Frage gar nicht. |
| Was muss betrieben und aktualisiert werden? | Stärke Statische Dateien auf einem CDN. Kein Prozess, der abstürzen kann, keine Laufzeitversion, die gepflegt werden muss. | Schwäche Ein laufender Prozess mit einer Mindestversion von Node, eigenem Aktualisierungsrhythmus und eigenen Sicherheitsmeldungen. Das ist planbarer Aufwand, aber es ist Aufwand. | Kommt darauf an Rein statisch betrieben so günstig wie eine Browseranwendung. Mit Adapter für serverseitiges Rendern kommt derselbe Betriebsaufwand dazu wie bei Next.js. |
| Wie hoch ist der Anteil an Interaktion je Seite? | Stärke Der Normalfall für Anwendungen hinter einem Login: viele Zustände, Tabellen, Dialoge, kaum Seitenwechsel im klassischen Sinn. | Stärke Deckt beide Enden ab, von der öffentlichen Seite bis zur Anwendung, verlangt dafür aber eine Entscheidung je Bereich, was auf dem Server und was im Browser läuft. | Kommt darauf an Stark bei viel Inhalt und wenigen interaktiven Stellen. Für eine durchgehend interaktive Anwendung ist der Inselansatz die falsche Bauform. |
| Wie viel Rahmenwissen bindet ihr euch ans Bein? | Stärke React, ein Router und eine Bibliothek für Serverdaten. Wer React kann, ist damit in Tagen produktiv. | Schwäche Dazu kommen Server Components, das Zwischenspeichermodell mit Cache Components, die Trennung von Server- und Browsercode und Umbauten wie asynchrone Routenparameter oder die Umbenennung von middleware zu proxy. | Kommt darauf an Eigene Seitensyntax, Inhaltssammlungen und die Frage, wann eine Insel wirklich JavaScript bekommt. Überschaubar, aber es ist ein zweites Modell neben React. |
Stehen die Inhalte im ausgelieferten HTML?
Ausgeliefert wird ein leeres Gerüst, der Inhalt entsteht erst durch JavaScript. Für Vorschaubilder in Messengern und sozialen Netzen reicht das in der Regel nicht.
Seiten werden auf dem Server gerendert oder vorgebaut, Inhalt und Metadaten stehen im HTML, bevor JavaScript läuft.
Liefert HTML aus und schickt für nicht interaktive Bereiche gar kein JavaScript mit, was die Frage von vornherein erledigt.
Wo liegen Zugangsdaten für fremde Dienste?
Alles, was die Anwendung kennt, kann jemand auslesen. Für geheime Schlüssel braucht es zusätzlich ein eigenes Backend, das ihr dann ebenfalls betreibt.
Datenabruf und Aktionen laufen auf dem Server, Schlüssel bleiben dort. Genau dieser Punkt spart in vielen Projekten ein separates Backend.
Serverseitiger Code und Aktionen sind vorgesehen, sobald ein Adapter eingerichtet ist. Für rein statische Seiten stellt sich die Frage gar nicht.
Was muss betrieben und aktualisiert werden?
Statische Dateien auf einem CDN. Kein Prozess, der abstürzen kann, keine Laufzeitversion, die gepflegt werden muss.
Ein laufender Prozess mit einer Mindestversion von Node, eigenem Aktualisierungsrhythmus und eigenen Sicherheitsmeldungen. Das ist planbarer Aufwand, aber es ist Aufwand.
Rein statisch betrieben so günstig wie eine Browseranwendung. Mit Adapter für serverseitiges Rendern kommt derselbe Betriebsaufwand dazu wie bei Next.js.
Wie hoch ist der Anteil an Interaktion je Seite?
Der Normalfall für Anwendungen hinter einem Login: viele Zustände, Tabellen, Dialoge, kaum Seitenwechsel im klassischen Sinn.
Deckt beide Enden ab, von der öffentlichen Seite bis zur Anwendung, verlangt dafür aber eine Entscheidung je Bereich, was auf dem Server und was im Browser läuft.
Stark bei viel Inhalt und wenigen interaktiven Stellen. Für eine durchgehend interaktive Anwendung ist der Inselansatz die falsche Bauform.
Wie viel Rahmenwissen bindet ihr euch ans Bein?
React, ein Router und eine Bibliothek für Serverdaten. Wer React kann, ist damit in Tagen produktiv.
Dazu kommen Server Components, das Zwischenspeichermodell mit Cache Components, die Trennung von Server- und Browsercode und Umbauten wie asynchrone Routenparameter oder die Umbenennung von middleware zu proxy.
Eigene Seitensyntax, Inhaltssammlungen und die Frage, wann eine Insel wirklich JavaScript bekommt. Überschaubar, aber es ist ein zweites Modell neben React.
Was passt wann
- Wenn die Anwendung hinter einer Anmeldung liegt und niemand ihre Inhalte finden können soll
- reicht eine React-App mit Vite und einem Router, ausgeliefert als statische Dateien.
- Wenn öffentliche Inhalte, geheime Schlüssel und Formulare in einem Projekt zusammenkommen
- ist Next.js die passende Wahl, dann aber mit eingeplanter Zeit für das Zwischenspeichermodell.
- Wenn die Seite überwiegend aus Inhalt besteht und nur einzelne Stellen interaktiv sind
- nimm Astro und heb React für genau diese Inseln auf.
Vier Anforderungen, die einen Server verlangen
- 01 Inhalte müssen im ausgelieferten HTML stehen, für Suche und Vorschaubilder.
- 02 Ein geheimer Schlüssel darf den Server nicht verlassen.
- 03 Die Antwort hängt von der Anfrage ab, etwa von Rolle, Region oder Uhrzeit.
- 04 Zwischenspeicher, Bilder und Weiterleitungen brauchen eine eigene Logik.
- 05 Trifft nichts davon zu, reicht eine Anwendung im Browser auf einem CDN.
Was ihr nach dieser Prüfung entscheiden könnt
Die Entscheidung fällt nicht am Framework, sondern an vier Anforderungen. Wenn keine davon zutrifft, gibt es keinen Grund für einen Server, und wenn eine zutrifft, ist die Frage nur noch, welcher der drei Wege am wenigsten Ballast mitbringt.
Sichtbarkeit prüfen, nicht behaupten
Sieh dir den ausgelieferten Quelltext an. Steht der Inhalt darin, ist alles in Ordnung. Steht dort nur ein leeres Gerüst, verlasst ihr euch darauf, dass jede Gegenstelle JavaScript ausführt, und das tun längst nicht alle.
Zugangsdaten verorten
Alles, was im Browser läuft, ist einsehbar. Sobald ein fremder Dienst einen geheimen Schlüssel verlangt, braucht ihr eine Stelle auf dem Server, entweder im Meta-Framework oder als eigenes Backend.
Den Zeitpunkt der Daten festlegen
Entstehen die Inhalte beim Bauen, bei der Anfrage oder erst nach einer Bedienung? Nur der mittlere Fall verlangt zwingend einen Server, die anderen beiden lassen sich anders lösen.
Den Betrieb mitrechnen
Statische Dateien liegen auf einem CDN und kosten fast nichts. Ein laufender Server bringt Node-Versionen, Sicherheitsaktualisierungen, Überwachung und Zwischenspeicherfragen mit. Beides ist vertretbar, aber nur eines davon ist umsonst.
Den Anteil an Interaktion einschätzen
Eine Anwendung mit Tabellen, Formularen und Dialogen ist etwas anderes als eine Seite mit Texten und einzelnen dynamischen Stellen. Für den zweiten Fall ist ein Inselansatz sparsamer als eine vollständige Anwendung.
Den späteren Wechsel offenhalten
Haltet Datenabruf und Routing so, dass sie sich ersetzen lassen. Dann bleibt der Weg von einer Browseranwendung zu einem Meta-Framework ein Umbau in Etappen und kein Neuschrieb.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die vier Anforderungen, die wirklich einen Server verlangen
Die erste ist Sichtbarkeit. Wenn Inhalte in Suchmaschinen erscheinen sollen oder wenn beim Teilen eines Links ein Vorschaubild mit Titel und Beschreibung entstehen muss, braucht es fertiges HTML. Suchmaschinen führen JavaScript zwar aus, viele andere Gegenstellen tun das nicht, und das betrifft genau die Vorschaubilder in Messengern und sozialen Netzen.
Die zweite sind Geheimnisse. Ein Schlüssel für einen Zahlungsdienst, ein Zugang zu einem CRM oder ein Verbindungsstring zur Datenbank haben im Browser nichts verloren. Entweder es gibt ein Backend, das diese Aufrufe übernimmt, oder das Meta-Framework tut es. Die dritte ist der Zeitpunkt: Hängt das Ergebnis von der Anfrage ab, also von Rolle, Region, Uhrzeit oder Sprache, muss es zur Anfragezeit entstehen.
Die vierte ist Auslieferungslogik: Weiterleitungen und Zugriffsprüfungen vor dem Rendern, Bildumwandlung in mehreren Größen, feingranulare Zwischenspeicherung mit gezielter Ungültigkeitserklärung. Das lässt sich alles nachbauen, aber ab einer gewissen Menge ist ein Rahmen, der es mitbringt, günstiger als der Eigenbau. Trifft keine der vier Anforderungen zu, bringt ein Server nichts, was ihr braucht.
Was ihr euch mit Next.js einkauft
Next.js 16 ist im Oktober 2025 erschienen und hat einiges bewegt: Turbopack ist stabil und der voreingestellte Bündler, die Unterstützung für den React Compiler ist stabil, aber ausdrücklich einzuschalten, und mit Cache Components gibt es ein Modell, in dem Zwischenspeicherung freiwillig über eine Anweisung im Code erfolgt, statt implizit zu passieren. Dazu kommen Umbauten, die bei einem Wechsel Arbeit machen: Routenparameter werden asynchron gelesen, middleware heißt jetzt proxy, und Node 20.9 ist die Mindestversion.
Der Gewinn im Alltag liegt weniger im Rendern als in der Nähe zum Server. Datenabruf ohne eigenes Backend, Aktionen, die direkt aus einem Formular heraus etwas auf dem Server ändern, Bildumwandlung und eine Zwischenspeicherung, die sich nach einer Änderung gezielt für einzelne Bereiche aufheben lässt. Für Seiten mit öffentlichen Inhalten und angemeldeten Bereichen in einer Anwendung ist das ein echter Unterschied.
Der Aufwand steckt in zwei Bereichen. Erstens im Modell selbst: Welche Komponente läuft auf dem Server, welche im Browser, was darf über diese Grenze gereicht werden, welcher Teil ist zwischengespeichert. Zweitens im Betrieb: ein laufender Prozess, ein Aktualisierungsrhythmus mit gelegentlichen Sicherheitsmeldungen, und die Frage, wo das Ganze läuft. Rechnet mit einigen Tagen Einarbeitung je Person, nicht mit Stunden.
Was eine reine Browseranwendung weiterhin gut kann
Create React App ist im Februar 2025 abgekündigt worden. Empfohlen wird seitdem entweder ein Meta-Framework oder ein Bauwerkzeug wie Vite, Parcel oder Rsbuild. Wichtig ist die Lesart: Abgekündigt wurde das alte Startwerkzeug, nicht die Bauform. Eine mit Vite gebaute React-Anwendung mit React Router ist ein aktueller, gut unterstützter Weg.
Der Betrieb ist der eigentliche Vorteil. Die Ausgabe besteht aus statischen Dateien, die auf jedem CDN liegen können. Es gibt keinen Prozess, der neu gestartet werden muss, keine Laufzeitversion, die veraltet, und keine serverseitigen Zwischenspeicherfehler. Für interne Werkzeuge, Verwaltungsoberflächen und alles hinter einer Anmeldung ist das die sparsamste Bauform.
Zwei Punkte solltet ihr trotzdem regeln. Erstens die Aufteilung des Codes nach Routen, damit die erste Auslieferung nicht die ganze Anwendung enthält. Zweitens die Frage nach einzelnen öffentlichen Seiten, etwa der Startseite oder rechtlichen Hinweisen. Die lassen sich getrennt vorbauen, ohne dass die ganze Anwendung auf einen Server umziehen muss.
Astro als dritter Weg
Astro dreht die Voreinstellung um: Eine Seite besteht aus HTML, und JavaScript kommt nur dorthin, wo ihr ausdrücklich eine Insel setzt. Diese Inseln dürfen React-Komponenten sein, ihr müsst also nichts neu lernen, um einen bestehenden Kalender oder eine Suche einzubinden. Für Dokumentation, Wissensbereiche, Blogs und Produktseiten ist das die sparsamste Bauform, weil der Großteil der Seite ohne Laufzeitkosten auskommt.
Die Grenze ist erreicht, wenn fast jede Stelle interaktiv ist und Zustände über Seitengrenzen hinweg erhalten bleiben sollen. Dann arbeitet ihr gegen das Modell, und eine Anwendung im Browser oder ein Meta-Framework ist ehrlicher. Ein häufiger und gut funktionierender Zuschnitt ist deshalb die Trennung: die öffentliche Seite in Astro, die Anwendung dahinter als eigene React-Anwendung.
Beim Betrieb gilt dieselbe Rechnung wie oben: Rein statisch ist Astro so günstig wie jede Dateiauslieferung. Sobald ihr serverseitiges Rendern oder Formularverarbeitung braucht, kommt ein Adapter und damit ein laufender Prozess dazu, und der Unterschied zu Next.js schrumpft auf die Frage, welches Modell euch besser liegt.
Die Kosten, die man erst im zweiten Jahr merkt
Der häufigste Fehler in der Rechnung ist die Annahme, die Entscheidung sei einmalig. Sie ist es nicht: Jedes Werkzeug bringt einen Rhythmus mit, in dem Hauptversionen erscheinen und Sicherheitslücken geschlossen werden. Bei einer Anwendung, die nur aus statischen Dateien besteht, betrifft euch das im Wesentlichen über die Abhängigkeiten. Bei einem laufenden Server betrifft es zusätzlich die Laufzeitumgebung und die Umgebung, in der sie läuft.
Der zweithäufigste Fehler ist, die Fehlersuche zu unterschätzen. Ein Zwischenspeicherproblem auf dem Server sieht im Browser aus wie veraltete Daten und im Protokoll wie ein erfolgreicher Abruf. Wer serverseitiges Rendern einsetzt, braucht im Team mindestens zwei Personen, die den Weg einer Anfrage durch Zwischenspeicher, Rendern und Hydratation nachvollziehen können. Diese Fähigkeit gehört in die Planung, nicht in die Hoffnung.
Gut ist, dass die Wege nicht getrennt bleiben müssen. Eine bestehende React-Anwendung lässt sich schrittweise unter ein Meta-Framework schieben, indem zunächst nur die öffentlichen Bereiche umziehen und der angemeldete Teil unverändert weiterläuft. Wer das von Anfang an offenhalten will, hält den Datenabruf in einer eigenen Schicht und vermeidet es, Routing-Eigenheiten quer durch die Komponenten zu verteilen.
Dazu passende Kurse
Wer diese Abwägung am eigenen Projekt durchgehen will, klärt bei cmt mit erfahrenen Leuten, wann ein Meta-Framework den Aufwand wert ist .
Wer die Bauformen im Web insgesamt sortieren möchte, findet bei cmt Angebote zu Rendern, Routing und Auslieferung im Zusammenhang .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Der passende Lernpfad
Wenn du nicht nur ein Thema abhaken, sondern eine Rolle ausfüllen willst, zeigt dir der Lernpfad die Kurse in der Reihenfolge, in der sie aufeinander aufbauen.
Dein Weg zum React Entwickler
Moderne Web-Produkte werden heute mit React gebaut. Wer es sauber beherrscht, arbeitet an echten Web-Anwendungen – nicht an Spielwiesen.
Dieser Karrierepfad führt dich gezielt von den Grundlagen über Architektur und Design bis hin zu professionellen React-Frontends, wie sie in produktiven Teams erwartet werden. Starte einfach durch!
Die Grundlagen
Einstieg in React
Wo du genau das übst
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Die Schulung ist gerade für Einsteiger oder Entwickler*innen mit eingestaubtem Basiswissen sehr hilfreich.
Ich bin sehr glücklich Franz als Trainer gehabt zu haben. Er hat offensichtlich unglaublich viel Wissen zu den Themen, und schafft es, dieses auch interaktiv und verständlich weiterzugeben.
Häufige Fragen
Finden Suchmaschinen eine reine React-Anwendung wirklich nicht?
Können wir Next.js ohne Server betreiben?
Was ist mit Create React App?
Wir sind unsicher. Womit fangen wir an?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Webentwicklung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Bauform vor dem ersten Commit klären
Bei cmt lässt sich beides nebeneinander ansehen, die reine Anwendung im Browser und das Rendern auf dem Server, samt der Frage, was der Umzug einer bestehenden Anwendung kostet.