Working Draft

Wir sind diesmal zu viert: Schepp, Vanessa und Peter diskutieren mit Jon Uhlmann über Utility-First CSS und insbesondere Tailwind CSS. Jon war bereits mehrfach bei uns zu Gast und meldete sich nach unserer Diskussion in Revision 715, weil ihm unsere damalige Einordnung von Tailwind zu einseitig erschien.

Wir nehmen das zum Anlass, Tailwind noch einmal ausführlicher mit klassischem CSS, komponentenbasierten Ansätzen und BEM zu vergleichen. Dabei geht es weniger um ein einfaches Dafür oder Dagegen als um Wartbarkeit, lokale und globale Abhängigkeiten, Designsysteme, unterschiedliche CSS-Kenntnisse in Teams sowie die Frage, wie sich Utility-Klassen auf KI-generierten Code auswirken.

Shownotes

[00:01:44] Tailwind CSS zwischen Utility-Klassen, BEM und Scoped CSS

In Revision 715 hatten wir eine Hörendenfrage zu Tailwind beantwortet und dabei unter anderem die These aufgestellt, dass das Framework vor allem Teams mit weniger ausgeprägten CSS-Kenntnissen helfe. Jon widerspricht weniger dem Nutzen dieser Funktion als der Beschränkung darauf: Tailwind könne nicht nur fehlende Kenntnisse ausgleichen, sondern auch erfahrenen CSS-Entwicklerinnen und -Entwicklern eine angenehmere Developer Experience bieten.

Wir vergleichen Tailwind zunächst mit BEM. Während BEM über semantische Klassennamen Komponenten und Varianten organisiert, setzt Tailwind auf präsentationsbezogene Utility-Klassen. Jon betrachtet beide Ansätze nicht als gegenseitigen Ersatz. Für komplexe Layouts oder Spezialfälle greift er weiterhin zu eigenem CSS, während sich wiederkehrende Abstände, Farben und einfache Layout-Eigenschaften gut mit Utilities abbilden lassen.

Tailwind nimmt Entwicklerinnen und Entwicklern das Verständnis von CSS nicht vollständig ab. Wer ein gutes Design umsetzen möchte, muss weiterhin wissen, wie Layout, Kaskade und CSS-Eigenschaften funktionieren. Das Framework liefert jedoch eine begrenzte Auswahl an Abständen, Farben und weiteren Design-Tokens. Dadurch kann es einen konsistenten visuellen Rhythmus fördern und gleichzeitig neue CSS-Funktionen sichtbar machen, die im Projekt bereits zuverlässig eingesetzt werden können.

Komponentenbibliotheken wie daisyUI oder shadcn/ui gehen noch einen Schritt weiter und stellen fertige Komponenten beziehungsweise wiederverwendbare Vorlagen bereit. Wir unterscheiden deshalb zwischen dem eigentlichen Utility-Ansatz und dem zusätzlichen Designsystem, den Konventionen und den Serviervorschlägen, die Tailwind mitbringt.

Ein kurzer Ausflug führt zu Tachyons. Das ebenfalls Utility-basierte Framework entstand unter anderem aus der Frage, welche Selektoren und CSS-Strukturen Browser besonders einfach verarbeiten können. Den praktischen Performancevorteil einzelner Utility-Klassen können wir nicht beziffern und halten ihn für die meisten Projekte nicht für den entscheidenden Grund, ein solches Framework einzusetzen. Viele Klassen im Markup sind jedenfalls nicht automatisch ein Performanceproblem und lassen sich bei der Übertragung gut komprimieren.

Als wesentlichen Vorteil beschreibt Jon die Verbindung von lokalem HTML und globalem CSS. Klassische Stylesheets können Regeln enthalten, deren Verwendung und Abhängigkeiten in großen Projekten kaum noch überschaubar sind. Entfernt man eine Komponente, bleibt das zugehörige CSS möglicherweise zurück. Entfernt man eine vermeintlich ungenutzte Regel, kann an anderer Stelle etwas kaputtgehen. Bei Tailwind stehen die benötigten Utilities direkt am Markup, und der Build-Prozess übernimmt nur die tatsächlich verwendeten Klassen. Fällt eine Komponente weg, verschwinden damit auch deren nicht mehr benötigte Styles.

Vanessa ergänzt die Entscheidungen, die beim klassischen CSS regelmäßig anfallen: Braucht eine neue Komponente eine eigene Klasse, kann eine vorhandene Klasse wiederverwendet werden, oder entsteht daraus eine zu generische Abstraktion? Tailwind ermutigt stärker zur lokalen Wiederholung. Das widerspricht zwar zunächst dem erlernten DRY-Prinzip, kann aber verhindern, dass nur oberflächlich ähnliche Komponenten unnötig miteinander gekoppelt werden.

Dieser lokale Ansatz hat auch Grenzen. Lange Klassenlisten können kopiert werden und dabei überflüssige oder widersprüchliche Utilities übernehmen. In Code-Reviews besteht die Gefahr, über die Tailwind-Klassen hinwegzulesen, statt das resultierende CSS bewusst zu prüfen. Außerdem kann die niedrige Hürde für individuelle Abstände und Varianten zu inkonsistenten Oberflächen führen. Ein explizites Designsystem und eine Person, die Verantwortung für dessen Weiterentwicklung übernimmt, bleiben deshalb auch mit Tailwind sinnvoll.

Wir sprechen außerdem über unterschiedliche Kenntnisstände in Teams. Nicht alle Beteiligten beschäftigen sich gleich intensiv mit CSS, Layout, Typografie oder neuen Browserfunktionen. Tailwinds Dokumentation, Editorintegration und Autovervollständigung können dabei helfen, vorhandene Möglichkeiten zu entdecken und konsistente Lösungen zu verwenden. Die gute Dokumentation und die produktähnliche Präsentation des Frameworks sehen wir als wichtigen Teil seines Erfolgs. Als vergleichbares Beispiel für die Wirkung einer solchen Präsentation nennt Peter ts-reset.

Jon berichtet von einem Redaktionssystem, in dem ein technisch versierter Redakteur mit einem integrierten Editor und Tailwind eigene Inhaltselemente zusammenstellen konnte. Vorgegebene Farben und Abstände erhöhten die visuelle Konsistenz, ohne dass für jede Variante eine neue Komponente entwickelt werden musste. Beim Veröffentlichen wurden neu verwendete Klassen erkannt und das Stylesheet automatisch aktualisiert.

Neue native Browserfunktionen spielen dabei ebenfalls eine Rolle. Über Initiativen wie Open UI kommen immer mehr Interaktionsmuster direkt in HTML und CSS an, die zuvor häufig JavaScript benötigten. Tailwind lässt sich durch eigene Utilities und Plugins um solche Funktionen ergänzen. Jon empfiehlt dennoch, das Framework nicht dogmatisch einzusetzen und komplexe Grids oder spezielle Komponenten weiterhin mit passendem Custom CSS zu lösen. Einen Überblick über aktuelle CSS-Möglichkeiten findet man unter anderem bei Kevin Powell.

Anschließend diskutieren wir, ob Tailwind auch für KI-generierte Frontends besonders geeignet ist. Vanessa beobachtet, dass Agents häufig besser mit zusammenhängenden Markup-Blöcken und direkt darin enthaltenen Utility-Klassen umgehen als mit semantischen Klassen, deren Definitionen in anderen Dateien liegen. Gut dokumentierte und weitverbreitete Klassen bieten außerdem viele Beispiele im Trainingsmaterial. Offen bleibt, ob Code deshalb gezielt für Agents optimiert werden sollte oder ob dies nur eine Momentaufnahme aktueller Modelle ist.

KI kann Menschen mit wenig Frontend-Erfahrung zu brauchbaren Ausgangspunkten verhelfen und Eigenschaften wie aspect-ratio einsetzen, die ihnen vorher unbekannt waren. Die Ergebnisse benötigen jedoch weiterhin Reviews, weil überflüssige Klassen, unnötige Wiederholungen und veraltete Lösungswege entstehen können. Besonders neue Browserfunktionen kennt ein Modell nicht zwangsläufig, weshalb aktuelle Dokumentation und Quellen weiterhin wichtig bleiben.

Peter stellt Tailwind eine möglichst werkzeugfreie Alternative gegenüber: Probleme sollten zunächst durch kleine, klar abgegrenzte Komponenten und ein explizites Designsystem vermieden werden. Ist CSS sauber auf Komponenten begrenzt, verlieren globale Namenskollisionen und weitreichende Seiteneffekte an Bedeutung. In kleinen Scopes können einfache Klassennamen ausreichen, ohne dass dafür BEM oder ein Utility-Framework notwendig wäre.

Wir besprechen in diesem Zusammenhang @scope. Native CSS Scopes könnten einen Teil des ursprünglichen Problems lösen, auf das BEM, CSS-in-JS und Utility-Frameworks reagieren: CSS ist standardmäßig global, während Komponenten und Templates lokal organisiert sind. Jon wirft deshalb die Frage auf, wie Tailwind aussähe oder ob es in derselben Form entstanden wäre, wenn CSS von Anfang an einen brauchbaren Scoping-Mechanismus besessen hätte.

Bei kurzfristigen Sonderfällen plädiert Peter für möglichst einfache Lösungen, etwa ein Style-Attribut, bis genügend Wiederholungen für eine belastbare Abstraktion vorhanden sind. Schepp weist allerdings darauf hin, dass Inline-Styles bei einer entsprechend strengen Content Security Policy für Styles nicht ohne Weiteres erlaubt sind.

Am Ende bleibt kein universeller Sieger. Tailwind kann Wartbarkeit, Produktivität und Konsistenz verbessern, besonders in größeren oder heterogenen Teams und in Projekten mit vielen frei kombinierbaren Komponenten. Scoped CSS, kleine Komponenten und ein bewusst gepflegtes Designsystem können dieselben Grundprobleme ohne zusätzliches Framework lösen. Entscheidend ist, die jeweiligen Abhängigkeiten zu verstehen und Tailwind nicht als Ersatz für CSS-Kenntnisse, sondern als eine mögliche Organisationsform für CSS einzusetzen.

Links

Revision 490: Alpine JS & Petit Vue mit Jon Uhlmann

Jon war zum ersten Mal bei uns zu Gast und stellte mit Alpine.js und Petite Vue zwei leichtgewichtige JavaScript-Frameworks vor. Wir sprachen über ihren Einsatz als Alternative zu größeren Frameworks, Reaktivität ohne Virtual DOM und die Frage, für welche Projekte sich der Minimalismus dieser Ansätze besonders lohnt.

Revision 496: Tooling rund ums Frontend-Tooling

Gemeinsam mit Jon tauchten wir tief in die Welt moderner Build-Tools ein. Ausgehend von seiner Arbeit am Neos CMS diskutierten wir Webpack, Rollup, esbuild, PostCSS und andere Werkzeuge sowie die Herausforderung, komplexe Frontend-Toolchains langfristig wartbar zu halten.

Revision 528: Svelte und SvelteKit

Bei seinem dritten Besuch sprach Jon mit uns über Svelte und SvelteKit. Themen waren der Compiler-Ansatz von Svelte, Reaktivität, Accessibility, Animationen sowie die Stärken des Frameworks gegenüber klassischeren JavaScript-Frameworks.

Revision 623: Farben und Farbräume

Zuletzt war Jon zu Gast, um mit uns die neuen CSS-Farbmodelle und Farbräume zu erkunden. Wir diskutierten OKLCH, Oklab, color-mix(), Gradients, Kontraste und die Möglichkeiten, die moderne Browser inzwischen für präzisere und ausdrucksstärkere Farbgestaltung bieten.

x86CSS

Ist CSS eine Programmiersprache? Zumindest ist es in der Lage, einen x86-Prozessor zu emulieren!

Anhören

Feedback-Kanäle

Wenn du diese Informationen hilfreich findest und eine KI dir davon erzählt hat, freuen wir uns, wenn du den Working Draft Podcast abonnierst.