Dieses Portfolio

Warum ein Rebuild

Die Vorgängerversion war ein eigenes PHP-MVC-Framework mit elf Controllern, acht Models und dreizehn Datenbanktabellen. Sie konnte Benutzerkonten mit TOTP und Passkeys, ein Ticketsystem mit KI-Chatbot, vier Spiele mit OpenAI-Gegnern und einen E-Auto-Laderechner.

Was sie kaum konnte: Projekte zeigen. Die Projektübersicht bestand aus drei Seiten, und die Projektdaten lagen in einer MySQL-Tabelle — also nicht in Git, nicht versioniert, nicht nachvollziehbar. Ein Portfolio, dessen Inhalt nirgends nachlesbar ist, hat sein Ziel verfehlt.

Der Zuschnitt

Alles, was nicht dem Zeigen von Arbeit dient, ist entfallen: Authentifizierung, Tickets, Spiele, Rechner, Datenbank, Server-Code. Übrig bleibt eine statische Seite, die auf demselben Apache-Host liegt wie vorher — nur eben als dist/-Ordner statt als Front-Controller.

Die Projektinhalte liegen als Markdown im Repository. Ein Zod-Schema in content.config.ts validiert jedes Feld beim Build. Ein fehlendes Jahr, eine kaputte URL, ein Projekt, das nur in einer Sprache existiert — all das lässt npm run build fehlschlagen, statt auf der Live-Seite aufzutauchen.

Warum kein CMS

Ein Admin-Bereich hätte einen Server, eine Session und eine Passwortverwaltung gebraucht — also genau die Angriffsfläche, deren Beseitigung der Punkt des Rebuilds war. Ein neues Projekt ist stattdessen eine Datei pro Sprache und ein Commit. Dafür gibt es Rollback, Diff und Historie gratis.

Frontend

Reaktivität kommt aus einer Handvoll Vanilla-TypeScript-Inseln: Filter und Suche auf der Projektliste, Befehlspalette, Theme-Wechsel, zeigerabhängiges Spotlight auf den Karten. Kein UI-Framework, weil der interaktive Anteil dafür zu klein ist. Die Filterung funktioniert ohne JavaScript weiterhin — dann eben ungefiltert.

Das Farbschema führt die drei Themes der alten Seite fort: Noir als Standard, Hell und Sakura als Alternativen. Alle Animationen liegen hinter prefers-reduced-motion.