Tailwindcss vs CSS

In diesem Beitrag wollen wir die Vorteile und Grenzen von TailwindCSS mit denen von reinem CSS vergleichen. Dabei teilen wir auch unsere eigenen Erfahrungen und Einsichten, die wir in unseren Projekten gesammelt haben.

Unser bisheriger CSS-Ansatz

Bevor wir in das Thema einsteigen, werfen wir einen kurzen Blick darauf, wie wir bisher gearbeitet haben. Wir haben hauptsächlich SCSS verwendet, weil es einige entscheidende Vorteile bietet:

• Variablen erleichtern die Konsistenz im Design.
• Funktionen und Mixins ermöglichen komplexe Styles ohne Wiederholungen.
• Modulare Struktur durch Aufteilung in verschiedene Dateien.
• Kompilierung in eine einzige CSS-Datei, früher mit Tools wie Grunt, Gulp oder Webpack.

Dann kam TailwindCSS und behauptete: All das brauchen wir nicht mehr! Stattdessen schreiben wir nur noch HTML mit den vordefinierten Utility-Klassen von Tailwind.

Wie funktioniert TailwindCSS?

Während der Entwicklung läuft im Hintergrund ein Prozess, der alle verwendeten CSS-Klassen erkennt und eine optimierte CSS-Datei generiert. Das bedeutet:

• Wir nutzen nur die CSS-Klassen, die im HTML tatsächlich verwendet werden.
• Anders als bei großen Frameworks bleibt die finale CSS-Datei schlank.

Vorteile von TailwindCSS:

• Konsistente Styling-Vorgaben durch vorbereitete Variablen für Farben, Abstände usw.
• Integrierte Flexbox- und Grid-Unterstützung.
• Keine zwingende Notwendigkeit eines Bundlers.
• Responsive Design direkt eingebaut.
• Browserkompatibilität von Anfang an gegeben.
• Ideal für Rapid Prototyping.

Ein Beispiel aus unserer Erfahrung: Marks YADL-Blog haben wir mit einem Tailwind-Theme und nur wenigen Anpassungen sehr schnell umgesetzt. Auch Maurice nutzte Tailwind für seine Webseite und profitierte anfangs von einer deutlich kleineren CSS-Datei und dem Verzicht auf zusätzliches JavaScript.

Doch dann traten erste Probleme auf:

• Er wiederholte ständig CSS-Klassen in seinen Snippets.
• Ohne Komponenten wurde das HTML zunehmend unübersichtlicher.
• Er begann, eigene Utility-Klassen mit @apply zu definieren – eine Mischung aus Tailwind und Custom CSS entstand.
• Am Ende musste er doch eigene CSS-Klassen schreiben, was den Tailwind-Ansatz konterkarierte.
• Schließlich entschied er sich für reines CSS.

Vanilla CSS – Dank neuer Features eine echte Alternative?

Inzwischen hat sich CSS so stark weiterentwickelt, dass viele Tailwind-Vorteile auch ohne ein Framework erreicht werden können:

• CSS-Variablen bieten eine flexible und modulare Gestaltung.
• Nested CSS macht SCSS oft überflüssig.
• Container Queries (eine der größten Neuerungen!) erleichtern responsives Design.
• Aspect Ratio, Grid, Flexbox und weitere moderne Features machen viele externe Helfer überflüssig.
• Keinerlei Abhängigkeit von externen Bibliotheken.

Ein weiterer Vorteil: Das HTML bleibt sauber! Während Tailwind gegen zwei wichtige Prinzipien verstößt:

• Separation of Concerns: CSS und HTML werden vermischt.
• DRY (Don't Repeat Yourself): Wiederkehrende Klassen führen zu redundanten HTML-Strukturen.

Zudem ist ein Wechsel von Tailwind zu reinem CSS oft aufwendig und zeitintensiv.

Unser Fazit: Wann TailwindCSS, wann reines CSS?

Wir setzen Tailwind weiterhin für schnelles Prototyping ein – dafür ist es hervorragend geeignet. Doch für detailreiche Projekte bevorzugen wir reines CSS, da es:

• langfristig sauberer und flexibler ist,
• keinen Overhead durch externe Frameworks verursacht,
• mit modernen Features wie Container Queries besser skalierbar bleibt.

CSS hat sich in den letzten Jahren enorm weiterentwickelt und kann viele Probleme lösen, die früher ohne ein Framework nur schwer zu bewältigen waren. Die Zukunft bleibt spannend!

Habt ihr bereits Erfahrungen mit Tailwind oder seid ihr Verfechter von reinem CSS? Diskutiert mit uns in den Kommentaren! Wir freuen uns auf euer Feedback.

Und nicht vergessen: Lasst uns eine Bewertung bei Apple Podcasts da oder gebt uns ein paar Sterne. Wir hören uns in zwei Wochen wieder! :)