Warum wir auf TailwindCSS setzen

Wer zum ersten Mal TailwindCSS sieht, denkt oft: «Das ist doch Chaos — warum sind da 20 Klassen im HTML?» Verständliche Reaktion. Aber dahinter steckt eine Philosophie, die in der Praxis überzeugt — und die wir nach hunderten von Projekten nicht mehr missen möchten.

TailwindCSS ist unser primäres CSS-Framework für neue Projekte. Nicht weil es aktuell populär ist, sondern weil es echte Vorteile für Entwicklungsgeschwindigkeit und langfristige Wartbarkeit bringt.

Was TailwindCSS ist — und was nicht

TailwindCSS ist ein «utility-first» CSS-Framework. Das bedeutet: Statt vordefinierte Komponenten (wie Bootstrap-Buttons oder Bootstrap-Cards) zu verwenden, baut man Designs aus atomaren Hilfsklassen zusammen. `text-lg`, `font-bold`, `p-4`, `bg-gray-100` — jede Klasse macht genau eine Sache.

Das ist der Gegensatz zu klassischen Component-Frameworks: TailwindCSS macht keine Designentscheidungen für dich. Es gibt keinen «Tailwind-Look». Jedes Projekt sieht aus wie es soll, nicht wie Tailwind.

Was Tailwind nicht ist:

• Kein UI-Framework mit fertigen Komponenten (dafür gibt es Headless UI, shadcn/ui, etc.)
• Keine CSS-Bibliothek mit vorgefertigten Designsystemen
• Keine CSS-Methodologie wie BEM oder SMACSS

Warum utility-first in der Praxis schneller ist

Der grösste praktische Vorteil: Kontext-Wechsel entfällt. Bei klassischem CSS springt man zwischen HTML-Datei und CSS-Datei hin und her. Bei Tailwind bleibt man im HTML.

Das klingt minor — ist es aber nicht. Jeder Kontextwechsel kostet kognitive Ressourcen. «In welche CSS-Klasse gehört das? Gibt es schon eine ähnliche Klasse? Wie heisst die wieder?» Diese Fragen entfallen.

Bei einem Projekt mit enger Deadline haben wir die Erfahrung gemacht: Ein Tailwind-erfahrener Entwickler baut eine Seite in einem Drittel der Zeit, die er mit klassischem CSS-Ansatz braucht. Das liegt nicht an Tailwind per se — es liegt daran, dass der mentale Overhead massiv reduziert ist.

Weitere Geschwindigkeitsvorteile:

• Kein Namensgebungsproblem (wie heisst die Klasse für «weisser Button mit Rand»?)
• Kein leeres CSS-File, das man erst strukturieren muss
• Design-Token aus der config.js funktionieren überall ohne Variablen deklarieren

Das CSS-Bloat-Problem und wie Tailwind es löst

In klassischen Projekten wächst die CSS-Datei immer. Neue Features kommen hinzu, alte Klassen werden nie gelöscht (weil man nicht weiss, ob sie noch verwendet werden), und nach zwei Jahren ist das Stylesheet ein Archäologieprojekt.

Mit Tailwind entsteht dieses Problem nicht. Der Build-Prozess analysiert alle Dateien und gibt nur die Klassen in den finalen Bundle, die auch verwendet werden. Das Ergebnis: minimales, sauberes CSS — unabhängig davon, wie gross das Projekt ist.

Für eine mittelgrosse Website mit mehreren hundert Seiten produziert Tailwind oft weniger als 10 KB an komprimiertem CSS. Das hat direkte Auswirkungen auf die Ladezeit — und damit auf SEO und Nutzererfahrung.

Design-System aus der config.js

Tailwind wird über eine config-Datei konfiguriert. Dort definiert man Farben, Schriften, Abstände und alle anderen Design-Token des Projekts. Einmal definiert, sind sie überall konsistent verfügbar.

Das ersetzt traditionelle CSS-Variablen-Systeme und macht das Design-System explizit und sichtbar. Jede Entwicklerin und jeder Entwickler sieht sofort: Das sind die Farben, das sind die Abstände, das ist der Schriftsatz dieses Projekts.

Bei langen Projekten mit mehreren Entwicklern ist das Gold wert. Kein «hast du eine custom class für dieses Grau?», kein inkonsistentes Abstands-System, keine willkürlichen px-Werte im CSS.

Was wir in der Tailwind-config definieren:

• Brand-Farben als semantische Tokens (primary, secondary, accent, muted)
• Typografie-Skala aus dem Figma-Design
• Benutzerdefinierte Breakpoints für responsive Layouts
• Spacing-System für konsistente Abstände

Zusammenarbeit mit Designern: Figma zu Tailwind

TailwindCSS funktioniert besonders gut, wenn Designer und Entwickler dasselbe Vokabular sprechen. Wir setzen Figma ein, definieren dort die Design-Tokens und exportieren sie direkt in die Tailwind-config.

Das bedeutet: Wenn ein Designer «Primary Blue» sagt und ein Entwickler `text-primary` schreibt, meinen beide dasselbe. Diese Übersetzungsschicht — die in klassischen Projekten oft Quelle von Missverständnissen ist — entfällt.

Tailwind und SvelteKit: Eine starke Kombination

Wir verwenden TailwindCSS primär in Kombination mit SvelteKit. Die Integration ist nahtlos, das Entwicklungserlebnis ist konsistent, und das Ergebnis ist performant.

In Svelte-Komponenten sehen Tailwind-Klassen natürlich aus — sie gehören zum Markup, nicht zu einer externen Datei. Die Component-Grenzen von Svelte und die Utility-Klassen von Tailwind ergänzen sich: Jede Komponente ist ein in sich geschlossenes Stück HTML, CSS und JavaScript.

Wann wir Tailwind nicht einsetzen

Tailwind ist nicht für jedes Projekt die richtige Wahl. Bei stark Legacy-geprägten Projekten, die auf bestehenden CSS-Architekturen aufbauen, würde ein Wechsel zu Tailwind mehr kosten als bringen.

Und für einfache Marketing-Websites, die ein bestehender Designer in einer Stunde in WordPress bauen kann, ist der Aufwand der Tailwind-Konfiguration nicht gerechtfertigt.

Unser Einsatz: Tailwind gehört zum Standard-Stack für neue SvelteKit-Projekte, API-getriebene Applikationen, und alle Projekte, die langfristig gewartet werden sollen.

Das bringt dir TailwindCSS als Agentur konkret

• Schnellere Entwicklung: Kein Kontextwechsel zwischen HTML und CSS — wir sind schneller fertig
• Konsistentes Design: Design-Tokens in der config garantieren visuelle Konsistenz über alle Seiten
• Minimales CSS: Nur verwendete Klassen landen im Build — bessere Performance
• Wartbarkeit: Kein wachsendes CSS-Monster — Klassen sind explizit und immer verwendungsgebunden
• Kein Lock-in: TailwindCSS ist Open Source, gut dokumentiert und hat eine grosse Community
• Bessere Zusammenarbeit: Designer und Entwickler sprechen dieselbe Sprache über Design-Tokens