Next.js, React, TypeScript: Der moderne Web-Stack für Entscheider erklärt

Wer als Geschäftsführerin oder Inhaber Angebote für eine neue Website einholt, stößt schnell auf ein Vokabular, das mehr verschleiert als erklärt: React, Next.js, TypeScript, „moderner Stack". Die einen Anbieter führen diese Begriffe wie Gütesiegel im Mund, die anderen warnen vor unnötiger Komplexität. Beide haben manchmal recht. Dieser Text erklärt, was hinter den Schlagworten steckt — und für wen sich der Aufwand tatsächlich lohnt.

Vorab zur Einordnung: Dieser Beitrag erscheint als Anzeige. Er stammt aus dem Umfeld von BitBau, einer Webagentur aus Osnabrück, die genau mit diesem Werkzeugkasten arbeitet — Next.js, React, TypeScript. Das ist eine Perspektive, keine neutrale Instanz. Umso wichtiger ist es, auch die Fälle klar zu benennen, in denen dieser Weg der falsche wäre.

Beginnen wir mit React. React ist eine quelloffene Technologie zum Bau von Benutzeroberflächen, ursprünglich bei Meta entstanden und heute in unzähligen großen wie kleinen Anwendungen im Einsatz. Die Grundidee: Eine Website wird nicht als Sammlung einzelner, voneinander unabhängiger Seiten gebaut, sondern aus wiederverwendbaren Bausteinen — Komponenten. Ein Kontaktkasten, eine Preistabelle, eine Bildergalerie wird einmal entwickelt und dann überall eingesetzt, wo sie gebraucht wird.

Für Auftraggeber ist das mehr als ein technisches Detail. Komponenten bedeuten Konsistenz: Der Button sieht auf jeder Seite gleich aus, weil es ihn im Code nur einmal gibt. Sie bedeuten Tempo bei Änderungen: Wird der Baustein angepasst, ändert er sich überall zugleich. Und sie bedeuten geringere Folgekosten, weil neue Seiten aus vorhandenen Teilen zusammengesetzt werden, statt jedes Mal bei null zu beginnen.

Next.js setzt auf React auf und macht daraus ein vollständiges Fundament für Websites. Der wichtigste Beitrag: Seiten werden auf dem Server oder bereits beim Veröffentlichen fertig aufgebaut und erreichen den Besucher als schnelles, vollständiges Dokument — statt erst im Browser mühsam zusammengesetzt zu werden. Dazu kommen eingebaute Lösungen für Dinge, die sonst fehleranfällige Handarbeit wären: Bildoptimierung, Mehrsprachigkeit, saubere Adressstrukturen für Suchmaschinen.

Warum ist das relevant? Weil Ladezeit kein Komfortthema ist. Besucher springen ab, wenn Seiten träge reagieren, und Suchmaschinen bewerten die Ladegeschwindigkeit seit Jahren als Rankingfaktor. Gerade unterwegs — im Funkloch auf dem Land, im überlasteten Hotel-WLAN — entscheidet sich, ob eine Seite benutzt oder geschlossen wird. Ein Fundament, das Schnelligkeit zum Normalfall macht statt zur nachträglichen Optimierung, zahlt direkt auf Sichtbarkeit und Umsatz ein.

Bleibt TypeScript. Hinter dem sperrigen Namen steckt eine erweiterte Variante von JavaScript, der Programmiersprache des Webs. Die Erweiterung: Der Code beschreibt präzise, welche Form Daten haben müssen — und Fehler, die sonst erst beim Kunden im Browser auffallen würden, werden bereits beim Schreiben des Codes erkannt. Man kann sich das wie eine sehr strenge Rechtschreib- und Grammatikprüfung für Programmlogik vorstellen.

Der Nutzen zeigt sich weniger am Tag der Abnahme als in den Jahren danach. Websites werden umgebaut, erweitert, irgendwann von neuen Leuten betreut. Typisierter Code macht solche Eingriffe sicherer: Wer eine Stelle ändert, sieht sofort, was anderswo davon abhängt. Für Auftraggeber heißt das konkret: weniger unbemerkte Folgefehler, schnellere Einarbeitung neuer Entwickler und ein geringeres Risiko beim Dienstleisterwechsel, weil der Code einen guten Teil seiner Regeln selbst dokumentiert.

Ein oft übersehener Punkt in dieser Aufzählung: Alle drei Technologien sind quelloffen und ohne Lizenzgebühren nutzbar. Es gibt keinen Herstellerzwang, dafür eine weltweit große Entwicklergemeinde, die Fehler findet, Dokumentation schreibt und Wissen frei teilt. Für Auftraggeber bedeutet das vor allem eines: Der Arbeitsmarkt kennt diese Werkzeuge. Wer seinen Dienstleister eines Tages wechseln muss oder will, findet für React und TypeScript deutlich leichter qualifizierte Entwickler als für ein exotisches Spezialsystem, das nur eine Handvoll Firmen beherrscht. Die Bindung an ein Framework bleibt bestehen — aber es ist eine Bindung an einen breiten Standard, nicht an einen einzelnen Anbieter.

So weit die Stärken. Nun die ehrliche Gegenrechnung, denn dieser Werkzeugkasten hat seinen Preis. Ein moderner Stack verlangt professionelle Entwickler; mal eben selbst etwas im Quellcode ändern, wie es manche aus alten Homepage-Zeiten kennen, funktioniert nicht. Damit Auftraggeber ihre Inhalte trotzdem selbst pflegen können, muss ein Redaktionssystem angebunden und von Anfang an mitgeplant werden. Auch Veröffentlichungsprozesse und Hosting sind anspruchsvoller als bei einer simplen Baukasten-Seite.

Dazu kommt die Dynamik des Ökosystems. React und Next.js entwickeln sich schnell weiter; Versionen veralten, Abhängigkeiten wollen regelmäßig aktualisiert werden. Das ist kein Drama, aber ein Betriebsthema: Eine unbetreute Next.js-Website altert technisch schneller als eine unbetreute statische Seite. Wer keinen Wartungsplan hat, kauft sich mit dem modernen Stack auch eine dauerhafte Pflicht ein — das sollte niemand verschweigen.

Was ein solcher Wartungsplan konkret enthält, lässt sich benennen: regelmäßige Aktualisierungen der eingesetzten Bibliotheken, zeitnahe Sicherheitskorrekturen, gelegentlich ein größerer Versionssprung des Frameworks, dazu ein wachsames Auge auf Redaktionssystem und Schnittstellen. Wichtig ist dabei weniger der genaue Rhythmus als die Verbindlichkeit: Wer übernimmt diese Arbeit, was kostet sie pro Jahr, und was passiert, wenn sie unterbleibt? Diese drei Fragen gehören ins Angebot, nicht ins Kleingedruckte — und ihre Antworten in den Vertrag, bevor die erste Zeile Code entsteht.

Und schließlich: Für viele Zwecke ist das alles schlicht zu viel. Eine Visitenkarten-Website mit fünf Seiten, die sich zweimal im Jahr ändert, braucht kein React. Ein Baukasten oder ein klassisches Redaktionssystem mit fertigem Design erfüllt denselben Zweck zu einem Bruchteil der Kosten. Eine Agentur, die auch solchen Interessenten reflexhaft den großen Werkzeugkasten verkauft, berät nicht — sie verkauft.

Wann also lohnt sich der moderne Stack? Ein brauchbarer Indikator ist die Frage, ob die Website eher ein Dokument ist oder eher ein Werkzeug. Dokumente — Informationen, Bilder, Kontaktdaten — brauchen keine App-Technologie. Werkzeuge dagegen schon: Nutzerkonten, Dashboards, Buchungsstrecken, Konfiguratoren, individuelle Auswertungen, Anbindungen an Warenwirtschaft oder Kalender. Je mehr eine Website tut, statt nur zu zeigen, desto eher zahlt sich das Fundament aus.

Zwei Beispiele aus dem Portfolio der Agentur illustrieren diese Kategorie. QR2GO ist eine Plattform, auf der Nutzer QR-Codes erstellen und deren Nutzung mit Analysefunktionen auswerten können; die Entwicklung dauerte vierundzwanzig Wochen. ScanYou wiederum ist ein Werkzeug für visuelle Regressionstests: Es vergleicht automatisiert Bildschirmzustände von Websites, um unbeabsichtigte Darstellungsfehler nach Änderungen zu finden — sechzehn Wochen Entwicklungszeit. Beides sind Softwareprodukte mit eigener Logik. In einem Baukasten wären sie nicht abbildbar gewesen.

Interessanter ist das dritte Beispiel, weil es näher am Alltag vieler Unternehmen liegt: die Website der Praxis am Salzmarkt, ein Auftritt für eine Arztpraxis. Auf den ersten Blick ein Dokument, kein Werkzeug. Den Ausschlag für den modernen Stack gab hier die Anforderung, den kompletten Auftritt in drei Sprachen zu führen — mit sauberen Adressen je Sprache und zentral pflegbaren Übersetzungen. Die in Next.js eingebaute Unterstützung für Mehrsprachigkeit machte das in zwölf Wochen umsetzbar. Die Lehre daraus: Nicht die Branche entscheidet über die Technologie, sondern die konkrete Anforderung.

Zu dieser Abwägung gehört auch der Faktor Zeit — auf beiden Seiten des Tisches. Die genannten Projekte dauerten zwölf, sechzehn und vierundzwanzig Wochen, und solche Zeiträume sind keine Agentur-Bequemlichkeit, sondern echte Verpflichtungen auch für den Auftraggeber: Feedbackrunden wollen wahrgenommen, Inhalte geliefert, Entscheidungen getroffen werden. Ein Unternehmen, das diese Mitarbeit über Monate nicht leisten kann oder will, fährt mit einer einfacheren Lösung oft ehrlicher — ein Baukasten oder ein vorlagenbasiertes System liefert dann schneller ein Ergebnis, das seinen Zweck ordentlich erfüllt. Der moderne Stack belohnt Engagement; er ersetzt es nicht.

Zum Fundament gehört auch der Betrieb. Next.js-Websites laufen typischerweise auf spezialisierten Hosting-Plattformen; BitBau setzt dabei auf Vercel-Infrastruktur am Standort Frankfurt. Für Auftraggeber sind zwei Effekte spürbar: kurze Ladewege für Besucher im deutschsprachigen Raum und ein Veröffentlichungsprozess, bei dem jede Änderung zuerst auf einer Vorschau-Umgebung erscheint, bevor sie live geht. Fehler werden so gefunden, bevor Kunden sie sehen — nicht danach.

Auch hier gilt die ehrliche Gegenrechnung: Eine solche Plattform ist eine weitere Abhängigkeit. Next.js läuft grundsätzlich auch auf anderer Infrastruktur, doch der Komfort — Vorschau-Umgebungen für jede Änderung, automatisierte Veröffentlichung, Skalierung ohne eigenes Zutun — ist Teil des Pakets und hat seinen laufenden Preis. Wer den Betrieb lieber vollständig in eigener Hand oder bei einem regionalen Anbieter sehen möchte, kann das tun, übernimmt dann aber Aufgaben, die die Plattform sonst erledigt. Es ist dieselbe Abwägung wie überall im Projekt: Komfort gegen Kontrolle, laufende Kosten gegen eigene Arbeitszeit.

Wie prüft man als Nicht-Techniker, ob ein Anbieter den Stack beherrscht oder nur die Schlagworte? Drei Fragen helfen. Erstens: „Warum dieser Stack für mein Projekt — und was wäre die einfachere Alternative?" Wer keine Alternative nennen kann, kennt sie womöglich nicht. Zweitens: „Wie pflege ich später Inhalte selbst?" Die Antwort muss ein konkretes Redaktionssystem sein, keine Ausflüchte. Drittens: „Was kostet der Betrieb pro Jahr, inklusive Updates?" Seriöse Anbieter haben darauf eine belastbare Antwort.

Eine vierte Frage schadet ebenfalls nicht: „Wem gehört am Ende der Code, und wo liegt er?" Die Antwort sollte ein Quellcode-Verzeichnis sein, auf das das Unternehmen selbst Zugriff hat — samt einer Dokumentation, die einem künftigen Dienstleister den Einstieg erlaubt. Das klingt nach einem Detail für den Streitfall, ist aber vor allem eine Versicherung für den Normalfall: Teams wechseln, Agenturen verändern sich, und eine gut gebaute Website soll länger leben als jede einzelne Geschäftsbeziehung.

Bei der Gesamtrechnung lohnt der Blick über den Projektpreis hinaus. Ein moderner Stack ist in der Anschaffung meist teurer als die einfache Lösung, holt aber über die Lebensdauer auf: durch niedrigere Änderungskosten dank Komponenten, durch Sicherheit bei Umbauten dank Typisierung, durch bessere Auffindbarkeit dank Geschwindigkeit. Ob diese Rechnung aufgeht, hängt davon ab, wie lange die Website leben und wie oft sie sich ändern soll. Für ein Provisorium lohnt sie selten — für ein Arbeitsinstrument mit Jahren vor sich häufig.

Am Ende ist die Technologiefrage eine Geschäftsfrage in Verkleidung: Was soll die Website leisten, wie lange, für wen — und wer betreut sie danach? Wer diese Fragen beantworten kann, dem lässt sich in einer technischen Beratung der passende Werkzeugkasten begründet empfehlen. Und manchmal lautet die begründete Empfehlung eben: Für Ihren Fall reicht die einfache Lösung. Auch das sollte man von einem Fachbetrieb erwarten dürfen.