Warum und womit wir juit.de neu gebaut haben

Zusammenfassung

Nach mehreren Jahren sind wir mit juit.de auf ein komplett neues Fundament umgezogen: eine statische, mit Astro gebaute Website, konsequent in TypeScript, mit einem eigenen Blog auf Basis von Content Collections — diesen Beitrag eingeschlossen. Entwickelt wird lokal in ddev, unter anderem mit einem eigenen Add-on für Node.js-Tooling. Der Relaunch war kein reines Facelift, sondern eine bewusste Entscheidung für mehr Ladegeschwindigkeit, bessere Wartbarkeit und einen Aufbau, der mit unseren Inhalten mitwächst, statt sie auszubremsen. Dieser Beitrag erklärt, warum wir neu gebaut haben und welche Technologien heute dahinterstecken.

Warum nach mehreren Jahren neu bauen?

Eine Website “einfach mal neu machen” ist schnell gesagt und selten die eigentliche Motivation. Die alte Seite lief auf Sculpin , einem PHP-basierten statischen Seitengenerator — vom Grundprinzip also demselben Ansatz, den wir auch heute wieder verfolgen, nur mit einem komplett anderen Stack darunter. Der Auslöser für den Relaunch war trotzdem eine Mischung aus mehreren kleinen Reibungspunkten, die sich über die Jahre angesammelt hatten, statt ein einzelnes großes Problem: Änderungen dauerten länger, als sie sollten, Inhalte wie Referenzprojekte oder Team-Profile ließen sich nicht so pflegen, wie wir es uns inzwischen von unserer eigenen Arbeit für Kunden gewohnt sind, und die Seite spiegelte unseren aktuellen Stack und unsere aktuelle Arbeitsweise nicht mehr wider. Dazu kam ein Gefühl, das sich schwerer in eine technische Anforderung fassen lässt: Die alte Optik entsprach uns nicht mehr so ganz. Als Beratung ist die eigene Website auch ein Aushängeschild fürs eigene Handwerk — und wer Kunden zu modernen, wartbaren Architekturen rät, sollte selbst kein Gegenbeispiel liefern.

Hinzu kam ein ganz praktischer Punkt: Wir wollten regelmäßiger über unsere Arbeit schreiben können — Erfahrungen mit Tools, Einblicke in Projekte, Gedanken zu Themen, mit denen wir uns beschäftigen. Das ging mit der alten Struktur nicht ohne größeren Aufwand. Ein Blog wie dieser hier war also von Anfang an Teil der Anforderungen an den Relaunch, nicht ein nachträglich angeflanschtes Feature.

Unsere Ziele für den Relaunch

Bevor wir über Technologien sprechen, kurz zu den Zielen, an denen wir Entscheidungen unterwegs gemessen haben:

• Geschwindigkeit. Wir beraten unsere Kunden zu Digitalisierung und Software-Qualität — da sollte unsere eigene Website nicht lahm laden.
• Wartbarkeit und Erweiterbarkeit. Inhalte und Struktur sollen sich unkompliziert anpassen und um neue Inhalte ergänzen lassen, ohne das bestehende Fundament grundlegend verändern zu müssen.
• Datenschutz von Anfang an. Nicht als nachträgliche Cookie-Bannerei, sondern als Entscheidung, die schon in der Architektur beginnt.

Diese drei Punkte haben die Technologieentscheidungen im Kern bestimmt.

Der Technologie-Stack im Detail

Astro als Fundament

Die Seite ist mit Astro gebaut, einem Framework, das konsequent auf statische Auslieferung setzt: Standardmäßig wird HTML zur Build-Zeit erzeugt, JavaScript landet nur dort im Browser, wo es wirklich gebraucht wird — bei einer überwiegend inhaltsgetriebenen Seite wie unserer also kaum. Das Ergebnis sind sehr schnell ladende Seiten, ganz ohne dass wir Performance-Optimierung als eigenes Projekt betreiben müssten. Für eine Website, die sich nicht laufend in Echtzeit ändert, ist das genau das richtige Modell — Interaktivität wie das mobile Menü oder der Copy-Button an Code-Beispielen kommt gezielt als kleines, eigenständiges Skript dazu, statt die ganze Seite in ein Single-Page-Application-Gerüst zu zwingen.

TypeScript und Content Collections

Die gesamte Seite ist in TypeScript geschrieben, inklusive der Datenstrukturen für Leistungen, Projekte, Team-Profile und eben Blogbeiträge. Der Vorteil zeigt sich vor allem dort, wo Inhalte eine feste Form haben müssen: Ein Blogbeitrag hat ein Pflichtfeld für die Hauptkategorie, optionale weitere Kategorien, eine Beschreibung, ein optionales Titelbild — und der Build bricht kontrolliert ab, wenn eine Angabe fehlt oder falsch typisiert ist, statt dass ein Tippfehler erst live auffällt.

category: z.string(),
additionalCategories: z.array(z.string()).default([]),
tags: z.array(z.string()).default([]),
heroImage: image().optional(),
draft: z.boolean().default(false),

Blogbeiträge selbst schreiben wir als einfache Markdown-Dateien mit diesem Schema als Frontmatter — inklusive Syntax-Highlighting für Code-Beispiele, wie Sie oben sehen können, ganz ohne zusätzliche Konfiguration on top.

Entwicklung mit ddev

Lokal entwickeln wir mit ddev , das die komplette Umgebung — Node.js-Version, Webserver, künftig auch Datenbanken für andere Projekte — in Docker-Containern reproduzierbar macht: Ein neues Teammitglied checkt das Repository aus, startet ddev, und hat exakt dieselbe Umgebung wie alle anderen, ohne Node lokal installieren oder Versionen manuell jonglieren zu müssen. Ein eigenes ddev-Add-on ist dabei direkt aus diesem Projekt entstanden: ddev-nub bringt ein schnelles Rust-CLI für Node.js-Tooling in den Container. Das Thema ist ausführlich genug für einen eigenen Beitrag — den finden Sie verlinkt, wenn Sie tiefer einsteigen wollen.

Bilder, Schriften und Performance im Detail

Zwei kleinere, aber spürbare Entscheidungen: Schriften liefern wir selbst gehostet aus, statt sie live von Google Fonts nachzuladen — das spart eine zusätzliche DNS- und TLS-Verbindung beim ersten Seitenaufruf und vermeidet, dass Besucher-IP-Adressen bei jedem Seitenaufruf an Google übertragen werden. Bilder — Team-Fotos, Referenzlogos, künftig auch Titelbilder in diesem Blog — laufen automatisch durch eine Optimierungs-Pipeline, die passende Formate und Größen erzeugt, ohne dass wir jedes Bild von Hand exportieren und komprimieren müssen.

Datenschutz von Anfang an mitgedacht

Ganz konkret heißt das: keine Analyse- oder Tracking-Skripte, die ohne Einwilligung laufen, ein Kontaktformular, das nur die Daten verarbeitet, die für die Anfrage tatsächlich nötig sind, und eine Datenschutzerklärung, die abbildet, was wir als Unternehmen insgesamt tun — bewusst nicht auf die Website beschränkt, damit wir dieselben Informationen nicht doppelt an mehreren Stellen pflegen müssen. Sie enthält nichts, was wir nicht tatsächlich tun, und lässt nichts weg, was wir tun. Datenschutz ist damit nichts, was einmal erledigt und abgehakt ist, sondern etwas, das wir bei jeder neuen Funktion — auch bei diesem Blog — neu mitdenken müssen.

Was als Nächstes kommt

Dieser Blog ist der sichtbarste neue Baustein: mit Kategorien, Schlagwörtern und einem RSS-Feed, den Sie unter /blog/feed.rss abonnieren können, sobald hier regelmäßig etwas erscheint. Wir werden hier über Projekte, Tools und Themen schreiben, mit denen wir uns ohnehin beschäftigen — nicht, weil eine Marketingstrategie das verlangt, sondern weil es Dinge gibt, die wir sowieso aufschreiben würden, und die für andere genauso nützlich sein können wie für uns.

Wenn Sie Fragen zum Relaunch, zu einzelnen Technologieentscheidungen oder zu Ihrem eigenen Projekt haben: Sprechen Sie uns einfach an.

Verwendete Technologien

Zum Nachschlagen, ohne den ganzen Artikel noch einmal zu lesen:

• Astro — Framework für schnelle, überwiegend statisch ausgelieferte Websites.
• TypeScript — typisierte Obermenge von JavaScript.
• ddev — Docker-basierte lokale Entwicklungsumgebung für Webprojekte.
• ddev-nub — ddev-Add-on, das nub (ein in Rust geschriebenes CLI-Tool für Node.js-Tooling) in den ddev-Webcontainer integriert.