Von Hugo zu HTML: Warum einfacher manchmal besser ist

## Die Frustration mit Hugo

Vor kurzem habe ich meine erste Website mit Hugo erstellt. Das klang in der Theorie großartig: Markdown schreiben, Hugo generiert statische Seiten, fertig. In der Praxis war es jedoch deutlich komplizierter.

Hugo ist manchmal echt bescheuert. Klingt hart, aber nachdem ich Stunden damit verbracht habe, Build-Prozesse zu debuggen, Git-Submodules zu fixen und Cloudflare Pages Deployments zum Laufen zu bringen, kann ich das mit gutem Gewissen sagen.

## Die Probleme mit Hugo

### 1. Build-Prozess Komplexität

Hugo braucht einen Build-Schritt. Das bedeutet:

• Man muss Hugo auf dem Deployment-Server installiert haben
• Die richtige Hugo-Version muss übereinstimmen (extended vs. normal)
• Build-Scripts müssen korrekt konfiguriert sein
• Themes als Git-Submodules sind eine zusätzliche Fehlerquelle

### 2. Debugging-Nightmare

Wenn etwas nicht funktioniert, wo liegt das Problem?

$ debugging_layers=(
    "Hugo-Config (hugo.toml)"
    "Theme-Config"
    "Build-Script"
    "Cloudflare Pages Settings"
    "Git-Repository Synchronisation"
)

for layer in "${debugging_layers[@]}"; do
    echo "[CHECK] $layer"
    # Good luck finding the actual problem...
done

Die Fehlersuche wird zum Detektivspiel durch fünf verschiedene Konfigurationsebenen.

### 3. Die "Es baut vom falschen Commit" Situation

Bei mir kam es sogar dazu, dass Cloudflare Pages von einem komplett anderen Repository-Commit gebaut hat als erwartet. Der Code war korrekt gepusht, aber die Website zeigte alte Inhalte. Das lag an falsch konfigurierten Repository-Verbindungen und Branch-Mappings.

Das war der Moment, wo ich dachte: "Das kann doch nicht sein!"

## Die Lösung: Back to Basics

Meine Lösung war radikal einfach: Zurück zu purem HTML, CSS und JavaScript.

### Was ich gemacht habe:

$ tree my-new-website/
my-new-website/
├── index.html
├── about/
│   └── index.html
├── projects/
│   ├── index.html
│   └── project1.html
├── css/
│   └── style.css
└── js/
    └── main.js

✓ Alle Hugo-Markdown-Dateien zu HTML konvertiert
✓ Poison Theme in reines CSS nachgebaut
✓ Dark Mode mit JavaScript + localStorage
✓ Responsive Design mit CSS Media Queries

### Die Vorteile:

## Wann macht Hugo Sinn?

Fairerweise muss ich sagen: Hugo ist nicht grundsätzlich schlecht. Es macht Sinn für:

• Große Blogs mit hunderten Artikeln
• Teams, die hauptsächlich in Markdown schreiben wollen
• Projekte mit komplexen Taxonomien und Tags
• Wenn man das Build-Setup einmal richtig eingerichtet hat

Aber für eine kleine Portfolio-Website mit 3-4 Seiten? Total overkill.

## Mein Fazit

Manchmal ist die einfachste Lösung die beste. HTML, CSS und JavaScript sind seit Jahrzehnten bewährt und funktionieren einfach. Kein Build-Prozess, keine versteckten Konfigurationen, keine Deployment-Magie.

Die Website, die du gerade liest, ist komplett in HTML/CSS/JS geschrieben. Sie sieht genauso aus wie die Hugo-Version, funktioniert genauso, aber ist 10x einfacher zu warten und zu deployen.

---

Diese Website ist das lebende Beispiel: Einfach, wartbar, und funktioniert perfekt ohne Hugo-Overhead.