Das leere HTML-Problem

Klick mal rechts auf einer großen Website und schau dir den Quellcode an. Was siehst du? Meistens nur ein kahler Rahmen. Ein paar Meta-Tags, ein Link zu CSS und dann dieser eine Div:

<div id="app"></div>

Nichts weiter. Der echte Inhalt – Texte, Bilder, Struktur – kommt später. JavaScript-Bundles laden Daten nach, die der Browser dann ausführt. So funktioniert das heute.

Früher war das anders. Wer das kapiert, baut bessere Web-Apps. Vor allem, wenn Performance, Barrierefreiheit oder SEO zählen.

Früher: Das Web als Dokument

Am Anfang holte der Browser eine fertige Seite vom Server. Alles, was du sahst, stand im HTML. Du konntest es prüfen, verstehen, kopieren.

Das war kein Nachteil, sondern genial. Ein Datum in einem Artikel hatte Kontext durch den umliegenden Text. Ein Link beschrieb, wohin er führt. Die Seite war eigenständig und lesbar.

Quelltext anzeigen war mehr als Debug-Tool. Es garantierte Klarheit.

Später kamen Server-Sprachen wie PHP oder CGI. HTML entstand dynamisch aus Datenbanken. Aber der User bekam immer eine komplette Seite. Entwicklungsteile wie Templates und Logik verschmolzen davor.

Die Seite blieb die zentrale Einheit.

Der Wendepunkt: AJAX verändert alles

Dann kam XMLHttpRequest. Browser konnten Daten ohne Neuladen holen. Teile der Seite aktualisierten sich allein. Mitte der 2000er hieß das AJAX. Google Maps zeigte, was möglich ist: flüssig, interaktiv, wie eine Desktop-App.

Der Grund war klar. Warum die ganze Seite neu laden, um einen Button zu ändern? AJAX brachte echten Fortschritt. Nutzer wollten das, Entwickler konnten es bauen.

Doch es gab einen Preis.

Der große Kompromiss

Anfang der 2010er festigte sich ein neuer Ansatz:

1. Minimales HTML als Hülle schicken.
2. JavaScript-App laden.
3. Daten per API holen.
4. Inhalt zur Laufzeit einfügen.

Frameworks wie React, Angular oder Vue machten das möglich. Sie lösten echte Probleme: Komplexe Zustände, wiederverwendbare Bausteine, große Teams. Ohne sie wären manche Apps unmöglich.

Aber sie drehten das Web-Prinzip um.

Was wir verloren haben – und warum es stört

Seiten sind nicht mehr direkt lesbar.

Der HTML-Code spiegelt nicht wider, was Nutzer sehen. Daten, Inhalt, Bedienung – alles fehlt im Quelltext. Dieser leere <div id="app"></div> wartet auf JavaScript.

Entwickler müssen Logik nachverfolgen, APIs debuggen, Zustände simulieren. Keine einfache Transparenz mehr.

Maschinen leiden noch mehr. Suchmaschinen für SEO, KI-Tools oder Screenreader müssen JavaScript ausführen. Sie tracken Klicks, Zustände und Effekte, um den Inhalt zu kapieren. Das frisst Ressourcen. Statt HTML zu parsen, braucht's Headless-Browser.

Ein Symptom tieferer Veränderung

Es geht nicht nur um JS oder Frameworks. Sondern um Denken:

Altes Modell: Seite = Dokument mit Sinn im Markup.
Neues Modell: Seite = Behälter für eine App, Sinn woanders.

Dokumente erklären sich selbst. Apps brauchen Ausführung. Wir gewannen Interaktivität, verloren Lesbarkeit.

Für Tools wie Figma oder Chat-Apps lohnt sich das. Aber der Trend gilt überall. Selbst einfache Blogs werden zu Single-Page-Apps. Zu weit geschwungen.

Was das für NameOcean-Kunden bedeutet

Bei NameOcean geht's um passende Domains und Hosting. Dein Setup sollte deine Architektur unterstützen – nicht Komplexität erzwingen.

Für Content-Seiten, Landing Pages oder Texte: Server-Side Rendering (SSR) oder Static Generation sind top. HTML trägt den Sinn. Suchmaschinen greifen sofort zu. Nutzer mit langsamer Leitung sehen Inhalt direkt.

Für interaktive Dinger wie Dashboards oder Echtzeit-Tools: Client-seitig ist okay. Aber wäge ab.

Wichtig: Verstehe deinen Grund, nicht blind Trends folgen.

Blick nach vorn

Die Zukunft bringt Ausgleich. Frameworks mischen jetzt: SSR für den Start, Client-Reaktivität danach, Static für Feste.

Next.js, Svelte oder Astro zeigen: Dokument und App passen zusammen. Kein Entweder-Oder.

Sei bewusst. Wähle nach Bedarf, nicht Gewohnheit. Baue lesbar, indexierbar, zugänglich – und interaktiv.

Das Web rockt, wenn Transparenz und Power Hand in Hand gehen.