Wir nehmen das Release von Version 2.0 von TailwindCSS als Anlass, das Framework nach längerer Zeit einmal wieder unter die Lupe zu nehmen. Als kompetenten Gast haben wir uns dafür Milan Matull ins Boot geholt, der uns durch die Ideen und Konzepte von Tailwind führt und mit dem wir über Vor- und Nachteile des Frameworks (fruchtvoll und zielführend) debattieren.
Schaunotizen
- [00:01:47] TailwindCSS 2.0
- Einleitend rekapitulieren wir noch einmal, was das erklärte Missionsziel von TailwindCSS überhaupt ist. Dabei erkennen wir einige konzeptionelle Vorläufer:
Als ehrenwerte Konkurrenz erwähnen wir:
- die Bootstrap Utilities, und
- Bulma.
Wir stellen als Hauptvorteile heraus, dass die vorgegebenen Leitplanken verhindern, dass Entwickler:innen in einem Team unterschiedliche Wege in Sachen Notationen und Eigenschaftenwahl gehen. Fifty Shades of Grey ist mit TailwindCSS nicht zu machen. Außerdem ist Tailwind im Production-Build unschlagbar klein und vor allem wächst es nicht mit zunehmendem Projekt- und Komponentenumfang. Klein bleibt klein, und damit schnell! Und zu guter Letzt ist es auch sehr angenehm, beim Komponentenbauen einfach in seinem HTML bleiben zu können, ohne zum Stylen ständig den Kontext hin zu CSS wechseln zu müssen.
Milan hat zu den Vorteilen von, und den Vor*UR*teilen gegen Tailwind aber auch ein komplettes Slidedeck am Start.
Selbstverständlich geht es in unserem Gespräch irgendwann tatsächlich auch um die Neuerungen, die Version 2 bringt. Im Wesentlichen sind das ein Dark Mode, sinnvoll vorkonfigurierte Zeilenhöhen, sinnvoll vorkonfigurierte Animations-Easings und unterlassene Hilfeleistung für den IE 11 (Custom Properties FTW!). Ansonsten gibt es von allem mehr: Mehr Farbabstufungen, mehr Grautöne, mehr Breakpoints, mehr Spacing, mehr Schriftgrößen. Wir wissen allerdings nicht, ob das gut ist, oder eher schlecht – wegen der Leitplanken und so…
Ach so, und TailwindCSS 2.0 dürfte das erste Framework mit kinoreifem Trailer sein! ?
Weitere Frameworks und Tools aus dem TailwindCSS-Dunstkreis, die spannend und Teil der Folge sind:
Die augenöffnenste Lektüre, die unser Gast mitgebracht hat, ist ein neun Jahre alter Artikel mit dem Titel About HTML semantics and front-end architecture von Nicolas Gallagher.
Einen super Kniff hingegen zeigt ein Artikel namens Composing the Uncomposable with CSS Variables von Adam Wathan.
Kommentare
Andi #
Geschrieben am 16.02.2021 um 13:00
Moin,
danke für diese Episode. Ich hatte Tailwind bereits vor zwei, drei Jahren rumgespielt und meine ersten Gehversuche unternommen und habe es mir zuletzt noch einmal etwas angesehen (https://www.youtube.com/watch?v=mQDs0ClIsD4).
Würde man meinen Standpunkt in einem Beziehungsstatus ausdrücken wollen, so wäre es „Es ist kompliziert“.
Hier meine Pro-Kontra-Liste.
Pro:
– das Design-System als solches und die Tatsache, dass es einem schwer gemacht wird aus diesem auszubrechen. Alles basiert auf einem gut ausgeklügelten, aber anpassbaren Design-System was meistens dazu führt, dass nichts wirklich schlecht aussieht. Darin sehe ich die Hauptstärke für Projekte mit kleinem oder gar keinem Design-Team irgendwas abzuliefern, was wirklich nicht schlecht aussieht
– Für Teams die keine Frontend-Kapazitäten haben und deren Fokus nicht auf CSS liegt, dann lassen sich damit einfach solide Projekte bauen
– Für Prototyping oder eben für Leute die CSS nicht mögen (IMHO nicht zu unterschätzen) etwas zusammenbauen, was einfach gut aussieht
– Community ist gefühlt riesig und es gibt viele nette Spielereien und Tools hierfür
Contra:
– Maintainability: Was Stefan sagt… wie soll ich mir Maintainability über Jahre damit vorstellen mit HTML Dateien und mehreren zig CSS Klassen die an Elemente dran geklöppelt sind
– Tailwind Updates: Was passiert wenn Tailwind entscheidet verschiedene CSS Klassen umzubennen? Soweit ich weiß ist das in der Vergangenheit zumindest schon passiert. Klar im Zweifel nur string replace, aber trotzdem fragwürdig für eine CSS Klasse die am Ende nur ein `font-size: 2em` setzt.
– Kaskade: Nicht mehr vorhanden, aber auch gleiches Problem mit React Styled Components etc. Ist eher ein genereller Trend, dass die Kaskade einfach den Bach runter fällt.
– CSS verlernen: Für manche ein Pluspunkt, aber auch ein Contrapunkt. Man lernt kein CSS mehr sondern ballert sein HTML einfach mit den entsprechenden Tailwind-Klassen zu. D.h. man entscheidet sich dazu lieber die Utilityklassen von Tailwind zu erlernen, anstelle `font-size: 2em` im CSS zu schreiben? Ich halte das einfach generell für fragwürdig. Klar für Backend-Entwickler die ein Frontend pflegen müssen, ist das wahrscheinlich eine Erleichterung und sinnvoll, aber als reiner Frontend-Entwickler sehe ich das problematisch. Wenn es neue CSS standards gibt, wartet man dann bis Tailwind eine Utility-Klasse dafür eingebaut hat?
TL; DR: Ich sehe den hauptsächlichen Selling-Point in dem eigentlichen Design-System hinter Tailwind und ich würde es sehr begrüßen, wenn es eine Auskopplung dessen geben würde, damit man die Design-Logik dahinter auch in anderen Projekten nutzen könnte. In diesem System sehe ich den meisten Mehrwert, weil sich dort einfach viele Personen Gedanken über gutes Design gemacht haben. Und meiner Meinung nach ist das auch der Hauptgrund für den Hype rund um Tailwind. Es sieht einfach immer gut aus, wenn man damit was baut. Das liegt aber IMHO nicht an den Utility-Klassen, aber eher an dem ganzen Gehirnschmalz der in das Design-System geflossen ist.
Der Utility-First Ansatz hat für mich einige Anwendungsfälle fürs Prototyping oder einfach wenn es kein reines Frontend-Team gibt, aber das Ergebnis dennoch gut aussehen soll. Dann bedient man sich Tailwind und haut die CSS Klassen ins HTML (template) weil man da ja evtl. eh als PHP, Python etc. Entwickler damit zu tun hat und muss keine CSS Dateien erstellen und anfassen. D’accord.
Aber als Frontendentwickler stellen sich mir persönlich die Nackenhaare, wenn ab jetzt Tailwind das Maß aller Dinge ist.
Daniel #
Geschrieben am 18.02.2021 um 19:43
Interessante Folge, auch wenn mir etwas der kritische Diskurs gefehlt hat. Ich möchte Andis Kommentar zustimmen, da ich seine Bedenken ebenfalls teile. CSS ist aus meiner Sicht eine geniale Abstraktion, unglaublich ausdrucksstark und dank guter Browserunterstüzung inzwischen weitgehend schmerzfrei zu schreiben.
Auch wenn ich die Attraktivität in gewissem Rahmen nachvollziehen kann (durchdachtes + ästhetisches Designsystem, gut für Team-Konventionen, schnelles iterieren etc.) wiegen mir die Nachteile recht schwer.
Meine Gegenargumente sind wie folgt:
– Leaky Abstraktion: es ist und bleibt eine weitere Abstraktionsschicht … welche in diesem Fall „leaked“. D.h. am Ende (bei echten Problemen) komme ich nicht umhin zu verstehen, wie CSS wirklich funktioniert. Siehe https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
– Das Verlernen bzw. „falsch“ lernen. Wenn Junioren CSS nur noch über Tailwind kennenlernen wäre das traurig (ähnlich der Trend nur noch JS-Frameworks zu lehren, statt Grundlagenverständnis zu fördern), da sie den eigentlichen Zauber des klassischen CSS (Kaskade, Selektoren, Ausdrucksfähigkeit uvm.) überhaupt nicht kennenlernen. Ja, die Lernkurve ist nicht zu verachten, aber definitiv machbar – vor allem wenn man sich mental wirklich darauf einlässt und nicht dagegen kämpft.
– Maintainability: schwer zu sagen, aber ich bin gespannt, wie in 5-10 Jahren auf Tailwind Syntax geschaut wird. Fakt ist: auch dann wird normales CSS problemlos les- und wartbar sein. Ob man das von Tailwindigen Templates sagen kann? Wir werden sehen. Wirkliche langfrisitige Projekte sollten vorsichtig sein, solche starke Konventionen mit an Bord zu holen.
– Debugging: Sehr gutes Argument von Stefan! Klassische CSS Debugging-Strategien sind nicht ohne weiteres anwendbar. Die Obfuscation nimmt weiter zu.
Und noch zum Thema BEM/Scoping bei klassischen CSS Lösungen: Das ist (zumindest im Kontext von JS Frameworks/SPAs) prima durch css-modules erschlagen. In Kombination mit ein paar(!) sinnvollen globalen Utility-Klassen braucht man sich da über Klassennamen kaum tiefere Gedanken machen. Wenn css modules nicht anwendbar sind, bleibt BEM weiterhin eine gute Lösung.
Tailwind trifft offenbar den Puls und ist sicher der richtige Hammer für manche Nägel. Es jedoch unreflektiert aus Hype-Gründen oder schlicht der simplen Abneigung gegenüber CSS (soll es ja geben ;) zu wählen, finde ich schade. Wie Andi schreibt, das spannende hinter Tailwind ist das gut durchdachte Designsystem und die „sensible defaults“. Vielleicht ergeben sich daraus neue Ansätze in der CSS-Framework Szene.
André Lademann #
Geschrieben am 17.02.2021 um 15:16
Hi!
mit Utlity-Klassen kann man letzlich im preprocessor wie less/sass individuelle Komponenten mit @extend zusammenstellen. Das finde ich ganz scharmant. Für den Production build könnte man dann die Utility-Klassen „abschütteln“.
Ich dachte bis eben, dass Bootstrap das genau so macht, dass sie ihre eigenen Utility-Klassen benutzen um dir vorgefährtigte Komponenten anzubieten die du nutzen kannst. Aber ist (noch?) nicht so; Beispiel: https://github.com/twbs/bootstrap/blob/main/scss/_buttons.scss
Beste Grüße
André
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.