Working Draft

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.