Weniger Laufzeit. Mehr Website.

Was muss diese Website eigentlich tun?

Projekte vorstellen, technische Beiträge veröffentlichen und zum Mitmachen einladen. Die Inhalte ändern sich bei einem neuen Beitrag oder einer Projektaktualisierung, nicht bei jedem Seitenaufruf. Dafür lässt sich die fertige Seite bereits während des Builds erzeugen.

Der Webserver liefert anschließend HTML und CSS aus. Die Besucher brauchen weder eine Anmeldung noch eine laufende Anwendung auf dem Server, um einen Artikel zu lesen.

Inhalte sind Daten mit einem Vertrag

Titel, Beschreibung und Datum sollten nicht bei jedem Beitrag anders aussehen. Eine Content Collection beschreibt diese Felder und prüft sie beim Build. Das folgende vereinfachte Beispiel definiert eine Sammlung lokaler Artikel:

import { defineCollection } from "astro:content";
import { z } from "astro/zod";
import { glob } from "astro/loaders";

const blog = defineCollection({
  loader: glob({
    base: "./src/content/blog",
    pattern: "**/*.{md,mdx}",
  }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    pubDate: z.coerce.date(),
  }),
});

export const collections = { blog };

Aus diesen Einträgen entstehen die Übersicht, einzelne Artikelseiten und der RSS-Feed. Die Metadaten werden einmal gepflegt und an mehreren Stellen verwendet. Weitere Details erklärt die Astro-Dokumentation zu Content Collections.

Markdown zuerst, MDX bei Bedarf

Für normalen Text genügt Markdown. MDX ergänzt die Möglichkeit, Komponenten direkt in einem Beitrag einzubinden, etwa diesen Hinweis:

Das hält wiederkehrende Elemente einheitlich, ohne den Schreibfluss in ein großes Seitentemplate zu verlagern. MDX-Dateien gehören dabei zum vertrauenswürdigen Quellcode: Sie können Imports und ausführbare Ausdrücke enthalten.

Wo statisch seine Grenzen hat

Eine persönliche Inbox, ein Schreibzugriff auf eine Datenbank oder aktuelle Kontodaten verlangen zusätzliche Laufzeitlogik. Wenn ein solches Feature wirklich gebraucht wird, muss es gezielt ergänzt werden. Für das Lesen von Projekten und Artikeln reicht der statische Build.

Auch Änderungen am Veröffentlichungsdatum brauchen einen neuen Build: Eine statische Seite veröffentlicht sich nicht von selbst, nur weil die Uhr weiterläuft. Ein geplanter Beitrag erscheint nach dem nächsten Build nach seinem Veröffentlichungsdatum.

Ein kleiner, nachvollziehbarer Ablauf

1. Eine Markdown- oder MDX-Datei schreiben.
2. Titel, Beschreibung, Datum und Themen im Frontmatter ergänzen.
3. Lokal mit npm run dev lesen und prüfen.
4. Mit npm run build Inhalte und Typen validieren sowie statische Dateien erzeugen.
5. Den Inhalt von dist/ auf dem Webserver veröffentlichen.

Wenige bewegliche Teile machen es leichter, sich auf die eigentliche Arbeit zu konzentrieren: gute Projekte und verständliche Texte.