Webentwicklung im Wandel: Von HTML-Tabellen zu modernen Frameworks

Wer heute eine Webseite baut, hat die Wahl zwischen Dutzenden von Frameworks, Build-Tools und Deployment-Strategien. Das war nicht immer so. Vor zwanzig Jahren bestand eine typische Webseite aus ein paar HTML-Dateien, einer CSS-Datei und vielleicht ein bisschen JavaScript für ein Dropdown-Menu. Der Weg von dort bis hierher ist länger, als man denkt.

Die Anfänge: HTML-Tabellen und Framesets

In den frühen 2000er Jahren war Webdesign ein Handwerk, das vor allem Geduld erforderte. Layouts wurden mit verschachtelten <table>-Elementen gebaut. Wer ein dreispaltiges Layout wollte, brauchte eine Tabelle mit drei Zellen. Wer Abstände wollte, verwendete transparente GIF-Bilder als Platzhalter. Das klingt heute absurd, war aber gängige Praxis.

Framesets waren die andere große Sache. Eine Webseite bestand aus mehreren HTML-Dateien, die in einem Frameset zusammengefügt wurden. Die Navigation links, der Inhalt rechts, die Kopfzeile oben. Jeder Bereich lud seine eigene HTML-Datei. Das Problem: Suchmaschinen konnten Framesets nicht vernünftig indexieren, Links zeigten oft auf einzelne Frames statt auf die Gesamtseite, und auf mobilen Geräten (die es damals kaum gab) war das Ganze unbenutzbar.

CSS existierte zwar schon, wurde aber von den Browsern so unterschiedlich interpretiert, dass viele Entwickler es vermieden. Internet Explorer 6 hatte eine völlig eigene Vorstellung davon, wie das Box-Modell funktioniert. Wer eine Webseite baute, baute sie eigentlich dreimal: einmal für IE, einmal für Firefox, einmal für alle anderen.

<table width="800" cellpadding="0" cellspacing="0">
  <tr>
    <td colspan="3" bgcolor="#003366">
      <img src="header.gif" />
    </td>
  </tr>
  <tr>
    <td width="150" valign="top" bgcolor="#f0f0f0">
      <!-- Navigation -->
    </td>
    <td width="10">
      <img src="spacer.gif" width="10" />
    </td>
    <td valign="top">
      <!-- Inhalt -->
    </td>
  </tr>
</table>

Wer heute diesen Code sieht, versteht sofort, warum die Branche dringend etwas Besseres brauchte. Aber damals war das der Standard. Und die Seiten haben funktioniert. Nur eben nicht besonders gut.

Die jQuery-Revolution (2006-2015)

Als John Resig 2006 jQuery veröffentlichte, änderte sich die Webentwicklung grundlegend. Plötzlich konnte man DOM-Elemente mit einer einzigen Zeile selektieren und manipulieren. Die Unterschiede zwischen Browsern? jQuery glättete sie. AJAX-Anfragen, die vorher Dutzende Zeilen Code erforderten? Eine Zeile. Animationen? Zwei Zeilen.

// Vorher: reines JavaScript
var elements = document.getElementsByClassName('menu-item');
for (var i = 0; i < elements.length; i++) {
  elements[i].style.display = 'none';
}

// Nachher: jQuery
$('.menu-item').hide();

jQuery demokratisierte die Webentwicklung. Man musste kein Experte mehr sein, um interaktive Webseiten zu bauen. Slider, Lightboxes, Tabs, Akkordeons: Für alles gab es ein jQuery-Plugin. Die Qualität dieser Plugins variierte stark, aber sie funktionierten. Und das war mehr, als man von den nativen Browser-APIs sagen konnte.

Parallel dazu wurde CSS immer mächtiger. CSS3 brachte Schatten, Rundungen, Verläufe und Animationen. Media Queries ermöglichten responsive Designs. Frameworks wie Bootstrap (2011) und Foundation machten es einfach, Layouts zu bauen, die auf verschiedenen Bildschirmgrößen funktionierten. Das war der Anfang vom Ende der Tabellen-Layouts.

Aber jQuery hatte auch Grenzen. Größere Anwendungen wurden schnell unübersichtlich. Der Code war oft prozedural, schwer testbar und eng an die DOM-Struktur gekoppelt. Wenn sich das HTML änderte, brach der JavaScript-Code. Das war für einfache Webseiten kein Problem, aber für Web-Anwendungen wurde es zum Flaschenhals.

Single Page Applications und der Framework-Boom

2010 kam AngularJS, 2013 React, 2014 Vue.js. Die Idee war radikal: Statt einzelne Seiten vom Server zu laden, wird die gesamte Anwendung im Browser ausgeführt. Der Server liefert nur noch Daten über APIs. Die Benutzer-Oberfläche wird komplett in JavaScript gerendert.

Single Page Applications (SPAs) fühlten sich schneller an, weil Seitenwechsel ohne Neuladen funktionierten. Komponentenbasierte Architektur machte den Code modularer und wiederverwendbar. State Management sorgte dafür, dass Daten konsistent blieben, egal wie komplex die Anwendung wurde.

<template>
  <div class="product-card">
    <h3>{{ product.name }}</h3>
    <p>{{ product.price }} EUR</p>
    <button @click="addToCart">In den Warenkorb</button>
  </div>
</template>

<script setup>
const props = defineProps(['product'])
const emit = defineEmits(['add'])

function addToCart() {
  emit('add', props.product.id)
}
</script>

Der Nachteil: Die initiale Ladezeit war hoch, weil der Browser erst das gesamte JavaScript laden und ausführen musste, bevor überhaupt etwas angezeigt wurde. SEO war ein Problem, weil Suchmaschinen-Crawler das JavaScript nicht immer ausführten. Und die Komplexität des Toolings explodierte: Webpack, Babel, ESLint, Prettier, TypeScript, Zustandsmanagement, Routing. Ein neues Projekt einzurichten, dauerte länger als früher das gesamte Projekt.

Server-Side Rendering kommt zurück (Nuxt, Next.js)

Die Branche erkannte relativ schnell, dass reine SPAs nicht für alles die richtige Lösung sind. Next.js (für React) und Nuxt (für Vue.js) brachten Server-Side Rendering (SSR) zurück: Die erste Seite wird auf dem Server gerendert und als fertiges HTML ausgeliefert. Der Browser zeigt sofort Inhalt an. Danach übernimmt JavaScript und die Seite verhält sich wie eine SPA.

Das Ergebnis: schnelle initiale Ladezeiten, gute SEO, trotzdem eine flüssige Benutzererfahrung nach dem ersten Laden. Dazu kamen Static Site Generation (SSG), bei der Seiten beim Build-Prozess vorgerendert werden, und Incremental Static Regeneration (ISR), bei der statische Seiten im Hintergrund aktualisiert werden.

Die aktuelle Generation von Frameworks geht noch weiter. Server Components (React), Hybrid Rendering (Nuxt 3/4) und Edge Computing ermöglichen es, für jede Seite individuell zu entscheiden, ob sie auf dem Server, im Browser oder auf einem Edge-Server gerendert wird. Die Technik ist mächtig, aber auch anspruchsvoll. Wer heute eine performante Webseite bauen will, muss mehr wissen als je zuvor.

Was kommt als Nächstes?

Die Branche bewegt sich in Richtung weniger JavaScript im Browser. Frameworks wie Astro oder Qwik versuchen, so wenig JavaScript wie möglich auszuliefern. Island Architecture rendert interaktive Komponenten einzeln statt die gesamte Seite. View Transitions machen Seitenwechsel in Multi-Page Applications genauso flüssig wie in SPAs.

Gleichzeitig wird KI-gestützte Entwicklung immer relevanter. Coding-Assistenten schreiben Boilerplate-Code, generieren Tests und helfen bei der Fehlersuche. Das ersetzt keinen erfahrenen Entwickler, aber es beschleunigt die Arbeit erheblich. Wer die Tools richtig einsetzt, ist produktiver als je zuvor.

Web Components und der zunehmende Verzicht auf Build-Tools (mit nativen ES Modules und Import Maps) könnten die Komplexität wieder reduzieren. Aber die grundlegende Herausforderung bleibt: Eine gute Webseite zu bauen, erfordert Verständnis für HTML, CSS, JavaScript, Performance, Accessibility, SEO und Nutzererfahrung. Die Werkzeuge ändern sich, die Anforderungen bleiben.

Was sich in den letzten 20 Jahren nicht geändert hat: Am Ende zählt, ob die Webseite für die Nutzer funktioniert. Ob sie schnell lädt, gut aussieht, einfach zu bedienen ist und gefunden wird. Die Technik dahinter ist Mittel zum Zweck. Und ein guter Entwickler wählt das Werkzeug, das zum Projekt passt, nicht das, das gerade am meisten gehypt wird.