Was ist Tailwind CSS?

Um Tailwind zu verstehen, hilft ein Blick auf das, was es ersetzt. Das Aussehen einer Webseite steckt in CSS, einer eigenen Sprache für Farben, Abstände und Schriften. Klassisch liegt dieses CSS in getrennten Dateien: Im HTML steht ein selbst erfundener Name wie produktkarte, in der Stildatei steht, wie eine Produktkarte aussieht. Bei jeder Änderung springt man zwischen beiden Welten hin und her, und über die Jahre sammeln sich Namen an, deren Bedeutung niemand mehr kennt.

Tailwind dreht das um. Es liefert einen großen Vorrat fertiger Mini-Klassen, von denen jede genau eine Sache tut: p-4 setzt einen Innenabstand, text-white macht die Schrift weiß, rounded rundet die Ecken. Diese Klassen stehen direkt am Element im HTML. Was ein Knopf tut und wie er aussieht, steht damit an einer Stelle, und es gibt keine erfundenen Namen mehr, die erklärt werden müssten.

Dieser Knopf ist fertig gestaltet, ohne dass irgendwo eine eigene Stildatei angefasst wurde: abgerundete Ecken, blauer Hintergrund, weiße Schrift, ein dunkleres Blau beim Überfahren. Wer die Zeile liest, weiß genau, wie der Knopf aussieht.

Der eigentliche Kern von Tailwind ist nicht die Schreibweise, sondern die Skala dahinter. Abstände, Farben und Schriftgrößen kommen aus einem festen Vorrat, der einmal im Projekt definiert wird. Es gibt p-2, p-4 und p-6, aber keinen Abstand von siebzehn Pixeln, weil es gerade passte. Es gibt die Blautöne der Skala, aber nicht dreiundzwanzig ähnliche Blautöne, die sich über Jahre eingeschlichen haben. Diese Begrenzung klingt nach wenig, ist im Alltag aber der Grund, warum Tailwind-Projekte einheitlich aussehen.

Die Skala lässt sich an das eigene Erscheinungsbild anpassen: Hausfarben, Schriften und Abstände werden in der Konfiguration hinterlegt und ersetzen die Voreinstellungen. Danach benutzt das ganze Projekt nur noch diese Werte, und eine Änderung an der Hausfarbe passiert an genau einer Stelle. Beim Bauen der Seite prüft Tailwind außerdem, welche Klassen tatsächlich vorkommen, und liefert nur diese aus. Die Stildatei bleibt dadurch klein, was den Seitenaufbau schnell hält.

Dass die Klassenketten im HTML nicht ausufern, liegt an einem zweiten Baustein: Komponenten. In Projekten mit React oder Next.js wird ein Knopf einmal als Komponente gebaut und überall wiederverwendet, die Tailwind-Klassen stehen also nur an einer Stelle. Genau deshalb passen Tailwind und komponentenbasierte Frameworks so gut zusammen.

Tailwind ist heute in einem großen Teil der neuen Webprojekte anzutreffen, vom Startup-Produkt bis zur Konzern-Anwendung. Besonders gut passt es dort, wo mehrere Leute an einer Oberfläche arbeiten oder mehrere Seiten zusammengehören sollen. Typische Einsätze sind:

• Webanwendungen und Portale mit vielen Ansichten, die einheitlich aussehen sollen
• Firmenwebseiten und Landingpage-Familien, die dasselbe Erscheinungsbild teilen
• Onlineshops, bei denen das eigene Erscheinungsbild statt eines Baukasten-Looks gefragt ist
• Oberflächen-Prototypen, die schnell entstehen und später weiterwachsen sollen
• Projekte mit wechselnden Bearbeitern, weil die Gestaltung am Element ablesbar ist

Bei uns ist Tailwind eine Option, kein Reflex: Wir setzen es ein, wenn euer Team damit weiterarbeitet oder das Projekt davon profitiert, sonst schreiben wir CSS ohne Zusatz. Diese Webseite selbst nutzt zum Beispiel SCSS-Module, weil das zu ihrem Zuschnitt besser passt. Wie wir solche Entscheidungen treffen, zeigt unsere Seite zum Webdesign.

Tailwind entstand aus Projektalltag, nicht am Reißbrett. Der kanadische Entwickler Adam Wathan zog sich aus seinen eigenen Projekten immer wieder dieselben Hilfsklassen heraus, bis daraus 2017 ein eigenständiges Werkzeug wurde. Die Idee, Gestaltung über viele kleine Klassen statt über erfundene Namen zu regeln, war damals umstritten und wurde in Fachkreisen heftig diskutiert. Durchgesetzt hat sie sich trotzdem, vor allem weil sie im Alltag schlicht funktioniert.

Der häufigste Irrtum zuerst: Tailwind gestaltet nichts von selbst. Es liefert Bausteine, aber kein Design, und eine Seite voller Hilfsklassen kann genauso lieblos aussehen wie jede andere. Die Gestaltungsarbeit bleibt Menschenarbeit. Dazu kommen ein paar handfeste Grenzen:

• Das HTML wird voller: lange Klassenketten am Element sind gewöhnungsbedürftig und bleiben es
• Es braucht einen Build-Schritt beim Bauen der Seite, in modernen Projekten ist der aber ohnehin da
• In Teams, die klassisches CSS pflegen und schätzen, wird Tailwind schnell zum Streitpunkt
• Bei einer kleinen Seite mit wenigen Vorlagen ist eigenes CSS oft kürzer und lesbarer

Keiner dieser Punkte lässt sich wegkonfigurieren. Wer die Klassenketten nicht mag, sollte Tailwind nicht einsetzen, und das ist eine völlig legitime Entscheidung.

Die Frage ist keine Glaubensfrage, auch wenn sie im Netz oft so geführt wird. Beides ist am Ende CSS, der Unterschied liegt darin, wer die Ordnung hält. Bei eigenem CSS hält sie das Team: mit Namensregeln, Disziplin und Erfahrung. Bei Tailwind hält sie das Werkzeug: durch die feste Skala und die Klassen, die es gibt oder eben nicht gibt. Als Orientierung:

• Tailwind, wenn viele Leute oder wechselnde Dienstleister an der Oberfläche arbeiten
• Tailwind, wenn mehrere Seiten oder Anwendungen dasselbe Erscheinungsbild teilen sollen
• Eigenes CSS, wenn ein eingespieltes Team seine Ordnung bereits hat und hält
• Eigenes CSS, wenn die Seite klein ist und ein Build-Werkzeug nur für die Gestaltung übertrieben wäre

Ehrlich gesagt entscheidet meist nicht die Technik, sondern die Frage, wer den Code in drei Jahren anfasst. Ein Nachfolger findet sich in einem Tailwind-Projekt schnell zurecht, weil die Regeln überall dieselben sind. Ein sauber gepflegtes eigenes CSS ist genauso wartbar, nur hängt das Wort sauber dort stärker an den Personen als am Werkzeug.

Als Auftraggeber sieht man Tailwind nie direkt, aber man spürt seine Wirkung an zwei Stellen. Die erste ist das Erscheinungsbild: Weil alle Werte aus einer Skala kommen, sehen auch Seiten einheitlich aus, die zu verschiedenen Zeiten von verschiedenen Leuten gebaut wurden. Die Hausfarbe liegt an einer Stelle, und ein Markenwechsel bedeutet eine Änderung statt einer Suche durch dutzende Dateien.

Die zweite Stelle sind die Folgekosten. Tailwind selbst kostet nichts, die Lizenz ist MIT, und die enorme Verbreitung sorgt dafür, dass praktisch jeder Webdienstleister damit arbeiten kann. Ein Wechsel des Dienstleisters scheitert also nicht am Werkzeug. Was eine Webseite insgesamt kostet und wovon das abhängt, haben wir in einem eigenen Artikel aufgeschrieben.

An der Verbreitung gemessen ist die Frage schnell beantwortet: Tailwind führt die Umfragen unter den CSS-Frameworks seit Jahren an, die Entwicklung ist aktiv, und mit Version 4 wurde der Kern gerade erst neu geschrieben. Hinter dem Projekt steht mit Tailwind Labs eine Firma mit eigenem Geschäftsmodell, es hängt also nicht am Wohlwollen eines einzelnen Konzerns.

Interessanter ist die Gegenbewegung: CSS selbst wird von Jahr zu Jahr besser und beherrscht inzwischen vieles, wofür früher Werkzeuge nötig waren. Der Abstand schrumpft also, und für kleine Projekte ist pures CSS heute eine ernsthafte Alternative. Tailwinds eigentliches Argument bleibt davon aber unberührt, denn die feste Skala und die gemeinsame Sprache im Team liefert CSS allein nicht. Wann wir zu Tailwind greifen und wann nicht, steht auf unserer Tailwind-Seite.