Warum Astro? Static Site Generation ohne Wahnsinn

Hand aufs Herz: Wer in den späten 90ern oder frühen 2000ern gelernt hat, Webseiten zu bauen, hat wahrscheinlich immer noch ein leichtes Trauma von verschachtelten HTML-Tabellen, Tag-Soup und CSS-Hacks für den Internet Explorer 6. Wer erinnert sich nicht an den legendären <p style="hack here">-Einfall, nur weil man “das mal eben schnell für die Weihnachtssaison” brauchte - um dann im Februar festzustellen, dass diese eine Schneeflocke das gesamte Layout zusammenhält?

Aber selbst heute noch ist das manuelle Pflegen von rein statischem HTML/CSS/JS eine absolute Qual. Sobald die Seite mehr als nur drei Zeilen hat, fängt das Elend an: Header ändern? Viel Spaß beim Suchen und Ersetzen über zwanzig Dateien. Ja, es gibt SCSS, BEM, Minifier und Hunderte Tools, um hier anzusetzen, aber seien wir ehrlich - das sind alles nur Krücken, um ein fundamentales Problem zu kaschieren: Man wurschtelt immer noch direkt am rohen Code herum. Irgendwo zwischen Inhalt und Aussehen schleichen sich dann wieder die kleinen Hacks aus Faulheit ein… Muss ich noch weiter erzählen oder kommen die Erinnerungen schon hoch? Sehr gut.

Wie ich bereits vor ein paar Tagen beim Ausmisten meines digitalen Kleiderschranks erwähnt habe, läuft diese Seite hier genau auf dem Stack, über den wir heute sprechen müssen.

Die CMS-Falle (oder: Warum Dynamic Rendering oft Blödsinn ist)

Die klassische Antwort der Industrie auf das HTML-Frustproblem war bekanntlich WordPress, Typo3 oder das nächste drölfzigste PHP-Monster. Man bekommt ein schickes Admin-Panel, drückt drei Knöpfe und hat dann eine Webseite. Meistens zumindest.

Als Sysadmin kriegt man dabei irgendwann nur noch Bauchkrämpfe vor lauter Problemen, die hinter diesen Systemen klaffen.

Ein dynamisches CMS bedeutet:

• Ein Interpreter im Hintergrund
• Eine Datenbank, die gepflegt werden will
• Unzählige Server-Requests pro Seitenaufruf
• Ein Ökosystem aus Plugins von fragwürdiger Qualität, weil sich jeder Hinz und Kunz mal eben was geschnitzt hat

Statische Seiten sind dagegen die Sorglos-Alternative. Keine Datenbank, kein Laufzeit-Interpreter, kein Angriffsvektor für SQL-Injections. Der Webserver liefert einfach nur die Dateien aus und der Cache tut auch mal seinen Job. Und das Beste: Da die Seite statisch generiert wird, ist der Wartungsaufwand überschaubar und Lücken im Generator sind nicht mehr ganz so heiß.

Enter Astro: Inhalt von Design trennen

Astro ist ein Static Site Generator, der unseren Inhalt in ein Design quetscht und sauber aussehen lässt, statt uns Steine in den Weg zu legen.

Das Prinzip ist simpel: Du schreibst deine Inhalte in simplem Markdown (or MDX). Keine Ablenkung durch Tags, Layouts oder Inline-Styles, keine Spezialeditoren. Einfach Text. Astro nimmt diesen Content und “kompiliert” daraus beim Build-Prozess saubere, hochoptimierte statische HTML- und CSS-Dateien.

• Gewaltentrennung: Der Inhalt liegt flach als Markdown vor, das Theme/Design in komponentenbasierten Astro-Templates.
• Kein Gerümpel dabei: Astro schickt standardmäßig genau 0 KB JavaScript an den Client, es sei denn, du verlangst explizit danach (z. B. für interaktive Komponenten).
• Kein geheiratetes Framework: Egal ob React, Vue, Preact, Svelte oder Solid - Astro kann sie alle. Du bestimmst, welches du möchtest.

Schnellstart in 30 Sekunden

Wer das selbst ausprobieren will, braucht lediglich ein halbwegs aktuelles Node.js und ein Terminal:

# Neues Projekt initialisieren
npm create astro@latest

# Den Anweisungen im CLI folgen und eine Vorlage auswählen
cd meine-neue-seite
npm run dev

Browser auf localhost:4321 öffnen und zusehen, wie unverschämt schnell das Teil baut - und bei Änderungen am Code sogar neu lädt. Das ist mal ein Service, oder?

Automatisierung: Build & Deploy via CI/CD

Als Admin bin ich natürlich gerne faul und lasse Scripts für mich ackern. Auch das ist hier sehr schön machbar, denn niemand möchte nach jedem neuen Blogpost lokal npm run build tippen und die Dateien manuell auf den Webserver schaufeln. Da unser Code hoffentlich ohnehin in einem Git-Repo liegt - sei es GitHub oder eine selbstgehostete Gogs-/Gitea-/Forgejo-Instanz -, überlassen wir das Kompilieren einfach einer Actions-Pipeline.

Ein typischer Workflow sieht so aus:

1. git push mit neuem Markdown-Artikel.
2. Unser Git-System weckt seine Action zum Leben. Der Runner startet.
3. Node-Umgebung hochfahren, Abhängigkeiten installieren, astro build ausführen.
4. Das fertige dist/-Verzeichnis per SSH/rsync auf den Server schieben. Fertig.

Der Schutzengel: Warum du einen Linter brauchst

Bevor die Action allerdings das fertige HTML auf die Produktionsmaschine wirft, bauen wir noch eine Notbremse ein: Linter und Formatierer (wie Markdownlint, ESLint oder Prettier).

Warum? Weil Menschen Tippfehler machen. Ein kaputter Frontmatter-Header, ein nicht geschlossenes Codeblock-Tag oder verwaiste Links zerschießen dir sonst mitten im Deployment das Layout.

Der Linter fängt diesen Müll im CI-Schritt ab, bevor überhaupt etwas gebaut wird. Bricht die Pipeline ab, bleibt die alte Version der Seite online und du bekommst eine Benachrichtigung, anstatt deinen Lesern eine kaputte Seite zu präsentieren.