blackzack.dev, Version eins

Im Oktober habe ich angefangen, eine Seite unter meinem eigenen Namen zu bauen. Nicht für ein Projekt, sondern für alles zusammen: Wer ich bin, was ich mache, woran ich arbeite.

Der Anlass war banal. Ich hatte mehrfach die Situation, jemandem etwas zeigen zu wollen, und die einzige Antwort war eine Sammlung von Links: hier der Bot, da ein Repository, dort ein Discord-Server. Nichts davon erklärt den Zusammenhang.

Was ich wollte und was nicht

Ich wollte: einen Ort, der über die Zeit wächst. Projekte, Texte, Notizen zu Dingen, die ich gelernt habe. Etwas, das in fünf Jahren noch dasteht und dann mehr enthält als heute.

Ich wollte nicht: eine Visitenkarte, die nach drei Monaten veraltet ist. Genau das sind die meisten Portfolioseiten — sie werden einmal gebaut, sind hübsch und dann nie wieder angefasst.

Daraus folgte die wichtigste Anforderung: Inhalte hinzuzufügen muss einfach sein. Wenn ein neuer Eintrag bedeutet, dass ich Layoutcode anfassen muss, wird es nicht passieren.

Warum kein Baukasten

Ich habe ernsthaft überlegt, einen fertigen Seitenbaukasten zu nehmen. Es hätte ein Wochenende gespart. Drei Gründe haben dagegen gesprochen:

Ich wollte die Inhalte in meiner Hand haben. Texte als Dateien im eigenen Repository, nicht in der Datenbank eines Anbieters.

Ich wollte die Seite als Übungsfläche. Neue Techniken probiere ich lieber hier aus als in einem System, auf das sich Leute verlassen.

Ich hatte den Aufbau schon. Framework, Gestaltung, Ausliefern — all das kannte ich aus dem Dashboard. Der Grenzaufwand war deutlich kleiner als bei jemandem, der bei null anfängt.

Der dritte Punkt ist der ehrlichste. Wer diese Grundlagen nicht hat, für den ist ein Baukasten die richtige Wahl.

Der Aufbau

Next.js, Tailwind, und Inhalte als Markdown-Dateien im Projekt. Eine Bibliothek liest den Ordner ein, wertet die Kopfdaten aus und stellt typisierte Objekte bereit.

content/
  blog/
    erster-eintrag.mdx
    zweiter-eintrag.mdx
  uses.mdx

Jede Datei beginnt mit Kopfdaten:

---
title: "Titel"
publishedAt: "2023-10-21"
summary: "Ein Satz, worum es geht."
tags: ["web"]
---

Der Vorteil dieses Ansatzes ist die Unmittelbarkeit: Eine Datei anlegen, Text schreiben, fertig. Kein Anmelden, keine Oberfläche, keine Datenbank. Für jemanden, der ohnehin den ganzen Tag in einem Editor sitzt, ist das der kürzeste Weg.

Der Nachteil ist genauso deutlich, und ich habe ihn zwei Jahre später zu spüren bekommen: Man kann nur dort schreiben, wo man das Repository hat. Vom Handy aus einen Tippfehler zu korrigieren ist nicht vorgesehen. Genau deshalb sind die Inhalte später doch in eine Datenbank gewandert — aber das ist eine Geschichte für einen späteren Eintrag.

Was ich beim Bauen gelernt habe

Dunkelmodus gehört ins Fundament. Ich habe ihn nachträglich eingebaut und dabei jede Farbe zweimal angefasst. Beim zweiten Anlauf habe ich mit Farbvariablen angefangen, die je nach Modus andere Werte haben — dann ist ein Modus eine Definition und keine Durchsicht.

Bilder sind der Grund, warum Seiten langsam sind. Nicht das Framework, nicht das JavaScript. Ein einziges nicht optimiertes Foto wiegt mehr als der gesamte Rest. Feste Größenangaben verhindern außerdem, dass die Seite beim Laden springt.

Eine Seite braucht eine Startseite, die etwas sagt. Meine erste Fassung hatte eine Begrüßung und drei Kacheln. Wer draufkam, wusste nach fünf Sekunden nicht, worum es geht. Die zweite Fassung sagt in einem Satz, wer ich bin und was ich mache — und die Verweildauer hat sich sichtbar verändert.

Was ich beim Aufbau der Seite gelernt habe

Ein paar Entscheidungen aus dieser Zeit haben sich als tragfähig erwiesen, andere nicht.

Getragen hat: Inhalte von Darstellung trennen. Die Texte lagen als Dateien mit Kopfdaten vor, die Darstellung war Sache der Anwendung. Als die Inhalte später in eine Datenbank umgezogen sind, war das ein Umbau der Herkunft — nicht der Darstellung.

Getragen hat: von Anfang an Farbvariablen. Auch als es nur einen Modus gab. Der Dunkelmodus war später eine Definition statt einer Durchsicht.

Nicht getragen hat: die Annahme, dass ich nur am Rechner schreibe. Genau daran ist das Dateimodell später gescheitert.

Nicht getragen hat: der Verzicht auf eine Verwaltungsoberfläche. Ich hatte gedacht, ein Editor reicht mir. Für Texte stimmt das. Für alles, was Zustand hat — Entwürfe, Veröffentlichungszeitpunkte, Medien —, nicht.

Der Teil, der bis heute funktioniert

Eine Sache aus dieser ersten Fassung ist unverändert geblieben und hat sich als die wertvollste erwiesen: Die Seite ist mein Versuchsfeld.

Alles, was ich an neuen Techniken ausprobiere, läuft hier zuerst. Ein neues Framework-Modell, eine andere Art, Daten zu laden, ein Ansatz für Bilder, ein Gestaltungssystem.

Der Grund, warum das funktioniert: Wenn diese Seite eine Stunde kaputt ist, stört das niemanden. Es gibt keine Nutzer, die darauf angewiesen sind, keine Verpflichtung, keine Ausfallzeit, die jemand bemerkt.

Ich halte so ein Feld inzwischen für notwendig. Wer neue Techniken nur in Systemen ausprobieren kann, auf die sich Leute verlassen, probiert entweder zu wenig aus oder zu riskant.

Was daraus geworden ist

Die Seite gibt es bis heute, in mehrfach überarbeiteter Form. Sie hat inzwischen Bereiche, die ich 2023 nicht vorgesehen hatte: ein Wiki, eine Downloadseite, Bilder, und einen Blog, der von einer Sammlung Dateien zu einem gepflegten Bereich mit Verwaltung geworden ist.

Was ich daran am meisten schätze, ist etwas anderes als das Ergebnis. Diese Seite ist der Ort, an dem ich Sachen ausprobiere, bevor sie in Systeme kommen, auf die sich Leute verlassen. Fast alles, was ich in den Jahren danach an neuen Techniken benutzt habe, war zuerst hier — und wenn es nichts taugte, hat es niemanden gestört.