Von der statischen Seite zur lebenden Architektur

Die erste Webseite der Welt hatte keine Navigation. Keine Datenbank. Kein State. Sie hatte einen Link - und die Kühnheit zu sagen: Hier ist noch mehr.

Das war 1991. Tim Berners-Lee schrieb HTML wie man einen Brief schreibt. Einmal. Für alle. Unveränderlich. Die Seite wusste nicht, wer du warst. Sie wusste nicht, wann du kamst. Sie wartete einfach - wie ein Schild an einer Tür.

Dreißig Jahre später öffnet sich diese Tür, bevor du anklopfst.

Das Problem der Wiederholung

Irgendwann - irgendwo zwischen der fünfzigsten kopierten Navigation und dem hundertsten identischen Footer - begann ein Entwickler zu fragen: Muss das wirklich so sein?

DRY. Don't Repeat Yourself. Drei Buchstaben, die eine ganze Philosophie tragen. Nicht weil Wiederholung faul ist - sondern weil sie gefährlich ist. Weil sie bedeutet: Wenn sich etwas ändert, muss es sich überall ändern. Und irgendwo wird man es vergessen.

Komponenten waren die Antwort. Nicht als technisches Konstrukt - sondern als Denkweise. Die Idee, dass ein Button ein Button ist. Überall. Immer. Und wenn der Button sich verändert, verändert er sich nur an einem Ort - und die Welt folgt.

React hat diesen Gedanken nicht erfunden. Aber es hat ihn demokratisiert. Es hat ihn in die Hände von Entwicklern gegeben, die keine Facebook-Ingenieure waren - und gesagt: Denk so. Bau so. Leb so.

State - das Gedächtnis der Seite

Eine statische Seite erinnert sich an nichts.

Sie kennt dich nicht. Sie weiß nicht, ob du eingeloggt bist, was in deinem Warenkorb liegt, oder ob du gerade zum dritten Mal denselben Fehler gemacht hast. Sie ist höflich gleichgültig.

State Management war die Antwort auf eine fundamentale Frage: Wie gibt man einer Seite ein Gedächtnis? Zuerst lokal - ein bisschen JavaScript, eine Variable hier, ein Event dort. Dann global - Redux, Context, Zustand. Strukturen, die sicherstellen, dass die Wahrheit einer Anwendung an einem Ort lebt. Nicht in fünf Komponenten gleichzeitig, jede mit ihrer eigenen Version der Realität.

Das ist kein technisches Problem. Das ist ein philosophisches: Wer kennt die Wahrheit? Und wer darf sie verändern?

Rendering - wann entsteht was?

Die nächste große Frage war nicht was gebaut wird - sondern wann und wo.

Client-Side Rendering: Der Browser lädt eine leere Seite und baut sie selbst zusammen. Flexibel. Lebendig. Aber langsam beim ersten Laden - und unsichtbar für Suchmaschinen, die nicht warten wollen.

Server-Side Rendering: Der Server denkt nach, bevor er antwortet. Die Seite kommt fertig an. Schnell. Sichtbar. Aber teuer - jeder Request, ein neuer Gedanke.

Static Site Generation: Alles wird vorher gebaut. Beim Deployment. Die Seite ist fertig, bevor jemand fragt. Blitzschnell - aber unflexibel, wenn sich Daten ändern.

Next.js sagte: Warum wählen? App Router, Server Components, ISR - ein Framework, das versteht, dass verschiedene Teile einer Anwendung verschiedene Antworten brauchen. Diese Seite statisch. Jene dynamisch. Diese Komponente auf dem Server. Jene beim Client. Architektur als Entscheidung, nicht als Schicksal.

Die Datenbank - das Fundament unter allem

Alle Eleganz der Oberfläche ruht auf etwas Schweigendem darunter.

Die frühen Datenbanken waren monolithisch. Ein großer Server. Eine große Wahrheit. Alles an einem Ort - was Stärke war, und Schwäche zugleich. Skalierbarkeit bedeutete: größerer Server kaufen. Das nennt man heute vertical scaling - und es hat natürliche Grenzen.

Dann kam das Umdenken. Horizontal scaling. Nicht ein größeres Schiff - sondern mehr Schiffe. Daten verteilt, repliziert, synchronisiert. NoSQL-Datenbanken wie MongoDB befreiten die Struktur - kein starres Schema mehr, Dokumente statt Tabellen, Flexibilität statt Strenge.

Und heute? Supabase ist in gewissem Sinne die Synthese. PostgreSQL - bewährt, relational, mächtig - kombiniert mit einer modernen API, Realtime-Subscriptions, Row-Level Security. Eine Datenbank, die weiß, wer du bist, was du sehen darfst, und dir in Echtzeit Bescheid gibt, wenn sich etwas ändert.

Das ist nicht nur Infrastruktur. Das ist Intelligenz, die tiefer liegt als der Code.

Cloud - die Infrastruktur wird unsichtbar

Es gab eine Zeit, in der "Deployment" bedeutete: einen physischen Server kaufen, ihn in einem Rechenzentrum aufstellen, und beten, dass er nicht ausfällt.

Heute drückt man auf einen Knopf.

Vercel, AWS, Google Cloud, Cloudflare - diese Namen repräsentieren eine fundamentale Verschiebung: Infrastruktur als Service. Edge Functions, die weltweit verteilt laufen - näher am Nutzer, schneller in der Antwort. Serverless Functions, die nur dann Kosten verursachen, wenn sie gebraucht werden. Auto-Scaling, das auf Traffic-Spitzen reagiert, bevor man sie bemerkt.

Die Cloud hat dem Entwickler etwas Kostbares zurückgegeben: Aufmerksamkeit. Nicht für Server - für Ideen.

Was das alles bedeutet

Web-Entwicklung ist heute kein einzelnes Handwerk mehr. Es ist ein Ökosystem aus Entscheidungen.

Wie wird gerendert? Wo leben die Daten? Wer kennt den State? Wie skaliert die Architektur, wenn aus hundert Nutzern zehntausend werden? Wie bleibt der Code lesbar, wenn das Team wächst? Wie bleibt die Anwendung schnell, wenn die Features es nicht mehr sind?

Diese Fragen haben keine universellen Antworten. Aber sie haben Prinzipien. Und diese Prinzipien - DRY, Komponentendenken, klare Datenschichten, bewusstes Rendering, skalierbare Infrastruktur - sind das eigentliche Handwerk.

Die Technologien werden sich ändern. Next.js wird irgendwann durch etwas ersetzt, das wir noch nicht kennen. Supabase wird wachsen, sich wandeln, vielleicht verschwinden.

Aber wer versteht, warum diese Dinge existieren - wer die Fragen kennt, auf die sie Antworten sind - der ist nicht abhängig von einem Tool.

Der denkt in Systemen. Und das verlernt man nicht.