Revision 722: Tailwind versus BEM, mit Jon Uhlmann

0:00Tailwind war ja oder ist vor allem meiner Meinung nach so erfolgreich im Vergleich zu allen anderen, weil sie halt geschafft haben, eine saubere Dokumentation rauszuhauen. Man kann irgendwelche globalen Variablen setzen und überschreiben aus jeder beliebigen Zeile Code heraus. Nur das ist so weit entfernt von allem, was wir auch nur entfernt in Betracht ziehen, dass es aus unserer Realität so weit rausdefiniert ist. Sollten wir unseren Code optimieren, damit Agents ihn gut lösen können, das können dann eher Projekte und Firmen für sich selber klären.

0:29Aber ich würde es auch gerne hier mal in den Raum werfen. Diese Revision von Working Draft wird euch präsentiert von Midwald. Next Level Container Hosting für eure Projekte. Wie euch bestimmt nicht entgangen ist, reden alle überall und ständig über Automatisierung und Self-Hosting. Und das klingt auch immer alles voll super, wenn es denn mal eingerichtet ist und läuft. Nur über diesen Schritt redet fast keiner, weil er meist kompliziert und anstrengend ist.

0:53Aber es gibt eine Ausnahme und das ist Midwald's Container Hosting. Und das funktioniert so. Erster Schritt, in Midwald's M-Studio einloggen. Ganz einfach und bequem direkt im Browser. Zweitens, fünf Minuten für die Konfiguration eures Containers aufwenden. Mehr Zeit braucht ihr nicht, denn ihr könnt die meisten Vorschläge für Entry-Points und Umgebungsvariablen einfach direkt übernehmen. Dritter Schritt, äh, euer Container läuft. Ihr seid fertig. Das war's.

1:16Von Nerds für Nerds bringt euch Midwald das Beste, was Container-Hosting zu bieten hat. Nämlich eure Eintrittskarte ins Automatisierungs-Wunderland. Deployt ganz einfach, was ihr wollt, wie ihr wollt. Und alles dazu findet ihr auf. mittwald.de slash workingdraft. Das war nochmal mittwald.de slash workingdraft. Wir danken Mittwald für die Unterstützung von dieser Revision von Working Draft. Revision 722. Wir sind heute zu viert. Richtig viele Leute aus dem Team haben wir dabei. Die Vanessa.

1:54Hallo Vanessa. Hallo. Dann haben wir den Peter. Hallo Peter. Moin Moin. Ich bin der Shep und wir haben einen Gast und zwar den John Ullmann. Hallo John. Hallo. Du bist schon ganz, ganz oft bei uns Gast gewesen. Mindestens viermal haben wir gesehen. Ich glaube, du musst dich, also willst du dich nochmal kurz vorstellen? Mach mal. Aber eigentlich ist es nicht nötig, glaube ich. Ja, ich mache halt seit mehreren Jahrzehnten, schiebe ich Pixel umher mit CSS.

2:22Und noch andere Sachen. Ja, gut. Perfekt. Das ist eine schöne Beschreibung. Die hätte ich auch gerne. Genau, und es geht auch um CSS. Und zwar hast du uns kontaktiert, weil du die Revision 715 dir angehört hast, irgendwann, wo wir Hörerfragen beantwortet haben und eine der Hörerfragen, da ging es darum, was unsere Meinung zu Tailwind ist und dass die fragende Person rausgehört hat, dass wir vielleicht Tailwind nicht ganz so super duper finden, und genau, der Peter und ich haben darüber diskutiert und haben uns möglicherweise auch ein bisschen in Rage geredet, ich weiß es nicht.

3:05Du hast uns angeschrieben und gesagt, ja, Moment, ich sehe das so ein bisschen anders oder differenziert als ihr das wiedergegeben habt und genau darum bist du da und, die vanessa sieht das auch anders als wir glaube ich, und genau jetzt wollen wir wollen wir das ganze noch mal also quasi tailwind versus. Weiß wie man es nennt klassisches css das thema könnten wir jetzt noch mal aufmachen zusammen. Um das nochmal so zusammenzufassen, ich bin Tailwind gegenüber so relativ neutral eingestellt, würde ich sagen, Peter fragt sich ein bisschen eher, was Tailwinds Daseinsberechtigung ist. Kann man das so sagen?

3:53Wenn ich jetzt natürlich wüsste, was ich in der angesprochenen Sendung gesagt hätte, wäre das von Vorteil. Einiges. Aber grundsätzlich kann ich jetzt erstmal gegen diese Aussage jetzt nicht erheblichen Einspruch einheben. Also lassen wir das mal so durchgehen fürs Erste als Arbeitsgrundlage. Ich habe mir in der letzten halben Stunde nochmal die Minuten, ich glaube die letzten 30 Minuten waren das von der Aufnahme angehört. Und was gesagt wurde, dass Tailwind dafür auch hilfreich ist, wenn es an Skills mangelt.

4:24Und es wurde auch positiv hervorgehoben, dass es jetzt mal zumindest das unterste Level auch schon so ein bisschen anhebt, sodass es nicht mehr ganz so gerattelig wird, aber zumindest dann auf Tailwind-Niveau. Und ich denke, die Perspektive, die ein bisschen gefehlt hat, wofür wir heute wahrscheinlich dann da sind, ist nochmal herauszukristallisieren, ob Tailwind dabei auch tatsächlich Vorteile mit sich bringt, mehr als nur Skillmangel zu ersetzen.

4:53Und was ihr beiden sehr hoch gelobt habt, war Bäm und dass man ja Bäm schon eigentlich in drei Minuten beibringen könnte und damit läuft es immer ganz gut. Während Talvin vielleicht auch doch ein bisschen komplexer sein könnte. Das wurde mehr gesagt, aber das war der Kern, den ich so rausgenommen habe, aber dann leite ich vielleicht gleich mal an schon weiter, was du denn da gedacht hast, als du zugehört hattest. Genau, wenn ich ganz kurz ausholen darf. Ich habe vor ein paar Jahren durfte ich an einer Konferenz oder an mehreren Konferenzen, das war einer der Talks, wo ich mehrmals halten durfte, über Tailwind und Alpine Jazz gehalten.

5:35Gut, Alpine Jazz war dann in den letzten fünf Minuten. So quasi, schau hier, reaktiv, ist geil. Aber voran habe ich da ein bisschen rausgearbeitet, wie ist das auch entstanden und, was sind die Vorteile davon, auch gegenüber BEM. Und ich sehe halt Tailwind jetzt nicht so als BEM-Ersatz, sondern, also sage jetzt nicht, BEM ist grundsätzlich schlecht, sondern ich verwende es auch immer noch für gewisse Sachen, wo halt Tailwind dann auch zu mühsam wäre.

6:08Ich glaube, das muss man ein bisschen lernen, wo setze ich jetzt was ein. Tailwind ist halt für mich so ein, ist halt das Tool, was jetzt die meisten kennen. Aber es gibt natürlich ganz, ganz viele andere Utility-First-Frameworks. Mein Bootstrap ist jetzt auch ein bisschen auf die Schiene aufgesprungen. Meiner Meinung nach ist es ein bisschen halbherzig. Aber ja, wo ich vor allem nicht so einverstanden war, war für mich so, dass ja, es ist jetzt für Anfänger leichter, weil, ich ja mit Tailwind, jetzt unabhängig, ob ich die Klassen im Markup schreibe oder im CSS, Ich muss quasi wissen, was macht jetzt diese eine CSS-Eigenschaft, also was macht jetzt dieses Marching.

6:54Was es sicher hilft, ist, einen gewissen vertikalen Rhythmus hinzukriegen mit Abständen, wenn man da diese ein bisschen einhält. Oder ich schreibe halt sehr viel auch eigene Tailwind-Plugins für meine Systeme, weil es ein bisschen advancer ist noch. Aber. Das hilft sicher dort, diesen vertikalen Rhythmus einzuhalten. Aber ich muss ehrlich gestehen, ich habe durch Tailwind viele Sachen gelernt, so okay, das ist jetzt schon stable, das kann man jetzt wirklich schon verwenden, cool, und ich habe auch, obwohl ich schon diverse Buckle auf dem Rücken habe mit CSS auch gemerkt, okay, dieses Property das kannte ich noch gar nicht, zum Beispiel diese Isolation, Isolate Geschichte, wo man nicht immer Positionen relativ verwenden muss und, das ein neues Fass aufmacht, dass andere Probleme bewirken kann.

7:48Es war zwar ein Beispiel, also ich habe da schon auch neue Properties kennengelernt, was ich eigentlich ganz cool fand. Aber so der Punkt, dass es jetzt hilft, weniger hässliche Webseiten zu machen, in Sachen Farben vielleicht, okay, weil man da gewisse Abstände hat und die, leicht einhalten kann wegen Lesbarkeit, okay. Aber es ist natürlich auch sehr leicht möglich, mit Tailwind ganz hässliche Seiten zu machen, wie mit jedem anderen System.

8:19Und um das so ein bisschen zu vergleichen. Kann man ja sagen, wenn wir jetzt mit Kochen als Vergleich ist so Bäm vielleicht, ja du musst alles selber einkaufen, du musst dir alles selber deine Mengen zurechtsuchen und das dann zurechtschnippeln und machen und tun und dann kochst du dein Essen und hoffst, es ist gut. Auch dort kann es natürlich schlecht werden. Tailwind ist dann für mich so ein bisschen wie HelloFresh, heißt das, glaube ich. Ich kriege eine Box geliefert, es ist alles schon von den Mengen her ready.

8:57Ich muss auch immer noch schnippeln, ich muss immer noch alles bereit machen. Und natürlich gibt es danach noch so andere Frameworks, so Daisy UI und wie sie auch alle heißen, wo ich dann sagen kann, ja gut, ich schmeiße es einfach in die Mikrowelle und gut ist. Also dann prep my meal, dann muss ich dann gar nicht mehr viel können und das ist eigentlich mal grundsätzlich mal gut. Das ist super für, wenn Backend-Entwickler ein Frontend entwickeln müssen, dass es wenigstens einigermaßen gescheit ausschaut und Accessibility und alles eingehalten wird.

9:26Also Daisy UI wäre dann so eine Komponentenbibliothek, die Tailwind nutzt. Ja, oder es gibt ja Shadow CNN oder wie sie auch alle heißen. Es gibt ja ganz viele verschiedene. Daisy UI ist mir eingefallen, weil mir heute das über die Leber gelaufen ist, weil es jemand verwendet, wo ich das gesehen habe. Aber so ein bisschen das als Vergleich. Also für mich war so ein bisschen der Punkt, ja. Die wirklichen Vorzüge von Tailwind liegen für mich eigentlich noch in einem ganz anderen Bereich, wo vielleicht vielmals auch unterschätzt wird.

10:05Weil, wenn man ein bisschen weiß, Tailwind ist ja wirklich aus dem entstanden, ein bisschen so von der Developer Experience her, das Problem zu lösen, ja, eine HTML-Seite ist lokal und CSS ist global, wie fixen wir das Problem? Dass wenn ich jetzt eine Hard-Termal-Seite wegschmeiße, dass auch das zugehörige CSS, wenn es nicht mehr braucht, auch wegkommt. Aber es gibt zum Beispiel andere Systeme wie Techion, wo auch ein Utility-First-Framework ist.

10:33Und der hat einfach recherchiert, was ist für den Browser am leichtesten zum, Durchgehen und zum Style. Und der ist auch eigentlich auf die genau gleiche Lösung spannenderweise gekommen. Der hat dann gesagt, ja, okay, der Browser ist natürlich jetzt bei einer kleinen Seite im Minisekunden- oder Mikro-Nanosekunden-Bereich. Aber dann herausgefunden, ja, eigentlich rendert eine Seite auch schneller, wenn du viele TSS-Klassen hast, wo immer nur eine Klasse eine Sache macht.

11:03Fand ich sehr spannend, auch noch von der Seite quasi die DNG-Entstehungsgeschichte anzuschauen. Aber kannst du das mal kurz quantifizieren? Also das ist ja, was ich immer, wenn Chaps sagt, ich verfolge hier folgende absurde CSS-Syntax, weil es ist ja schneller. Und dann nehme ich den Chaps und dann drehe ich den Grillspieß so ein bisschen und dann kommt halt eben raus, dass unter irgendwelchen Edge-Case-Bedingungen vielleicht eine halbe Millisekunde an Benefit rauskommt.

11:28Ist es bei dir genauso schlimm oder ist das irgendwie mehr? Ja, ich kann dir jetzt, ehrlich gesagt, die genauen Zahlen, die müsste ich jetzt selber auch googeln oder in meinen Slides sogar nachschauen. Es ist jetzt natürlich, die Browser werden natürlich auch immer schneller. Also ich glaube, das ist inzwischen, würde ich jetzt so sagen, vernachlässigbar. Aber ist natürlich auch gut zu wissen, wenn ich jetzt ein CSS habe vollgestopft mit TAS, dass das dann schon langsamer wird, weil es natürlich von der Denkweise vom TSZ her massiv aufwendiger ist, wenn es da noch zuerst reinschauen muss, hat es das jetzt, hat es das nicht und dann, appliziere ich diese Styles oder Custom Properties.

12:12Aber so größer- und August-mäßig hast du da irgendwas, woran ich mich festhalten kann? Das müsste wahrscheinlich dann uns irgendwie... Ich meine, schneller ist ja vieles, man muss ja zum einen irgendwie quantifizieren, in welchen Bereichen bewegt man sich da grob und dann halt eben auch die Gegenprobe machen, welche Mittel muss man zu Felde führen, um diesen Benefit dann einzufahren tatsächlich. Ja, hat vielleicht keinen Tag. Also ich würde ja vermuten, dass der Unterschied wahrscheinlich gar nicht so riesig ist.

12:39Also ich glaube, die Aussage ist einfach, es schadet nicht, viele Klassen auf HTML-Elemente zu stecken. So würde ich das vielleicht eher sehen. Es gibt keinen Slowdown dadurch. Wenn man Parallelman wie BAM anwendet, nutzt man ja auch CSS-Klassen. Und das sind ja so zusammen mit Elementen und ID-Selektoren so die schnellsten Selektoren, die man in CSS haben kann. Ich glaube, das ist wahrscheinlich eher so ein, hey, auch wenn es vielleicht gewöhnungsbedürftig aussieht, so viele Klassen in ein Element zu stecken, schlägt sich das jetzt irgendwie nicht negativ auf die Performance nieder.

13:18Ich glaube, so rum würde ich das wohl eher formulieren. Ich meine, das wäre ja auch eine Größenordnung, wenn man sagt, es wird nicht schlimmer. Es ist halt vor allem der Punkt, wenn du eben einzelne Klassen hast, die ist natürlich immer schneller, was auch logisch ist, als wenn du jetzt da für diesen Verschachtelung bist und der war der, wie ist der, Adam Morse, hat dann quasi sogar noch herausgefunden, dass die, Browser ein bisschen, also noch besser performen, wenn ich dann eine Klasse habe und die macht nur eine Sache, weil es einfach weniger Abhängigkeiten zwischen den verschiedenen CSS-Klassen gibt.

13:52Was muss ich jetzt überschreiben, was ist jetzt weiter unten und so weiter und so fort. Also das ist eigentlich so die Überlegung. Und wenn man sich das so ganz klar überlegt und denkt, okay, dann habe ich jetzt BAM und dann habe ich Modifier und der ändert dann irgendein Padding durch das und so weiter und so fort, dann ist er quasi wie logisch, dass man, wenn ich auch länger zum Code lesen brauche, okay, jetzt wird es überschrieben, hat der Rechner quasi auch länger.

14:18Ja, aber ich wollte das jetzt sogar sehr gar nicht gegen BEM vergleichen, sondern mehr so überhaupt fragen, ob diese Domäne, über die wir da jetzt spezifisch sprechen, eine ist, die was wert ist. Weil auch da nehme ich halt wieder den Chat mal als Vergleichsmaßstab her. Der sagt auch immer, da kriege ich irgendwie eine halbe Millisekunde rausgekratzt, aber seine Baseline ist halt eine Web-Applikation, an der ein gewisser Chat seit Ewigkeiten arbeitet und wo halt alles, was auch nur in der Nähe von Low-Hanging Fruit ist, längst gepflückt worden ist.

14:45Die Frage stellt sich also jetzt mehr so, sind diese Optimierungen bezüglich, ist jetzt das CSS-Electoral-Matching schneller oder nicht, bezüglich der Größenordnung, gegenüber, wo kann ich meine Zeit, wenn ich irgendwie was optimieren möchte, noch reinstecken? Also mehr so, nicht wie verhält sich Tailwind zu BAM bezüglich Geschwindigkeitsbenefit, sondern wie verhält sich der Einsatz von Tailwind im Vergleich zu, ich nehme mal meine ganzen PNGs und jagge die mal nochmal eine Runde durch den Optimizer.

15:13Also ich würde ja sagen, diese Performance-Fragestellung ist ja gar kein Motivator, irgendwie zu Tailwind oder Tachyon und Co. zu greifen, oder? Aber Moment, Moment. Gerade war doch der Punkt, dass sich die Leute, die das gebaut haben, explizit angeschaut haben, wie funktioniert der Browser, was macht es dem am leichtesten und den Ansatz wählen wir. Oder? Habe ich das falsch verstanden? Das war Tachyon. Also Tachyon ist auf die Seite hergekommen, sind halt auf die gleiche Lösung gekommen wie Tailwind.

15:40Das sollte einfach mal das Einschub noch reinbringen, weil ich fand das ein spannender Gedanke. Du wirst ja schnell konfrontiert mit diesen Fragestellungen, wenn du so ein Framework rausbringst und die Leute sehen dann so ein ungewöhnliches Konstrukt, dann gibt es ja diverse, sagen wir mal, Bauchgefühle, die dann da ausgesprochen werden, und ich denke einfach, dass man dem das dann irgendwie nachgemessen hat, und dann gesagt hat, so Leute, also daran, also an der Performance wird es jetzt nicht scheitern.

16:09Ja, okay, das kann ich ja, das sehe ich ja sofort und die ganzen Klassen komprimieren ja auch gut weg im HTML und alles so einverstanden, macht es nicht schlimmer. Ich versuche halt mal irgendwie noch zu greifen, was jetzt so der... Naja, zwei Vorteile hat der John ja schon gesagt. Also das eine ist, dass sozusagen du dank der Arbeit, die der Adam Wathen und Team in dieses Framework stecken, das sozusagen immer auf Stand zu halten. Wenn du, ja, vielleicht so ein bisschen wie das früher mit jQuery war, wo man auch angefangen hat, JavaScript zu lernen, auch vor allem, wenn man dann ins jQuery reingeschaut hat, wie die das machen, dass man irgendwie sich, dass man dann irgendwann irgendwie so merkt, okay, cool, Isolation und Co, coole Features, wird überall supported, Wusste ich nicht, habe ich jetzt dazugelernt, also sozusagen.

17:00Als Anlass, als Räuberleiter irgendwie so ein paar neue CSS-Features irgendwie sich drauf zu tun. Und das andere war, was du gesagt hast, dass man eben auch leicht, Komponenten wieder loswerden kann, weil es im Grunde kein CSS gibt, was an eine Komponente gebunden ist, weil es ja im Grunde alles primitive Bausteine sind, an denen sich alle Komponenten bedienen, und es kein dediziertes, kein CSS gibt, das spezifisch für eine Komponente gebaut wurde.

17:32Sofern du, das hast du ja am Anfang gesagt, nicht dann doch eben manchmal zu, custom CSS greifst. Das kann natürlich immer passieren. Dann verlierst du da so ein bisschen den Benefit. Aber bei Tailwind gibt es ja keinen. Du kannst ja nicht in Tailwind auf die CSS-Datei zeigen in irgendeine Zeile und sagen, die Zeile gibt es im Grunde nur, oder die nächsten 100 Zeilen, die gibt es nur, weil ich diese Komponente stylen will. Das gibt es halt nicht. Mhm.

18:00Aber warte mal, das ist jetzt ja was anderes, wenn ich richtig verstehe. Also klar, das hilft ja sozusagen, dein Kram unter Kontrolle zu halten, aber jetzt sind wir ja schon bei der Ergonomie-Frage und nicht mehr bei der Performance-Frage, weil wir jetzt die Performance-Frage sozusagen abschließen mit, die ist es nicht wirklich wert, das ist zumindest jetzt nicht schlimmer, das ist ein Nicht-Faktor. Spannend war einfach, dass Techion nicht nach der Frage recherchiert hat, sondern davor.

18:25Wir haben geschaut, oder der Typ hat geschaut, was kann der Browser am schnellsten und dann ist er auf diese Lösung gekommen und dann hat er das Framework gebaut, und das fand ich halt spannend auch mal, dass so, ich meine, auf die Idee muss man kommen, ich mache ein CSS-Framework auf Basis, was der Browser am schnellsten kann. Fand ich eh schon crazy, aber fand ich jedenfalls sehr spannend, mal so zu hören oder so zu lesen. Ich glaube, der war auch sogar vor Tailwind, hat er das rausgeschmissen, dieses Ding.

18:56Tailwind ist vor allem meiner Meinung nach so erfolgreich im Vergleich zu allen anderen, weil sie halt geschafft haben, eine saubere Dokumentation rauszuhauen. Ja, und auch das bisschen das amerikanische Bam, hier sind wir und Wir haben da Trailers und wir haben, wenn wir ein neues Release machen, machen wir ein Video und alle Sachen, wie sie das machen. Aber es hat halt recht gut funktioniert. Lustigerweise war er ja auch der Typ, wo die Tailwind-Videos gemacht hat, das ist ein in Australien lebender Schweizer, wo die Videos dann immer so rausgehauen hat und er war natürlich sehr euphorisch und empathisch und hat es voller Motivation erklärt.

19:42Und ich glaube, der Typ hat Tailwind auch sehr viel geholfen, diesen Lärm zu erzeugen und die Erfolgsquote quasi zu steigern, weil ich weiß jetzt natürlich selber von meinen Open-Source-Projekten, es steht und fällt mit der Dokumentation, und es braucht arschviel Arbeit und wenn die nicht gescheit ist, dann, passiert halt nicht viel, weil wenn du da nicht weißt, wie man das auch so geniale Tool anwendet, das natürlich bringt auch nichts. Also das.

20:14Ist natürlich, war auch bei Bootstrap so, sage ich mal, die waren auch erfolgreich, aus dem Grund, weil sie eine anständige Dokumentation hatten. Und das hilft natürlich jedem, gerade Frontend-Tooling hilft es enorm, wenn das gut aufgebaut ist. Versuche. Okay, aber kann man das jetzt, also ich stimme dir erstmal grundsätzlich zu, dass die Projekte, die tatsächlich ihren Output und seien sie noch so Open Source und MRT lizenziert so quasi als Produkt behandelt. Also was du ja gerade so als den amerikanischen Ansatz bezeichnet hast.

20:44Ich bin da ja, das erwähne ich ja im Prinzip jede Folge, die ich mit Stefan aufnehme. TS Reset ist ja super, das sind irgendwie drei Zeilen Typescript, aber die Webseite sieht halt wirklich aus, als wollten sie mir ein MacBook verkaufen. Ist eine feine Sache. Das hilft halt. Aber kann man diesen Appeal-Faktor, der jetzt dadurch und durch eine gute Dokumentation ausgelöst wird, wirklich sauber davon trennen, dass zumindest sich bei mir, wenn ich durch Hacker News scrolle, oder das war zumindest bevor KI losgegangen ist, sich mir der Eindruck aufdrängt, dass die Leute nichts lieber wollen, als dass sie CSS in den Vulkan aus Herr der Ringe reinwerfen.

21:21Weil das ist ja, glaube ich, wirklich so ein Ding, das ist irgendwie so. Das ist mühsam, man kann da viel falsch machen und ich verstehe nicht so richtig, warum meine Webseite blöder aussieht als die andere. Das ist irgendwie so ein Design-Vibes-Kram. Das hätte ich lieber am liebsten alles gelöst. Und guck her, da gibt es einfach ein Produkt. Das kaufe ich mir ein, indem ich NPM-Install mache. Und dann habe ich das. Und dann kann ich Sachen schreiben, die irgendwie das Design kontrollieren. Aber ich muss mich halt eben nicht mit dem Ding befassen, von dem ich eh keine hohe Meinung habe, wie informiert oder uninformiert die auch sein mag. Aber so ist das halt eben.

21:49Ich glaube halt wirklich, es ist immer ein guter Pitch, wenn du den Leuten sagen kannst, guck mal, da ist so ein Ding, das geht ja auf den Keks. Kauf mein Produkt ein. Und dann musst du dich mit diesem Ding nicht mehr befassen. Und CSS mit seinen ganzen Nachteilen und dem Legacy und dem ganzen Globalen und man kann es schlecht warten und langsam und hast du nicht gesehen. Und dieser ganzen Komplexität ist einfach ja auch ein wunderbares Ziel, um zu sagen, ich habe hier was gebaut, guck her, das da geht damit weg.

22:13Ja, das hat ja Tailwind so zwei, oder Utility, wir benutzen Tailwind hier einfach wie Tempo, also wir reden einfach von Utility-based CSS und das quasi fast ausschließlich benutzt, wobei es ja tatsächlich manchmal sinnvoll ist, so ein bisschen Sachen zu mischen. Wobei, da würde ich noch sagen, also ich glaube, Tailwind hat ja tatsächlich so gute Serviervorschläge, also es ist ja wirklich nicht nur primitive, sondern die haben das Ganze auch noch irgendwie zusammengeschnürt zu was Schönem.

22:37Also ich glaube, dass schon ein Mehrwert da ist gegenüber vielleicht anderen, Utility-Based Frameworks. Absolut. Also Tailwind hat halt seine Standarddesigns und halt das, was ich so als den Way of Doing Things bezeichnen würde. Und wenn wir jetzt darüber diskutieren, müsste man das halt, glaube ich, entweder irgendwie explizit machen, dass man die beiden zusammen meint oder man müsste sie halt tatsächlich trennen. Der Vergleich mit Ben hinkt ja allein schon damit, dass halt Notationen dafür, wie Klassen zu schreiben sind, Und nicht mit einer eingebauten, wie hätten wir das, glaube ich, bezeichnet, Schep als irgendwie so ein unteres Limit, das man designtechnisch nicht unterschreiten kann. Das bringt halt Tailwind mit.

23:12Und das wäre halt einfach nur, wenn, schreib deine Klassen halt so, das ist da halt nicht mit drin. Schon ein Faktor, würde ich sagen, weil da muss man sich ja, das ist meine Theorie ja, noch weniger mit diesem Kram befassen. Weil, düpp, düpp, düpp, Legosteine, sieht einigermaßen aus, just ship it. Genau, aber die Vanessa wollte noch was erzählen. Tailwind CSS ist ja weiterhin CSS. Ich muss ja eigentlich weiterhin CSS können, um damit ein gutes Design machen zu können. Ich habe ein bisschen eine andere Denkweise jetzt erst mal.

23:43Ich lasse das jetzt mal kurz ausgeklammert, dass Tailwind mit Bausteinen kommt und mit vorgegebenen Spacings. Und was wahrscheinlich auch mitkommt, ist wahrscheinlich arbeitet man in einem komponentenbasierten Framework und Copy-Paste da auch gerne mal rum und hat dementsprechend automatisch schon ein bisschen ähnliches Seils in den Komponenten. Ich denke, mein größter Punkt mit den großen CSS-Dateien war tatsächlich die Wartbarkeit. Das habe ich bei Tailwind auch ein bisschen anders, denke ich.

24:14Und die Namensfindung habt ihr beim letzten Mal so angesprochen. Und ihr habt das so ein bisschen runtergespielt. Wenn einem da die Skills fehlen, dann ist das, keine Ahnung, dann kann man sich so beibringen. Ich finde aber tatsächlich auch die Wartbarkeit recht umständlich, mir jedes Mal zu überlegen, ist das jetzt der gleiche CSS-Block oder brauche ich da eine neue CSS-Klasse? Und die CSS-Klassen sind aber schon sehr ähnlich. Also ich brauche zwei CSS-Klassen, Display-Flags, Flex-Direction-Whatever, da, da, da, da, da, da.

24:52Aber so ein bisschen unterschiedlich ist es halt. Und in so großen CSS-Dateien habe ich schon das Gefühl, dass man bei jeder neuen Komponente, die man hinzufügt, sich jedes Mal die Frage stellen muss, schreibe ich dafür eine neue CSS-Klasse, oder versuche ich eine wiederzuverwenden? Ist die Frage nicht durch das Designsystem zu beantworten und ist nicht sozusagen die Strukturierung einer Datei in einer bestimmten Sprache der falsche Ort dafür?

25:23Wenn man ein Designsystem hat, wie viele Projekte erarbeitet? Haben die alle Design... Die haben alle eins, die wissen nicht alle, dass sie eins haben und die machen es selten explizit und die meisten würden davon profitieren, wenn sie es täten, aber die haben eins. Sie machen halt Designsystem falsch. Aber was du sagen willst, Vanessa, ist, dass wenn man eben den herkömmlichen Weg geht, man möglicherweise mehr als nötig dupliziert, was so CSS-Styling angeht.

25:56Oder weniger als nötig. Bei Tailwind bist du da so, ein bisschen reingezwungen, dass du mehr duplizierst, als du vielleicht mal üblicherweise als Softwareentwicklerin gelernt hast. Weil wir waren ja normalerweise, das wurden wir ja alles sehr dry erzogen. Mit Tailwind hast du schon ähnliche Fragen. Du musst schon auch überlegen, stecke ich das jetzt in die gleiche React-Vue.js-Komponente oder schreibe ich eine neue Komponente dafür. Je älter ich werde, desto mehr werde ich ungefähr von einfach duplizieren und nicht so versuchen, alles generisch zu machen.

26:32Aber dadurch, dass ich dann vielleicht schon zwei, drei Komponenten habe, die eben leicht unterschiedlich sind, dann haue ich halt wieder meinen Flex, Flex, Justify, Between etc. Ran. Und ja, ich fühle mich dabei auch mal so ein bisschen, ja, es sind wieder die gleichen 15 gleichen Tailwind-Klassen hier wieder dran, keine Ahnung. Aber ich habe die Entscheidung einfach schon dadurch getroffen. Und damit fahre ich auch ein bisschen leichter. Als in der Vergangenheit von noch, keine Ahnung, vor sieben, acht Jahren, wo ich wirklich größere Webseiten versucht habe zu maintainen und ich habe mir gern diesen UI-Kopfhut aufgezogen, aber, ich hatte wirklich viele Stunden, wo ich mir auch den Kopf zerbrochen habe, gehört das jetzt zusammen in eine BEM-Klasse, wie nenne ich die jetzt wirklich, damit die generisch genug funktioniert oder mache ich eine neue und ist das jetzt ein Blog oder ist das jetzt was anderes und dann komme ich an den Punkt, ja eigentlich würde ich es gerne wiederverwenden, Aber das hätte jetzt einen ganzen neuen Namen verdient.

27:25Und dann muss ich relativ viel refactoren und umschreiben. Und sobald mein CSS getrennt ist vom HTML, habe ich gefühlt da immer so ein Risiko dabei. Weil ich hatte zumindest damals nicht, vielleicht fehlen mir da jetzt vielleicht ein paar Skills. War mir nie sicher, wenn ich das jetzt hier ändere, hat es wirklich nur Effekt auf diesen einen Bereich. Ich musste sehr viel manuell testen. Bei Tailwind habe ich das nicht, weil da klebt es an dem HTML dran.

27:50Das kann nichts anderes beeinflussen und ist leichter zu handhaben. Könnte man jetzt argumentieren, dass dann Skills fehlen? Vielleicht, aber nach doch relativ vielen Jahren Erfahrung in Teams. Habe ich positivere Erfahrungen da mit weniger Komplexität, gefunden, wenn man halt tatsächlich einfach die Utility-based Klassen, das hat andere Nachteile, die können wir vielleicht auch nochmal durchgehen, wenn wir möchten. Mit Tailwind kommt andere Nachteile, aber irgendwie haben den Vorteil, dass ich nicht mehr diese großen Blöcke maintainen muss, haben bei mir doch überwiegt. Mhm.

28:35Meine Erfahrung, wo ich hatte mit verschiedenen Leuten im Team, war, dass du nicht schaffst, dass jeder das gleiche Level oder die gleiche Liebe zu CSS hat. Ich bezeichne mich gerne als CSS-Nerd. Ich liebe CSS. Ich weiß nicht, wo das rausgekommen ist. Da habe ich gedacht, das werde ich nie schaffen, das werde ich nie verstehen. Dann habe ich es doch immer mal verstanden und am Schluss habe ich an einer Fachhochschule das Zeug unterrichtet. Aber du hast halt in einem Team immer verschiedene Levels und da hat jetzt Tailwind auch bei uns enorm geholfen. Also ich habe auch ein eigenes Projekt, wo ich aus Versehen quasi entwickelt habe.

29:20Und das besteht dann aus ganz vielen Komponenten, Inhaltselementen, wo man sich dann auswählen kann. Und je nachdem, welche Installation man hat, wird dann halt die CS-Datei kleiner oder größer, weil wenn sie nicht da ist, findet Tailwind CSS die Klassen nicht und schreibt es nicht, wenn nicht nötig. Das heißt, jeder hat immer nur das, was er braucht. Das ist der Riesenvorteil. Eine Art Tree-Shaking, ne? Genau, dieses Tree-Shaking. Das ist ja auch erst bei den neueren Tailwind-Versionen, ab Version 3 war das dann in Anständigkeit, aber war es immer ein bisschen mühsam. und, auch der Visionssprung auf Tailwind 4 war dann für mich nochmal ein großer Benefit, weil man es dann endlich so schreibt, wie man es auch in der CSS-Datei schreibt und nicht so, wie es liest, weil das wissen ja viele nicht, CSS liest sich von rechts nach links, aber du schreibst es von links nach rechts, jedenfalls wir.

30:13Und das wurde dann auch angeglichen, das hat es dann auch einfacher gemacht zu schreiben. Aber ich glaube, das Problem, wo für mich Tailwind CS es wirklich größtenteils gelöst hat, ist, dass wenn ich jetzt ein Projekt habe, egal ob Vue, React oder andere Sprachen, Twig, was es alles gibt, und mir ist es Fusion, wo ich arbeite ja mit Neos, ist das ja quasi ein HTML immer lokal ist. Also ich habe eine Ansicht, das ist ein HTML und da sind die Klassen drauf, aber CSS ist in der Regel global. Das heißt, du hast über die ganze Seite, vielleicht über mehrere Dateien, natürlich, wo du es dynamisch reinlädst, macht man halt ja alles auch.

30:56Trotzdem ist CSS per se immer global, das heißt, wenn ich jetzt eine neue CSS-Datei lade dann kann die andere CSS von mir überschreiben und wir haben ein Projekt gehabt. Von einem Verlag die haben einerseits Redakteure gehabt, wo ihre 50 Artikel pro Tag produzieren und da war ein anderer Typ, das war so ein bisschen ein, früher hat man eben gesagt, Webmaster, der konnte auf HTML und der musste dann halt so gewisse Layout-Seiten speziell gestalten.

31:28Und der musste so viele verschiedene Inhalts-Elemente bauen, dass wir gesagt haben, wir können nicht jedes Inhalts-Element den bauen, weil das sieht jedes anders aus. Und dann haben wir den Monaco-Editor bei uns im Becken integriert mit Tailwind, Autocompletion und allem Möglichen drin, mit einer Vorschau, wo er dann auch die anderen Prototypes oder Komponenten verwenden konnte. Und das hat dann bei ihm enorm geholfen, weil er auf einmal nicht mehr CSS schreiben musste, sondern sich quasi Bilder an dem orientieren konnte, was eh schon da war und das wiederverwenden konnte.

32:08Und dann haben wir es einfach so gemacht, okay, jetzt hat er ein neues Inhalts-Element gebaut und hat gesagt, jetzt will ich das live publizieren. Und dann ist im Hintergrund schnell der Check durchgerannt und hat geschaut, oh, habe ich neue CSS-Klassen? Wenn ja, schreibe ich das CSS-File neu, lösche die Caches vom Hash-Wert hintendran, dass das auch wirklich live geht. Und das Ding war live. Und das hat enorm geholfen, die Qualität vom visuellen Markup oder von der visuellen Darstellung zu steigern, weil wir auf einmal eine Farbkonsistenz drin hatten, weil wir eine Konsistenz drin hatten von den Abständen, alle Geschichten.

32:42Und das ist ein bisschen der Punkt, dass ich halt in keinem Team bis jetzt erlebt habe, dass jeder sagt, ja CSS, ich liebe das. Viele schlagen ja das mit JavaScript. Aber CSS kann halt inzwischen so viel, dass ich eigentlich schon sagen kann, ja, wenn du ein bisschen HTML-Markup kannst und mit CSS kombinierst, kannst du sehr viele JavaScript-Frameworks mal gleich wegkicken, sprich, Modals, also Dialogboxen, Pop-Ups, Anchors, all die Geschichten. Da kannst du heute wirklich sehr, sehr geile Geschichten machen.

33:17Und deswegen finde ich ja das Thema CSS generell spannend, weil es ja meiner Meinung nach mehr wächst sogar als JavaScript, weil gut, JavaScript, da kommt manchmal eine neue Array-Funktion hinzu und, noch blablabla, aber so im Großen und Ganzen ist es ein bisschen ruhiger geworden. Fühlt sich das schon relativ, ist ruhiger geworden, fühlt sich auch ein bisschen fertig an, so was, okay, was wollen wir noch? Wird noch irgendwie eine API angebunden, wo dann wieder abgestellt wird wegen Sicherheitsbedenken oder wegen Fingerprinting, so fühlt sich jedenfalls immer ein bisschen an.

33:54Aber bei CSS passiert halt schon momentan extrem viel also gerade eben, auch von der von dieser UI Open UI Initiative wo dann immer wieder neue Sachen reinkommen was auch extrem geil ist, und finde ich bei Tailwind ja bei jedem Tailwind Projekt wäre es halt gut wenn jedem Tailwind Projekt ein CSS Nerd hätte und ein bisschen das Auge drauf hätte, hat auch bei den Pull-Requests oder auch eigene, Tailwind-Plugins schreiben kann, was ja auch sehr viel einfacher geworden ist mit der Version 4.

34:32Also jedenfalls ist es auch besser lesbar und verständlicher für alle. Davor war das ja JavaScript pur und das war manchmal schon ein Pain in the Ass. War bei mir jedenfalls so, wenn ich dann nach einem halben Jahr wieder drauf geschaut habe, dass ich gedacht habe, meine Güte, was mache ich da eigentlich genau? Und ist jetzt schon einfacher geworden. Aber genau weil das halt jetzt so einfacher weiterbar ist mit den eigenen Funktionen, wo du dann dazu schmeißen kannst, kannst du auch im Tailwind sagen, ja egal ob die das jetzt schon unterstützen, dieses neue Anchor-Feature oder, Pop-Up-Modal-Dialog-Feature, ich kann es sehr schnell verwenden und mir eigentlich dann auch sehr viel JavaScript ersparen, was wiederum dann auch performance-mäßig spannend ist, weil wenn es der Browser einfach so kann und ich das dänisch beibringen muss, ist es für mich halt ein riesen Benefit.

35:28Klar, kann man mit BEM auch machen oder mit anderen Notationen. Nur wenn ich jetzt eben ein Editor habe, wo dann auch diese Automoblition drin habe und jetzt kommt jemand, wo das vielleicht noch nicht so auf Lunge geraucht hat, das ganze System, wird dem quasi auch vorgeschlagen, hey, du hast noch die Klasse, wenn Pop-Over-Open oder Starting-Style und all die Geschichten. Das macht es dann halt auch ein bisschen angenehmer für diese Leute, wo jetzt nicht so oberfit sind im CSS und sie quasi kann sie auch, so jedenfalls wie es erlebt, kann sie dann auch motivieren, die CSS-Only-Lösung zu fahren und nicht unbedingt, ich schmeiße jetzt da wieder ein JavaScript-Framework drauf, wo mir eine Klasse er draufsetzt, wenn jetzt dieses Form-Input invalid ist, sondern ich kann es einfach per CSS lösen.

36:22Und das ist so ein bisschen meine Erfahrung, wo ich hatte, wo es wieder dem beistimmt, wo er sagt, ja, es hilft halt schon, wenn ich jetzt nicht so fit bin in jedem Bereich, im CSS-Bereich, durch die Autocompletion Sachen zu verwenden, wo ich sonst vielleicht nicht verwenden würde. Aber es steigert für mich ein bisschen die Qualität dann, wenn jetzt jemand vom Team halt eine Komponente entwickelt, wo nicht so fit ist in dem Bereich. Der Peter, der schart schon hier, der ist schon ganz...

36:53Nein, nein, nein, nein, nein, nein, pass auf, pass auf, pass auf, ich mache nur gerade einen Fact-Check, weil ich mir gerade nicht sicher war, ob ich spinne, aber ich gucke gerade hier, ich habe gerade Visual Studio Code aufgemacht, habe eine random HTML-Datei aufgemacht und dann ein Style-Tag reingemacht und ich kriege ja irgendwie auch, CSS-Auto-Completion sehe ich da jetzt gerade. Ja, genau, wahrscheinlich ist es, aber es ist einfach sozusagen nicht, also ich glaube, bei Tailwind kriegst du halt so Tokens, die halt mehrere Dinge zusammen kombinieren und vielleicht auch irgendwelche Fallbacks integrieren.

37:26Also das hast du halt wahrscheinlich, hast du halt einfach nicht, wenn du, also es macht es so ein bisschen, bringt so ein bisschen mehr Convenience, würde ich sagen. Ich würde den anderen Laptop rausholen, wo ich Cloud installiert habe und gucken, ob das da nicht zufälligerweise auch kommt mit CSS. Müssen wir mal gucken. Ja, ich finde so ein klassisches Beispiel, wo man auch Schüler fragen kann, wo es noch nicht so lange geht, aber ich ein voll geiles Ding finde, sind ja diese Color Functions, wo ich sagen kann, hey, nimm die Current Color und mach sie 50% transparent.

38:02Ist halt in Tailwind schon sehr einfach, da sage ich Text Current Slash 50 und dann ist das die Current Call auf 50%, das kann ich einem CSS-Newbie sehr leicht beibringen, klar. Und das Coole ist, wenn er die Maus rüberfährt und er sieht das dann, okay, das schreibt die und die Klasse, so funktioniert das, der lernt dann quasi automatisch Learning by Doing, aber so aus dem Stehgreif. Zu sagen, ja okay, in OKCH, Current Color und jetzt nimm die Farbe und 50% Alpha transparent dazuschmeißen, das kann da nicht jeder, also ich glaube, wenn ich jetzt überlege, könntest du auch nicht direkt aus dem Stehgreif einfach so aufschreiben, müsst auch überlegen, okay, wie geht das jetzt nochmal genau, weil du ja ganz viel hast in die Geschichte und das sind dann so Sachen, wo ich schon recht cool finde, wo auch den Leuten halt hilft, Sachen zu verwenden und nicht hundertmal die gleiche Farbe definieren zu müssen, sondern quasi mit diesen komponentenbasierten Sachen zu arbeiten.

39:09Und ja, ich habe für mich Tailwind ein bisschen so erweitert, dass ich so ein Data-Theme habe, wo ich dann Main, Minor oder Primary, Secondary nennen sie es, wie es willst, anhängen kann. Und dann färbt sich der Button je nachdem in der verschiedenen Farben und hat dann eben diese verschiedenen Farben Auszeichnungen. Und wenn man dann eben mit diesen Kniffs arbeiten kann, wird es dann schon relativ einfach und leicht auch zu handeln und auch im Frontend leicht zu beprüfen, okay, jetzt hat der Button diese, Data-Theme dran und dann schalten quasi die Custom-Properties um und dann ändern sich die komplette Erscheinungsbild, egal ob es ein Hero ist oder ob es ein Button ist oder was auch immer.

39:52Das ist schon, eigentlich finde ich, extrem angenehm zu arbeiten. Und logisch, alles, was wir besprechen, ist ja nicht ein Tailwind-only-Feature, weil Tailwind ist ja unterm Strich auch nur einfach CSS. Also man kann jetzt nicht sagen, du kannst mit Tailwind-Sachen machen, was du mit CSS nicht kannst. Eher andersrum, aber es hilft halt diese, dem Editor wird halt wirklich geholfen, diesen Pain herauszunehmen aus. Ich habe das globale CSS und das lokale HTML und das war meiner Meinung nach auch dieser Haupterfindungsgrund von Tailwind, diesen Schmerz quasi zu beseitigen.

40:39Und für mich jetzt auch in meiner Entwicklungsumgebung finde ich es angenehm, weil ich mische dann manchmal auch ein paar Svelte-Komponenten dazu, wo ein bisschen komplexere Sachen machen. also Widget-mäßig. Und wenn ich dort dann auch wieder Tailwind verwenden kann und ich muss nicht nochmal Styles generieren, wo ich dann nochmal reinziehen muss, sondern, die Klassen sind eh schon vorhanden und entspricht eh so ein bisschen dem Stil vom Design, wie ich es aufbaue, dann wird die Svelte-Komponente gar nicht grösser, sondern hat eh schon diese Tailwind-Klassen drin und fertig und gut ist.

41:14Und wenn die Komponente des Widgets nicht verwendet ist, dann ist es halt nicht da und es passt auch. Und das ist für mich halt so das auch Coole, wenn du jetzt eben ein Projekt hast, wo du nicht nur React oder Vue oder Svelte oder was auch immer verwendest, sondern auch vielleicht so ein gemixtes Umfeld hast mit Widgets, wie Svelte zum Beispiel halt ein bisschen auch entstanden ist. Du hast eigentlich ein klassisches Templating und dann kommen da noch diese dynamischen Komponenten hinzu.

41:46Das ist halt dann für mich ein Riesenvorteil, weil auf einmal die CSS-Datei dann massiv geschwumpft ist und ich wusste, dass wo eine CSS-Datei drin ist, das benötige ich wirklich und sonst nichts mehr. Das ist halt dann schon sehr, sehr nice. Und Frank, das ist dann aber auch wieder ein bisschen natürlich die Obhut des CSS-Nerds, sage ich mal, wenn du es ein bisschen clever aufbaust mit, Custom Properties und nur noch Custom Properties steuerst durch gewisse Klassen, wo dann sehr viel umstellen, farbtechnisch oder abständetechnisch kannst du dann diese Tailwind-Klassen nochmal reduzieren.

42:28Was es dann auch wieder ganz angenehm macht zu bearbeiten und du das Zeug auch sehr dynamisch aufbauen kannst. Du kannst dir sagen, der Redakteur kann wählen, ja, ich habe jetzt fünf Spalten, ich habe vier Spalten, Bento Box und wie und egal. Ich setze nur noch ein Custom Property aufs Element als Teil und fertig und der Rest sind die Klassen. Das wächst dann nicht immer mit jeder Variante, wo ich dann erstellen muss. Das ist halt dann schon sehr, sehr nice.

42:59Wenn jetzt kurz Stille ist, eröffne ich jetzt gleich mal noch das nächste gefährliche Thema. Und zwar haben wir, denke ich, ich unterstelle uns das jetzt einmal, dass wir alle wahrscheinlich eher schlechte Erfahrungen damit gemacht haben, Frontends mit AI zu generieren. Und ich meine jetzt tatsächlich das CSS-lastige Frontend und nicht den JavaScript-Gedöns dazu. Und am Anfang dachte ich noch, das liegt dran, dass die Agents können das halt nicht ausprobieren, also installiere ich mir Playrate-MCPs, damit verbratet man auch gerne ein bisschen Tokens, damit die Screenshots erstellen und sich das noch irgendwie anschauen können, dann stolpert man über Probleme wie, aber dafür muss ich erstmal das Mutter, um Gottes willen, jetzt muss ich mich erstmal einloggen, jetzt schreibe ich ihr irgendwie schon, Integration-Specs und End-to-End-Tests, nur damit der Agent sich was anschauen kann.

43:52Gleichzeitig habe ich aber aus der Community gehört, so schöne Sitzige, man braucht jetzt keine Frontend-Developer mehr, das kann mir ja alles in Agents geben, wo ich mir dachte, Frontend ist doch das Schwerste für AI, das ist ja der Teil, den ich noch selber machen muss. Und da ist mir aufgefallen, klar, erstmal Greenfield ist natürlich immer alles super simpel, da braucht man nicht drüber reden. Aber ein großer Unterschied ist, dass dann die Agents schon sowas wie Tailwind verwenden.

44:18Ah, ist gut dokumentiert, aber ist das jetzt wirklich der Kronen, gibt halt viele Beispiele, keine Ahnung. Ich denke aber, dass da vielleicht die AI sehr menschlich ist und ebenfalls die Probleme hat, solche CSS-Klassen zu verstehen, wie Card, Wrapper, Inner, Container, Bordered-Variant. Und da ist es dann doch irgendwie einfacher zu lesen, ist eine Karte, hat einen Border, ist egal, ist halt irgendwie sowas. Und ja. Die Frage, die ich jetzt so im Raum stelle, ist es vielleicht halt dann tatsächlich sinnvoller, was zu benutzen, was für eine größere Masse an Menschen und Agents einfacher ist, zu lesen und zu warten und zu benutzen, als irgendwas, was mir die Möglichkeiten gibt, wirklich schöne, elegante Lösungen zu schreiben, wo sowas wie CSS Grid ganz einfach verwendbar ist, was ich bei Tailwind immer noch so ein bisschen Hickey-Hackey finde und dann nimmt man halt doch wieder Flex.

45:27Und ja, ich folge halt hier, wie ich das schon rausbringe, immer so ein bisschen eher den Weg von, ich will das einfach einfach nur lesen können und einfach nur warten können und brauche nicht unbedingt die eleganteste, beste CSS-Lösung, auch wenn ich weiß, dass es da wahrscheinlich schönere Lösungen gäbe. Zusammen mit der zweiten Frage, sollten wir unseren Code optimieren, damit Agents ihn gut lösen können? Das können dann eher Projekte und Firmen für sich selber klären, Aber ich würde es auch gerne hier mal in den Raum werfen und ducke mich jetzt mal gleich vor.

45:57Es schaut keiner böse, aber ich bin gespannt, was ihr darüber denkt. Naja, ich kann ja mal den Aufschlag einer Antwort geben, der bei mir halt eigentlich immer nur der ist. Ich würde halt die Auswahl meiner Werkzeuge davon abhängig machen, welches Problem ich zu lösen habe und von relativ wenig anderem. Ich will einen Nagel in die Wand treiben, dann, okay, ja, liegt die Bohrmaschine näher und ich könnte mit der das theoretisch auch machen, aber vielleicht greife ich dann doch zum Hammer, wenn es jetzt nicht komplett unmöglich ist, einen irgendwie in den nächsten fünf Minuten aufzutreiben.

46:32Und in diesem Statement sind ja sehr viele Sachen drin, die ja so unmittelbar jetzt gar nicht zu beantworten sind mit, trifft diese Annahme zu oder nicht. Also ist das jetzt irgendwie für einen Agent oder Menschen irgendwie besser lesbar? Schwierig zu beantworten, wenn das der Fall ist. Woran liegt das? Bleibt das so oder ist das eine Momenteaufnahme? Das halte ich halt irgendwie für relativ schwer zu antizipieren, und ich habe viel zu wenig Einsicht in die Details der Implementierung von all diesen Systemen, um mir jetzt zuzutrauen, dass ich da irgendwie eine definierte Aussage zu treffe oder irgendwas Aussage auf der Basis von, ich glaube, dass das so ist weil, sagen wir mal ehrlich, ich habe keine Ahnung ich habe keine Ahnung, wie das zustande kommt, dass die Dinger per Default React und BAM machen, vielleicht ist das einfach, was sie am meisten gescrapt haben, vielleicht ist das objektiv das Sinnvollste.

47:25Vielleicht wurde die persönlich vom Facebook-Team bezahlt, ich habe keine Ahnung, aber irgendwas davon wird sein und es gibt für mich, also nicht nur weiß ich das nicht, sondern ich sehe nicht mal die Möglichkeit, wie ich ermitteln kann, was wahr ist. Und von daher definiere ich das als Not My Department. Ja, also ich muss schon sagen, AYA hat die letzten paar Monate schon sehr viel dazugelernt. Ich kann es inzwischen auch ganz anständig mit's Welt verwenden.

47:53Ohne dass irgendwelcher Objektzeug reinkommt. Das war am Anfang ja immer gern da drin. Ich habe so einen Kollegen, einen Kumpel von mir, der ist jetzt nicht Frontendler direkt, würde ich sagen. Er kann so ein bisschen, hat ein bisschen Verständnis dafür. Er kann auch gut beschreiben, was er will. Und der baut dann immer gern manchmal mit Tailwind sich die Sachen, Tailwind und AI zusammen. Und ich nehme es dann meistens als Starting Point und überarbeite es dann nochmal.

48:27Aber jetzt in dem Punkt kommt er halt weiter mit dieser Hilfe als er ohne das schaffen würde, weil der wusste zum Beispiel gar nicht dass man jetzt Aspect Trade Show dass man das irgendwie setzen kann, ich weiß nicht ob er diesen Padding Trick so gekannt hat, weiß ich jetzt nicht nehme ich mich nicht an, aber er hat halt jetzt in dem Punkt bei ihm einen Vorsprung, weil ich schon ein bisschen mehr weiß, was alles möglich ist. Und natürlich die Sachen, wo jetzt on the edge sind, oder wo ganz neu sind, und wo man auch verwenden kann, weiß ja AI auch nicht wirklich.

49:12Ich habe jetzt vor ein paar Monaten, oder letzten Monat war das, an der Neos-Konferenz ein Talk gehalten, so, your browser ist ja Superhero, schmeiß mal dieses Plugin und dieses Ding weg, weil dein Browser kann es inzwischen nativ. Und da war auch so mein Anekdote am Fluss, ja, AI kann man schlecht fragen, du kannst einfach eine Dokumentation lesen oder gewissen Leuten auf YouTube folgen, wo immer wieder so Shorts machen, wie der Kevin, wo sich jetzt inzwischen schon relativ viele Leute kennen.

49:41Kevin Povel heißt er, glaube ich, Povel, irgendwie so, aus Kanada. Der macht auch ganz nice Sachen. Ist auch nicht so ein Tailwind-Fan, habe ich gemerkt, aber ist ja völlig egal. Ich finde es cool, was er macht. Und ich glaube, das ist immer so ein bisschen das bei AI, wo man sich halt im Hinterkopf halten kann. Ja, es hat so einen gewissen Wissensstand, aber nicht jetzt so das Allerneueste. Aber vielen Leuten, wo halt zwischendurch was machen müssen, weil Not am Mann ist oder er will jetzt einfach was fertig kriegen, kann es dann halt schon auch helfen, dass sie da ein bisschen ein anständiges CSS generieren, als wenn sie jetzt da selber anfangen würden, CSS-Dateien, rumzuschieben und ganz lustige BEM-Klassen zu schreiben, wo sie dann vielleicht auch nicht wissen, oh, das wurde im Projekt schon mal verwendet und in anderen Ecken vom System fällt das Regal um.

50:38Und das wird halt durch das Vermienen. Also das ist für mich nach wie vor eines der Hauptbenefite, wenn man in Teams arbeitet, in grösseren Teams dann umso mehr, dass halt diese Konsistenz dann einfach gegeben ist und das nicht ein aus Versehen, eine BEM-Klasse nimmt, wo dann gleich heißt, die hundertste BTN-Klasse oder Button oder weiß nicht was, weil er jetzt nicht gerade gewusst hat, dass es eh schon gibt, oder die hundertste Card-Komponente.

51:08Das wird halt durch das ein bisschen vermindert. Und ja, also mein Kumpel, der würde sagen, der will jetzt nicht mehr ohne AI seine Frontend-Sachen bauen. Klar, er braucht dann jemanden, wo es dann noch sagt, ich bügel da nochmal drüber und nehme da ein bisschen unnötige Diffs weg und unnötige Klassen, wo es überhaupt keinen Sinn machen. Aber das hilft schon recht. Und was ich aber cool finde, das machen auch CSS Auto-Completion zum Teil auch schon.

51:37Aber wenn ich jetzt eine Klasse setze, wie zum Beispiel Absolut und hinten dann Relative sagt mir mein Editor, hey du das ist das gleiche Property das ist ein Fehler, schau das mal bitte an oder, du überschreibst da was, was du vorhin da gesetzt hast, bitte pass da auf, das ist schon sehr nice, dass du da ein bisschen mit dem arbeiten kannst und ja, Ja und das könnte man eigentlich noch viel weiter treiben, weil ja CSS in letzter Konsequenz eine statisch typisierte Sprache ist, und man theoretisch das ja nicht nur so inselmäßig analysieren könnte, von wegen Relative nach Absolut macht keinen Sinn, weil das kollidiert, das könnte man ja theoretisch auf alles anwenden.

52:19Man könnte das ja in einen Baum aus Typinformationen gießen und einfach irgendwie alles immer so anzeigen, wenn man da entsprechende Energie reinballern würde. Wenn man es halt mal ernst nehmen würde, tut ja keiner. Ist ja CSS, kann ja weg. Ja, aber die Browser-Hersteller, also gerade Apple, was die in den letzten Jahren aufgeholt haben in CSS, muss ich sogar sagen, die haben CSS in den letzten paar Jahren ernster genommen als JavaScript. Also die sind ja, das Safari ist ja beim JavaScript noch ein paar, viele Sachen im Hintertreffen im Vergleich zu Chrome und anderen.

52:59Und bei CSS haben die aber richtig viel investiert und auch viel beigesteuert, wo ich sagen muss, wo dann allen geholfen hat. Ja, im Kern, aber nicht in dem amerikanischen Gesamtpaket, das du vorhin ja so eloquent beschrieben hast. Was halt eben fehlt, ist das Ganze drumherum. Was halt irgendwie fehlt, ist tatsächlich, also okay, die gibt es da auf YouTube vereinzelt, die CSS-Vorreiter, die irgendwie, damit auch sagen, guck mal, was du Krasses bauen kannst oder so, Aber gerade so im Bereich von Tooling ist da, glaube ich, noch wirklich sehr viel ungehobenes Potenzial.

53:30Denn wie gesagt, du könntest einen CSS-Type-Checker haben, der halt auf einer Stufe mit TypeScript steht und dir genau sagen kann, das, was du da schreibst, kann so nicht funktionieren und hier ist der Grund dafür. Das drumherum fehlt, das Tooling fehlt. Stattdessen erfinden wir Tools, die zum Beispiel theoretisch CSS-Klassen umschreiben, weil es halt ein bisschen bequemer. Wenn man da mal an der fundamentaleren Ebene ansetzen würde, könnte man halt irgendwie statisch typisiertes CSS haben.

53:55Das fände ich persönlich viel krasser, weil dann könnte man das Original schreiben, bräuchte keine extra Libraries, um das zu supporten, wird mit allem funktionieren und man könnte halt Fehler vermeiden und müsste sich die nicht hinterher aus HTML rauskompilieren. Das könnte gut sein, wie es ist. Ich wollte eigentlich nur nochmal reingehen und sagen, dass eigentlich, also das, was wir letztes Mal gesagt haben, dem, was wir jetzt gerade diskutieren, ja auch gar nicht so wahnsinnig widerspricht.

54:26Also ich glaube, dass wir letztes Mal auch gesagt haben, dass Tailwind, vielen Leuten die Arbeit mit CSS leichter macht, weil man eben einfach so Serviervorschläge hat, die man fix und fertig einsetzen kann, wo man eben auch einfach weiß, die laufen Cross-Browser. Da wird quasi hintenrum abgesichert, dass das auch robust ist. Und ich glaube, Peters Argumentation letztes Mal war, dass er eben dafür plädiert hat, dass man in seinen Projekten, ein CSS-Spezialisten haben sollte, damit, also weil Tailwind im Prinzip sozusagen eine Lösung ist, für wenn man solche Leute nicht hat.

55:14Würde ich differenzierter beschreiben wollen. Also nicht diesen einen CSS-Spezialisten, weil CSS ist mir zu technisch. Es geht mir halt wirklich mehr so darum, dass jemand nicht bei CSS oder UI-Spezialist, sondern tatsächlich nicht mal ein Spezialist sein muss, aber jemand, der dafür zuständig ist. Du kannst auch für was zuständig sein ohne die Maximalkompetenz zu haben. Aber du kannst halt eben sagen, das ist meine Aufgabe, die nehme ich ernst.

55:36Und wenn hier eine Entscheidung getroffen wird, für wegen führen wir jetzt noch eine siebte Button-Variante ein, dann geht die über meinen Schreibtisch und, passiert nicht irgendwie so. Das ist ja vielleicht mit Tailwind auch der Fall. Also das eine schließt das andere nicht aus. Wahrscheinlich gibt es in den Projekten Leute, die dafür zuständig sind und. Die entscheiden sich dann vielleicht für Tailwind. Das kann durchaus sein. Nur ich habe ja vorhin Jon so verstanden, dass er sagte, Und der Einsatz von Tailwind hat spezifisch Probleme gelöst, die entstehen, weil halt nicht alles über einen Schreibtisch geht.

56:08Das war dieser, glaube ich, dieser Wettmaster mit seinen etwas größeren Ambitionen bezüglich der Gestaltung. Also das ist ja tatsächlich wieder meine Idee von wegen, du hast auf jeden Fall ein Designsystem. Die Frage ist halt, ob du das implizit hast oder ob du es explizit oder irgendwo dazwischen hast. Also das ist halt eben eine vielschichtige Kiste. Es ist halt einerseits die Syntax und die Sachen zu schreiben mit halt irgendwie, das kann man dann irgendwie cooler finden oder nicht.

56:35Und es gibt halt diese Serviervorschläge, die man entweder so nehmen kann, wie sie sind oder sich was anderes hernehmen kann, was in die ähnliche Richtung geht. Aber das sind grundsätzlich erstmal zwei Concerns, die zusammengemanscht sind in eins, was ja irgendwie auch okay ist. Machst ein schönes Paket, buchst du halt Flug und Hotel in einem Schritt. Ist ja grundsätzlich alles fein. Aber was halt eben man gucken muss, ist, wie vergleicht sich das zu eben der Nulllösung, die halt eben daraus besteht, wie ich arrangiere mich halt mit dem, was schon da ist.

57:03Wo ich halt einfach sagen muss, ich habe halt so immer einen sehr lustigen Disconnect, wenn ich mit Menschen die ehrliche Arbeit verrichten, also mit euch so rede und das mit meiner Realität vergleiche, wo halt so Sachen wie die große CSS-Datei, in der alles drin ist. Die sehe ich halt persönlich mittlerweile eher selten, weil das halt auf die eine oder andere Weise in Komponenten gekapselt wird mit halt irgendwelchen Mechanismen, die da sein können.

57:27Ich mache halt irgendwie Oldschool-CSS in JavaScript, weil ich irgendwie ein React-Projekt von 1804 habe oder ich mache irgendwie was anderes. Ich mache vielleicht Up-Components mit Shadow DOM, keine Ahnung. Aber so, das ist dieser ganz große Klassiker von früher. Ich schreibe an die CSS-Datei hinten, was haben und plötzlich wird im Header was grün, was ich gar nicht grün haben wollte. Das sehe ich sehr selten und das höre ich mittlerweile auch sehr selten.

57:51Und ich frage mich halt immer, wenn auch das bei mir in meinem Hinterkopf noch so rumklappert, ob das einfach nur daran liegt, dass ich halt einfach nicht von früher loslassen kann und mal mit der Zeit gehen sollte, wo das einfach immer seltener passiert. Ist so mein Eindruck, meine Frage. Ich denke halt immer meine Nulllösung ist so schön, ich habe CSS Variable und den ganzen Kram und der ist halt schon da ich muss dafür nichts installieren, das wird sich auch niemals updaten, da gibt es keine Version 4 Gehirnausab dafür, ach da ist schon was nehme ich jetzt, setze ich ein Gehirnausab dafür funktioniert, super, kein Tooling, keine Updates, Und spannend, man muss ja immer noch bedenken, dass 90% der Webseiten mit einem System arbeiten, wo ja sehr gern und sehr einfach gehackt wird, wie WordPress.

58:37Und dort hast du halt zum Beispiel diese sehr viele Komponenten, Denken oder so, wie wir jetzt auch arbeiten können. Also ich möchte es ja auch nicht missen, aber sehr viele Systeme können das halt auch nicht. Oder auch bei Kunden, wo ältere Projekte da sind, wo halt riesige Monolithen sind und tausende von Geschichten reinfließen. Klar, widerspreche ich dir gar nicht, Peter, klar könnte man das auch mit BAM lösen. Wurde auch sehr viel gelöst, aber da war das Problem, dass CSS gewachsen ist, gewachsen ist und dann hat man Komponenten entfernt und man hat sich dann nicht getraut, CSS-Teile davon zu entfernen, weil man gemerkt hat, oh, da geht woanders was kaputt.

59:25Und das ist für mich so. Der Hauptbenefit für mich zu sagen, ja, okay, wenn ich die Komponente wegschmeiße, dann geht alles unnötige CSS automatisch auch weg. Und ich muss mich nicht darum kümmern. Ich muss nicht daran denken, ich muss nicht überlegen, okay, was ist jetzt da genau. Aber ist das nicht ein Problem, das tatsächlich durch ein System beim Definieren der visuellen Komponenten erschlagen gehört? Ist es nicht so, dass irgendwo definiert sein müsste, Beaudit ist ein Button mit den drei Varianten und den sieben Variablen und, der ist dann mehr oder minder, wenn man aus High-Level-Sicht arbeitet, ein Self-Contained-Ding, das man irgendwo reinplanken kann, vielleicht irgendwie ein bisschen themen kann, aber auch OnBlock auch wieder entfernen kann.

1:00:15Ja, oder weißt du, ich habe so mal ein Beispiel gebracht, ich habe ein Hero und das hat die Klasse Hero und jetzt. Hat das Hero ein Margin nach oben von, so und so viel Pixeln oder RAM oder was auch immer, völlig egal und jetzt kommt das Hero Element auf einmal tiefer unten auf der Seite und da brauche ich jetzt, null, also ich muss es resetten quasi und dann okay, jetzt kommt hero minus minus after text, dann bitte auf null, dann arbeitet man weiter und dann merkt man, oh, jetzt kommt das hero-element, auf einmal nach einem Bild und jetzt muss ich das auch auf null setzen, weil ich ja da nicht diesen weißen Streifen drin habe.

1:00:59Okay, jetzt habe ich wieder minus minus after image und jetzt habe ich after image und after text, was eigentlich das gleiche machen. Da weiß ich ja die Lösung. Also ich wüsste auch eine Lösung. Shep, du zuerst. Ja, also ich baue alle meine Komponenten ohne Margins. Und immer, immer, immer, immer. Und auch ohne Breitenbegrenzung und so. Und das, was eben dann die Margins setzt und die Breiten begrenzt, das ist dann die Komponente. Bei mir sind alles Komponenten, selbst wenn es quasi ein Page-Layout oder ein Teil-Layout ist.

1:01:32Also dieses Layout, was dann die Komponenten benutzt, das macht das. Ich hätte genau das geraten, dass das deine Lösung ist. Ich hätte es gewusst, errate kurz meine Lösung. Puh, du, wie würdest du das machen? Du würdest, ich weiß es nicht, ich gebe ja tausend Möglichkeiten. Die dümmstmögliche Lösung, Chef, was ist die dümmstmögliche maximale Low-Tech-Lösung? Du würdest wahrscheinlich den Sibling-Selektor nutzen. Ich würde halt, wenn ich in diese Sonderfälle reingerate, erstmal anfangen zu sagen, das ist ein Ad-Hoc-Problem, das kommt bestimmt nur einmal vor und dann male ich da ein fucking Style-Attribut rein.

1:02:10Und dann wiederhole ich das, wie Vanessa schon gesagt hat, einfach, dann machen wir das hier auch noch und hier auch noch und hier auch noch, so lange, bis es irgendwen stört und dann entwickeln wir eine Lösung auf der Basis von dem Ganzen und bis dahin nutzen wir halt die Werkzeuge, die halt schon rumliegen. Da muss man nicht direkt anfangen, nur weil man irgendwie einen Edge Case hat, dann da Klassen und BEM irgendwie länger zu machen und so.

1:02:31Nee, Ausnahmefällen benötigen halt eben auch Ausnahmelösungen und da macht man das so lange, bis es knirscht und dann baut man auf der Basis dessen weiter. Alles andere ist doch hier so Klassiges, you ain't gonna need it. Ja, aber es geht nicht, weil wir ja alle Content Security Policies nutzen, wo wir keine Inline-Styles nutzen können und darum bricht dein Kartenhaus gerade zusammen, Peter. Ja, wer kennt sie nicht, die CSP-Regeln? Ich wollte aber vorhin zu Peters Punkt noch sagen, den habe ich dann bei der letzten, bei der zweiten Juni-Episode auch gar nicht so wahrgenommen. Die würde ich jetzt aber auch unterstützen.

1:03:11Ich finde es bei Code Reviews, schwieriger und das ist aktuell auch durch AI nochmal größer geworden, weil es auch mehr zu Reviewen gibt, mich wirklich zu fokussieren auf die einzelnen Bestandteile. Ich muss mir wirklich merken, du überprüfst jetzt das HTML, du überprüfst jetzt das JavaScript, du überprüfst auch jetzt wirklich das CSS. Ich finde es schon irgendwie einfacher, über Tailwind-Klassen so ein bisschen hinwegzulesen und so, das wird schon passen.

1:03:45Versus, da ist jetzt ein Blog an CSS. Das ist jetzt, dafür kann jetzt Taylorin CSS auch so wenig. Das ist schon auch so eine mentale Einstellung. Und deswegen sage ich ja, ich denke jetzt nochmal spezifisch dran, okay, jetzt schau dir nochmal wirklich das CSS im Detail an. Denn was wirklich bei komponentenbasierten Sachen passieren kann, ist, dass du es halt copy-pasted hast und dann Frage nach, was macht denn die Klasse hier eigentlich? Ja, ach so, hups.

1:04:11Das kann jetzt bei klassischen CSS natürlich ganz genauso passieren. Wenn du sagst, okay, du hast eine BEM-Klasse, oder wenn man das so nennt, Entschuldigung, und die hast du halt auch copy-pasted und da war da halt auch nochmal so ein Position Relative drin, das macht ja jetzt erstmal nichts Schlechtes, aber hat vielleicht auch keinen Sinister drin gehabt. Und, ähm, dieses, was ich als Problem bei sowas wie BEM sehe, diese ganzen Entscheidungen zu treffen und wie nenne ich jetzt das Ding genau und für was ist das alles verwendbar, wenn es global ist, ähm, das kann natürlich auch bei einem Tailwind zu einem Problem werden, wenn mir diese Entscheidung abgenommen wird und es ist einfach die Single Source of Truth von so manchen Styles.

1:04:51Als man sollte seine Base-UI-Components haben. Man sollte sie verwenden. Aber ja, dazu können auch wieder unrhythmische Webseiten entstehen, weil hier mache ich mal einen Margin von vier ran, hier mache ich mal einen Margin von sechs ran. Und es ist eine sehr günstige Möglichkeit, das zu tun, weil ich mich eben nicht entscheiden muss, ist das jetzt meine BEM-Klasse XY oder die XYZ-Klasse. Sowas wie Inline-Style, das geht ja gar nicht. Das wurde ja schon wahrscheinlich durch Linter verboten oder sowas.

1:05:25Naja, aber so dieses Problem, dass man vielleicht, also ich meine, so Sachen wie Buttons oder sonst sind ja dann auch Komponenten, die man einmal stylt und dann eben Varianten davon hat. Und ich glaube, dann hat man Konsistenz. Und das würde ja genauso in einem BAM-Umfeld wie in einem Tailwind-Umfeld würde man das, würde ich jetzt hoffen, machen, dass man eben solche Primitiven, die immer mal wieder benutzt werden, irgendwo, in Form von Komponenten. Diese ganz primitiven Fassungen, da habe ich glaube ich bei beiden Frameworks nie so wirkliche Probleme gesehen.

1:06:00Bei mir sind es wirklich immer wieder diese Karten, diese Listen, die irgendwie aber immer so ein bisschen besonders sein müssen. Und alles, was ein Container ist. Es gibt so viele Container und die haben so viele Borders und das hat den Background und das hat keinen Background und das hat den Border und das ist ein Border and Hover. Ja, das sind halt so Sachen, so Sachen wie Container oder Cards sind halt einfach auch zu unterspezifiziert. Das kannst du nicht richtig machen, weil die Dinger einfach einen Job haben, der so offen ist, dass du da nicht irgendwie eine Lösung haben kannst. Geht halt nicht.

1:06:33Und generell so die Sache von wegen, nehme ich da jetzt Komponente X oder mache ich eine Variante von X und sowas allem, Tailwind vs. Spam wisst ihr, in welchem Bereich keiner damit ein Problem zu haben scheint, in allem anderen, also irgendwie JavaScript oder so, schreibe ich jetzt eine neue Klasse oder mache ich irgendwie eine Subklasse von meiner bestehenden, schreibe ich eine neue Funktion die die andere aufruft oder, wird die komplett from scratch geschrieben und ist der anderen halt ein bisschen ähnlich Irgendwie kriegen die das alle irgendwie super hin, egal ob sie PHP, JavaScript, Ruby oder sonst was schreiben, ohne eine neue Syntax zu erfinden. Wie machen die das?

1:07:08Ich finde es auch bei offensichtlicher im JavaScript oder im Vue.js-Komponentenbereich. Ich finde es da einfacher eben zu sagen, hier mache ich eine klare Trennung, weil ich gelernt habe, das Versuchen zu generisch zu machen, ist einfach zu schmerzhaft. Und irgendwie habe ich halt in meiner persönlichen Bubble das Gefühl, bei CSS hat man noch mehr versucht, es generischer zu machen, während man JavaScript-Komponenten irgendwie als günstiger und kann nicht mehr duplizieren angesehen hat.

1:07:36Das ist jetzt eine sehr, sehr spezifische, meine persönliche Erfahrung. Und wahrscheinlich hat hier jeder andere irgendwie andere Erfahrungen damit gemacht. Aber das ist genau das, was ich meinte in der Folge, die du da ansprachst, wo ich da mit Shep so drüber gerantet habe. Wo ich halt gesagt habe, wenn die ganzen Programmiererinnen und Programmierer einfach nur, die gleiche Logik, die sie halt eben auf ihr JavaScript oder PHP anwenden, auf ihr CSS anwenden, ergibt sich automatisch sowas wie ein BAM weil man denkt sich dann halt eben, man denkt halt drüber nach, was für eine Klasse gebe ich dem Teil, statt einfach irgendwie zu sagen, okay, ich gehe jetzt nach so irgendwie offensichtlichen Kategorien wie halt Container, Card und dem, was man halt eben als so, offensichtliche erste Wahlen annimmt, was halt immer diese unterdefinierten, Dinger sind, die halt einfach nicht hilfreiche Kategorien darstellen.

1:08:27Das ist halt in der Programmierung ist das dann so der Abstract Service Provider. Aber das klingt erstmal gut und das kann auch alles irgendwie lösen, aber ist halt so unspezifiziert, dass es halt einfach so einen Rattenschwanz an Problemen nach sich zieht, dass man einfach durch Schmerzen gelernt hat. Okay, das muss halt irgendwie alles getrennt, gekapselt, gesondert gebaut werden, auch wenn es der reinen Theorie nicht entspricht, weil man halt eben da ein paar implizite Verbindungen hat, ein bisschen Wiederholung drin hat.

1:08:51Und wenn man das gleiche einfach auf CSS anwendet, dann läuft das viel besser. Aber was ich auch noch so glaube, es war vielleicht für mich so ein Unterschied zwischen, ich nenne es jetzt mal semantischen Klassennamen und Presentational-Klassennamen, also zwischen BAM, Tailwind. Ist halt, also die HTML und CSS haben ja quasi immer. Eine Kupplung oder eine Verbindung zueinander. da. Und wenn ich jetzt sage, ich habe eben so manche Klassnamen, BEM zum Beispiel, dann sage ich, ja, das HTML kann man restylen, wie man will, das ist unabhängig vom CSS und, Das CSS ist quasi dann gebunden ans HTML und ist nicht neu verwendbar quasi.

1:09:43Und bei Tailwind oder bei Crosstational Class Namen ist es halt genau umgedreht. Da sage ich ja, das HTML ist verbunden zum CSS und kann nicht einfach so umgestylt werden. Das heißt, dort ist es nicht entbunden, aber das CSS kann man verwenden oder wiederverwenden, wie man will. Also eigentlich ist es ja nur eine andere Dependency, wo die zwei Paradigmen quasi haben. Einmal ist das HTML decoupled und das CSS ist gebunden ans HTML und einmal umgedreht.

1:10:20Und das ist für mich eigentlich der Hauptunterschied zwischen eben BAM und Tailwind und ich für mich, wo ich jetzt schon sehr viel TSS schreibe, täglich, mein täglich Brot ist quasi. Fun für mich so herausgefunden, ja. Tailwind hilft mir da schon sehr, quasi diese Qualität hochzuhalten und klar, ich könnte es auch mit BEM, aber es würde mich halt sehr viel mehr Rechenpower im Hirn kosten. Und da ja der Mensch immer geneigt ist, die möglichst faule Lösung herzubauen, wo für ihn am besten passt, das kann für jemand anderes eben BAM sein, habe ich es für mich gemerkt, hey, Tailwind ist da schon eine Riesenhilfe gewesen, quasi, diesen Ansatz quasi umzudenken.

1:11:05Klar, wenn ich jetzt, wo du vor allem die Grids erwähnt hast von Tailwind, die verwende ich jetzt auch nicht so gerne für komplexe Grids-Geschichten, da nehme ich dann lieber eben mein, da nehme ich Custom CSS, weil ich da mit Grid-Templates schöne Sachen bauen kann, wo dann auch schön dynamisch sind, wo dann auch gut funktionieren und das ist, finde ich, auch völlig in Ordnung, also ich. Ich warne davor, quasi Tailwind zu sagen, ja nur noch Tailwind und du darfst keine einzige Klasse mehr schreiben, weil das ist dann böse.

1:11:38Ja nicht. Ich glaube, das ist so ein bisschen manchmal, wo es dann auch wieder ausschlägt von gewissen Tailwind-Jüngern, wo du sagst, ja nein, das darfst man gar nicht mehr verwenden. Und ich glaube, da muss man einfach einen sehr guten Mittelweg finden. Aber für mich jetzt persönlich, fand ich es viel einfacher, diesen Mittelweg zu gehen, wenn ich sage, ja gut, ich habe hier zwei, drei Komponenten oder lass es zehn sein bei einem größeren Projekt, wo jetzt Customs sind und der Rest sind quasi Tailwind-Klassen, also so BAM an gewissen Orten.

1:12:09Aber das Große dann Tailwind hat für mich schon sehr die Wartbarkeit erhöht von Code und ohne, dass ich halt. So andauernd überlegen muss, oh, mache ich jetzt da woanders kaputt oder habe ich jetzt dieses schon so verwendet, weil wenn ich nur 10 BAM Komponenten habe, die kann ich quasi im Arbeitsspeicher halten, wenn ich 100 BAM Komponenten habe, kann ich mir das Naming nicht im Arbeitsspeicher halten, macht es für mich dann schon schwieriger, muss ich jedes Mal schauen und oh, ja, wie nenne ich das jetzt, Naming is hard und das war für mich so von meiner Seite her, Developer Experience schon sehr viel angenehmer und muss auch sagen, hat mich auch massiv produktiver gemacht, weil ich dann bei BEM manchmal so den Anspruch hatte, es perfekt zu machen und BEM und perfekt machen ist dann halt auch schwierig manchmal, weil du sagst, ja eben, ich will jetzt nicht Inline-Styles verwenden oder ich will das nicht, war da manchmal schon tricky.

1:13:12Und da war für mich das Tailwind, hat es ein bisschen vereinfacht. Klar, es gibt dann auch hässliche Geschichten, wenn du dann irgendwelche CSS-Klassen-Maps schreiben musst, weil ein Property sie ändert und du musst zehn Klassen ändern und nicht nur eine Variante. Klar, das ist auch nicht immer geil. Das ist dann halt so quasi die Kehrseite der Medaille. Aber so im, Großen und Ganzen fand ich das eigentlich schon, diese Auflösung oder diese Abhängigkeit vom HTML zu CSS oder CSS zu HTML fand ich beim oder finde ich beim Tailwind einfach angenehmer zum Arbeiten, weil mir halt, weniger um die es fliegt mir schon ein bisschen weniger um die Ohren, als wenn ich es klassischerweise mache.

1:13:59Ich muss bei einem Projekt, wo ich die Übersicht habe, muss ich weniger testen, weil ich weiß ja, es ist ja eh nur dieses Property, ich kann diese Komponente isoliert betrachten und ich weiß, Also ich haue da nichts irgendwo anders was um. So dieser klassische CSS-Witz, wo man ja kennt mit den drei Bären, dieses Meme. Klar, wir können das auch wieder diskutieren, das haben wir gar nicht noch nicht angesprochen, mit diesem Scoping von CSS, was auch wieder sehr hilft, was da möglich sein wird.

1:14:30Und deswegen sage ich auch immer, auch wenn man Tailwind verwendet, Augen und Ohren offen halten, auch mal das andere ausprobieren, vielleicht löst das ein Problem, wo ich mit, Tailwind mit 100.000 Klassen anschlage und ich könnte einfach eine kleine Komponente bauen, wo gescoped ist. Ein extrem gutes Thema. Weil ich wollte gerade nämlich sagen... Finde ich auch spannend. Ich wollte nämlich sagen, wir haben ja, glaube ich, mittlerweile aus dem Metatext rausführen können, in meinem Alltag, okay, in meinen Alltag, in meinen Projekten, wo man mich machen lässt, da verwende ich ja kein Tailwind.

1:15:03Ich glaube, das ist klar geworden. Weißt du, was ich auch nicht verwende? Ja. Weißt du, warum nicht? Weil tatsächlich die richtige Lösung für der Code ist zu lang und ich blicke nicht mehr durch, welche Namen miteinander kollidieren, ist die älteste Programmiertechnik der Welt. Und ich würde sagen, die Kollegen Julius Cäsar und Konsorten haben das auch schon vor dem Programmieren erfolgreich eingesetzt, Teile und Herrsche. In meinen meisten Komponenten sieht das halt so aus, dass ich da ein Scoping-Mechanismus auf die eine oder andere Weise am Start habe, dass ich halt einfach einen feuchten Kehrig darauf gebe, wie die Klassennamen heißen und darüber exakte 0,5 Sekunden nachdenke.

1:15:43Weil in dem Fall, wenn das Universum so klein ist, dass es halt wirklich irgendwie ein so ein Widget in der Seitenspalte ist, dann ist eine Card tatsächlich eine Card. Dann ist eine Liste tatsächlich eine Liste. Dann gehen 90 Prozent von diesen ganzen bescheuerten Problemen hin und ich führe mich einfach auf, wie die letzte CSS-Drecksau. Lauter Regeln schreibe ich, die sich gegenseitig widersprechen und überschreiben, aber weil das Gesamtprojekt, der Scope, der Arbeitsspeicher, den du angesprochen hast, 50 Zeilen lang ist, ist mir das völlig egal.

1:16:09Ich brauche das auch nicht perfekt zu machen. Diese Computer sind meine Sklaven, die haben für mich zu arbeiten und ich nicht für die. Die sollen gefälligst spuren und sich damit abfinden, dass sich da jetzt nach Position absolut direkt zwei Zeilen später Relative zu stehen haben. Ich habe das so geschrieben, deal with it. Du hast ja vorhin gemeint, du hast ja gar nicht mehr so ganz lange globale CSS-Dateien in deinem Ökosystem. Da habe ich mich dann auch gefragt, ja, aber wozu dann?

1:16:32Ich wäre jetzt auch vollkommen fein damit zu sagen, die Vorteile, die da mit Tablen kommen, hast du genauso gut, wenn du nur deinen Scoped CSS, in deiner React-Komponente, der Vue.js-Komponente schreibst. Ich finde es immer noch ein bisschen angenehmer, wenn es so direkt im HTML steht und nicht da unten und ich muss nicht scrollen und so weiter. Aber da habe ich zumindest schon mal nicht mal diese ganzen Überlegungen eben auch, soll ich es jetzt hier irgendwie wiederverwenden oder, folge ich noch diesem Ansatz von wegen CSS und HTML sind so getrennt, dass ich immer das komplette CSS irgendwie austauschen könnte oder das ganze HTML austauschen könnte und das CSS wird immer noch funktionieren, und erledige mir dieses Problem halt weg.

1:17:11Ich kann dir sagen, wo Web herkommt tatsächlich in unserer Diskussion. Das kommt halt daher, dass wenn du Entscheidungen darüber gestalten möchtest, wie baust du dein CSS auf, hast du eigentlich nur einen Hebel, an dem du wirklich ziehen kannst und das ist, was mache ich mit dem Selektor. Das ist ja das Einzige, wo du wirklich eine Gestaltungsfreiheit hast. Okay, du kannst dich entscheiden, mache ich es mit Grid oder mache ich es mit irgendwie Flex, aber das ändert ja operativ nicht wirklich viel.

1:17:34Das große wirklich Organisationsprinzip ist einzig und allein, wie genau sieht am Ende des Tages dieser Klassenname aus, wie kommt der zustande, wie wird der eingesetzt. Und deswegen ist dann halt dieses Konzept extrem überladen und so Dinge wie halt zum Beispiel die Syntax von Tailwind oder die Syntax von BEM sind inhärent Dinge, die mehrere Sachen auf einmal lösen. Und speziell in der Diskussion, die Shep und ich in der vergangenen Folge hatten, war das halt eben mein Beispiel für, dass das so ein Erweckungserlebnis sein kann für Menschen, die halt CSS immer nur als Zumutung betrachtet haben, weil man denen nämlich sagen kann, hey, guck mal, das Ding ist einfach eine Benamung und wenn du anfängst, dieses simpel erscheinende Konzept, so zu begreifen, dass da all diese ganzen konzeptionellen Ebenen drin sind, diese ganze Lasagne an Möglichkeiten, an diesem einen einzigen Hebel, an dem du ziehen kannst und nimm das ernst und behandle es wie das, was es ist, dass dann da sehr viel Verständnis rausfällt für, ah, okay, das ist also dieser eine Hebel, den ich habe und mit dem kann ich diesen ganzen

1:18:28Zug steuern und einigermaßen gut fahren. Das ist so das Problem da drin und das ist, warum wir auch immer wieder zu BAM zurückkommen, weil wir da halt ursprünglich drüber geredet haben, aber weil das halt eben auch so ein wunderbar simples Konzept ist, drei Regeln, in denen so viel am Ende drinnen landet. Wie immer ist die beste Lösung, Probleme nicht zu lösen, sondern gar nicht erst zu haben. Wenn du auf deinem Betriebsgelände ein Bottich mit kochender Säure stehen hast, ist die beste Lösung nicht, da einen Zaun drum herum zu bauen, sondern eine Möglichkeit zu finden, dieses Ding nicht auf deinem Gelände stehen zu haben.

1:19:02Und deswegen sage ich, hey, mach einfach dein Designsystem, das du hast, ob du willst oder nicht. Mach es explizit. Das löst viele Probleme. Wenn du etwas hast, was zu groß ist, um das zu klarkommst, dann hack es halt in kleine Stücke. Hast du das Problem nicht mehr, dass da ein so ein großer Monolith irgendwie rumschwirrt. Und dann kann man natürlich da, wo das nicht geht, über Lösungen nachdenken. Aber Probleme lösen ist halt der zweite Schritt. Das ist die Implementierung.

1:19:27Der erste Schritt, das Design eines Systems, sollte Probleme erstmal aus dem Weg schaffen, vermeiden, unmöglich machen. Und das sind die Werkzeuge, die ich ganz gerne hätte. Weißt du? Da musst du über nichts nachdenken, weil du nimmst das, was schon da ist. Du brauchst das Problem nicht zu lösen, dass das Ding viel zu groß ist, weil es halt nicht zu groß ist. Inherent. Du machst dein Designsystem explizit im Rahmen deiner Möglichkeiten und dann ist das Problem zu einem gewissen Grad gelöst und über den Rest, da baut man dann Lösungen dran.

1:19:54Aber eine große Lösung für ein großes Problem ist immer falsch. Du brauchst immer für ein großes Problem einen Designansatz und nicht eine technische Lösung, eine Implementierung. Edge Cases wie Raumfahrt ausgenommen. Ihr wisst, was ich meine. Zu der Geschichte mit der, man hat ja keine große Datei und deswegen braucht man ja vielleicht keinen BAM. Ich glaube, das ist eher so zu verstehen, dass Leute, die das CSS eben nicht mehr in Form, also so wie das halt vor 15, 20 Jahren war, in Form einer langen CSS-Datei, zusammenschreiben, sondern dass tatsächlich eben die CSS-Teile, die zu einer Komponente gehören, mit in dem Ordner oder in der, Datei, in der eben auch der Rest definiert wird, dieser Komponente mit geparkt ist, aber am Ende natürlich ein Bundler trotzdem hingeht und in der Regel, also außer, bei SPAs, die sozusagen, route-abhängig gebundelt werden, die dann in dieser einen großen Datei zusammengemanscht werden.

1:21:02Und dann brauchst du natürlich immer noch BAM oder eben AdScope. Um eben kein Style-Leaking zu haben. Aber du weißt halt eben auch, wenn du diese Datei löscht oder wenn du diesen Ordner löscht, in dem eben die anderen Teile der Komponente definiert sind, dann löscht du auch das CSS mit und dann hast du es später auch nicht mehr als gleiche in deinem ausgelieferten CSS mit drin. Und vor allem, man kann ja davon ausgehen, dass die Style States in diesen Ordner sind, nicht plötzlich in dem Überordner XY auch noch verwendet wird.

1:21:39Und dass ich jetzt auch was kaputt mache, wenn ich da was ändere. Und wenn doch, hast du ein Designproblem, für das du eine technische Lösung entwickeln kannst? Ja klar, aber das ist genau das, wo ich halt schon in Teams erlebt habe, dass dann. Eine Komponente quasi an Orten verwendet wurde, wo es jetzt nicht gedacht war. Passiert halt. Und das ist ja, also wir haben bei uns eine Community, bei uns so ein Credo, wo wir sagen, wenn wir was entdecken, wo halt wirklich irgendwie, wo man sagt, wie kann man sowas machen?

1:22:16Dass wir sagen, hey, zu diesem Zeitpunkt, wo die Person das geschrieben hat, hat dieses ja am besten Wissen und Gewissen gemacht. Also es ist ja nicht so, dass es niemandem unterstellen, dass das böswillig passiert ist, sondern einfach aus dem Mangel von Witzen. Und da passieren dann halt genau solche Geschichten. Und das ist für mich der riesen Vorteil von Tailwind, dass dieses Problem halt schon vielleicht nicht komplett dezimiert wird, aber es wird schon sehr stark reduziert.

1:22:44Dieses Problem, dass halt irgendjemand dir was abschießt, und du entfernst jetzt eine Komponente und die zu ihrer EGC-Datei und der hat halt irgendwie noch die Klasse verwendet und, aber nicht die Komponente dazu, das heisst, du würdest das gar nicht finden per Suchen. Gut, wenn du jetzt den Code durchsuchst nach der Klasse und so, dann vielleicht schon. Aber ja, das passiert halt dann trotzdem. Und das dann schon erlebt halt in größeren Projekten, dass das halt weniger Probleme gemacht hat.

1:23:19Gebe ich auch an Peter vollkommen recht. Das würde nicht passieren, wenn man es anständig und gescheit machen würde von Anfang an. Aber eben dieses Level von Knowledge hat halt nicht jeder oder will nicht jeder. Die AI hat es ja sowieso schon mal nicht, weil er schon der nächste Angestellte ist, wenn man so will. Hat sie das nicht? Ich bin nämlich absolut nicht informiert. Ich habe keinen Cloud jemals auf irgendwie CSS losgeschmissen und das dann ernsthaft bewertet.

1:23:50Ist das Zeug schlecht in CSS? Weil es gibt ja genug CSS da draußen. Ich habe ja vorhin schon gesagt, dass es ein bisschen besser ist in Tailwind CSS als in einem getrennten CSS und das liegt auch einfach dran, wie die LLMs Texte schreiben und die schreiben deshalb auch erstmal gern, die Brocken am Stück und sie wollen jetzt nicht, vor allem nicht zwischen verschiedenen Dateien hin und her springen, aber sie wollen eigentlich auch nicht in einer Datei, da schreibe ich was oben, da schreibe ich was unten, da schreibe ich was oben, da schreibe ich was unten, weil sie ja schon eigentlich zusammenhängende, Textbausteine liefern.

1:24:24Okay, weil sie sozusagen wegen Autoregressiven, ich baue den nächsten Token, am Ende vergessen haben, was sie am Anfang gemacht haben. So tief bin ich auch nicht drin, aber ich kann jetzt nur wiederholen, die schreiben gerne Textbausteine am Stück und nicht so viel in verschiedenen Zeilen umher. Und ich glaube, das ist auch das, was Menschen auch da ein bisschen schwerer fällt, dieses Umherspringen, das im Arbeitsspeicher zu halten, wie das schon vorhin gemeint hatte.

1:24:46Aber ich habe riesige Vibe-Coded-Projekte in TypeScript gesehen und bildlich gründlich durchgelesen, einfach so aus Jux. Und da ist auch alles irgendwie extrem verteilt und da werden irgendwie Module von ganz weit da hinten importiert. Wieso kriegen die das mit TypeScript und mit CSS nicht? Ich glaube, weil CSS ist halt... Es gibt ja Leute, die sagen, ja, CSS ist keine Programmiersprache. Kann man jetzt drüber streiten? Nein. Inzwischen würde ich mit den Funktionen...

1:25:16Die Leute, die das sagen, sind nämlich Idioten. Da kann man nicht drüber streiten. Die haben keine Ahnung. Ja, ja, eben. Es ist natürlich schon so, also wenn ich eine JavaScript-Funktion habe, dann kann ich ja sehr gut isoliert testen, was passiert jetzt. Was ist denn ein Unit-Test, die Sie machen können? Shit in, shit out, irgendwas kommt rein. Du musst es kompilieren, es muss überhaupt mal lauffähig sein. und CSS erlaubt halt auch schon eh schon so viel.

1:25:39Eben, ich kann ja irgendwie fünfmal Positionen neu setzen im CSS. Der Browser sagt ja, nehme ich halt das Letzte. Die Klassen können sich gegenseitig überschreiben. Jetzt kommen noch die Layers hinzu. Es ist halt schon eine Komplexität, finde ich. Also du findest ja auch leichter, einen guten TypeScript oder JavaScript-Developer zu finden, finde ich, ehrlich gesagt, ist sehr viel leichter, als jemanden zu finden, der sagt, hey, ich kann CSS und habe da ein bisschen ein Händchen dafür, weil du da, du musst ja neben dem, dass du jetzt weißt, welche Klassen du verwenden sollst und welche nicht, welche Sinn machen, musst du dann eigentlich auch noch sagen, Und wenn du wirklich vorumfänglich sagen willst, muss ich da auch noch ein Verständnis haben von UX und UI und Geschichten und Abständen und typografisches Know-how und all diese Geschichten.

1:26:36Von dem her finde ich eigentlich, ist das Spannungsfeld von CSS für mich viel breiter als bei JavaScript. JavaScript, finde ich, kann man so sehr schnell, weil wenn du sagst, du bringst einem Jugendlichen, hast einen Vortrag über, wie entwickle ich eine Webseite, da erklärt, zeigst du ein JavaScript, schau, da machst du das und dann machst du das. Ist sehr viel schneller erklärt, als wenn ich dann jemandem erklären muss, ja, okay, jetzt CSS. Würde damit einer nie gesehenen Vehemenz widersprechen.

1:27:06Weil ich gucke mal, nimmst du dir halt irgendwie so einen modernen Full-Stack-Java-Skript-Ansatz, dann musst du halt irgendwie JavaScript die Sprache kennen, dann musst du irgendwie React auf dem Kasten haben, das muss irgendwie in Next.js reingeknuppert werden und weil das irgendwie Backend-mäßig noch arbeitet, musst du entweder REST sprechen oder mit der Datenbank auch noch reden und das sind alles irgendwie Libraries um Libraries um Libraries mit ihren eigenen Komplexitäten, permanenten Updates und.

1:27:31Node.js, Docker? Node.js, Docker, ja, wenn du Pech hast, musst du den Kram auch noch deployen, Gott bewahre oder gar Tests schreiben, ne, musst dann auch noch Qualitätssicherung machen, also Also ich glaube nicht, dass die Komplexität von CSS massiv unterschätzt wird von so den Feld-, Wald- und Wiesen-Menschen da draußen. Ich glaube aber nicht, dass irgendwie so, ich bin einigermaßen kompetent in JavaScript und allem, was da dran hängt. Eine andere Komplexitätsstufe ist. Das ist schon alles auf einem Niveau.

1:28:02Ich habe Docker schon ganz verdrängt. Guck, ich habe nicht mal daran gedacht, das aufzulisten, weil das so viel Scheiße ist, der in meinen beschränkten Schädel nicht reingeht. Ja, aber ich finde, ehrlich gesagt, klar, wenn du jetzt Libraries erwähnst und React mit den Lifecycle und all den Geschichten, ja, es ist ein Brainfuck. Deswegen verwende ich es ja nicht so gerne. Aber. So in sich, wenn ich jetzt sage, ich mache eine Miniseite und habe ein paar Effekte drauf, weißt du, ganz klassisch nur statisch, jetzt nichts, irgendwie externe Library, auch kein Tailwind, kein nichts, irgendwas. Da ist, eben JavaScript auch für dich selber, kannst du sehr gut isoliert testen.

1:28:48Da hast du einen kleinen, ich habe so ein kleines App, das heißt RunJS, da kannst du JavaScript-Funktionen schreiben, das kann auch TypeScript sein und dann kompiliert du das und du siehst rechts, was dann quasi rauskommt, ganz praktisch, wenn du mal was ausprobieren willst. Und CSS ist halt, weil es dieser globale Ansatz hat, finde ich schon manchmal komplexer oder halt habe ich jetzt auch, wo ich dann an der Fachhochschule unterrichtet habe, habe ich Jungs gehabt.

1:29:17Sekunde kurz, wir kommen gleich zu deiner Fachhochschule zurück, aber du hast jetzt ja gerade das JavaScript-Projekt auf seine Basics runtergebrochen und ich komme nicht umhin, dann auch darauf hinzuweisen, dass dieser ganze Rattenschwanz an Technologien, die an CSS dranhängen, unter gleichen Bedingungen dann ja auch keine Anwendung finden würden. Hast du einfach nur ein statisches Projekt, das halt mit ein bisschen JavaScript und HTML relativ einfach gebaut ist, hast du ja auch keine nennenswerten UX-Überlegungen, die du da anstellen müsstest, abgesehen von verstehe ich, was da vor sich ist und kann ich das lesen.

1:29:44Also wenn wir den Scope reduzieren, dann werden aber auch beide Welten gleichzeitig weniger kompliziert. Inherent halte ich das beides für definitiv in einer Liga spielend. Ja, das, wo ich viel Erfahrung habe mit den Leuten, wenn ich ihnen was beibringen muss, merke ich schon eher, dass sie vielleicht, weil sie auch mehr JavaScript schreiben, das kann natürlich auch sein, merke ich schon irgendwie, ja, JavaScript ist schneller verstanden. Klar, wenn du jetzt Bibliothek React tippst oder Bibliothek B oder C, muss man dann die Sonderheiten und die Eigenheiten lernen.

1:30:20Das ist klar, aber das ist für mich dann, man kann auch sagen, wie eine eigene Sprache zum Teil. Aber bei CSS tun sich halt schon sehr, sehr viel Entwickler schwer und kämpfen damit. Nur wenn du sagst, wie hier Formularfelder, bitte machst du es so, dass das Label jetzt rot wird, wenn das Formularfeld invalid ist und bitte ohne JavaScript, hängen halt schon viele dran. Weil du halt durch die ganzen Selektoren, eben Invalid und all die Geschichten oder wir haben auch das Transparent, wenn es Disabled ist und so all diese Geschichten.

1:31:01Ja, per se gebe ich dir recht, es ist eigentlich nicht schwieriger als JavaScript, nur es wird halt häufig sehr stiefmütterlich behandelt. Und auch unterbewertet, deswegen habe ich ja auch den Talk rausgeschmissen dieses Jahr, weil ich gesagt habe, hey, das will ich mal ein bisschen updaten oder mal versuchen, den Leuten ein bisschen auf die Sprünge zu helfen, was man jetzt da nicht, was man alles wegschmeißen kann. Ja, ja. Es ist halt auch so, JavaScript ist halt dem, was andere Entwicklerinnen und Entwickler kennen, ähnlicher als CSS irgendwas ähnlicher ist. Vollkommen korrekt.

1:31:41Aber das ist ja inhärent keine Aussage über die Komplexität oder Schwerverständlichbarkeit. Es ist halt nur, ah, okay, ich bin gewohnt, Class A Extents B zu schreiben aus meinem C-Sharp-Projekt. Das funktioniert in JavaScript komplett anders, aber hat halt einen vergleichbaren Effekt. Also habe ich da eine ganz andere Haltung für, wenn ich damit zum ersten Mal konfrontiert bin, weil es extrem dem ähnlich aussieht, was ich halt schon kenne. Das ist wie wenn wir Urlaub in Frankreich machen. Das sieht da genauso aus wie hier.

1:32:08Also gehen wir da irgendwie ohne nachzudenken hin, aber irgendwie reist du zum ersten Mal in eine andere Ecke der Welt, wo irgendwie alles komplett anders ist, dann denkst du dir auch, hoppla, da mache ich nicht mal vorher schlau. Ja, gut. JavaScript-Klassen habe ich eine ähnliche Meinung wie der Stefan. Aber dann will man auch ein anderes Fass aufmachen. Das kann man auch. Ich finde schon, dass TSS einfach eine komplett andere Disziplin ist, weil ich schon fast auch eine Art räumliches Denken dabei brauche.

1:32:41Ja, genau. Ein ganz anderes Verständnis, wie ich was aufbaue. Ob das jetzt typisiert ist oder nicht, ist eigentlich auch schon egal. Aber die Skriptsprachen, die laufen halt schon irgendwie nach einem Schema ab. Ich rufe eine Funktion auf, die Funktion ist fertig. Vielleicht kann ich noch ein bisschen asynchron machen, dann wird es ein bisschen komplizierter und dann können auch Sachen schief gehen. Aber bei CSS, da kann ich auch einfach hier mal so eine Position Relative hinknallen und wer weiß schon, was das drunter irgendwie alles beeinflussen wird.

1:33:10Oder ich habe vielleicht jetzt hier schon mal eine Fixed Header Bar. Jetzt will ich noch eine Fixed Header Bar und jetzt will ich noch Sticky Table Headers. Und generell, Und ich glaube auch wirklich, dass es das einfach ist, was LLMs auch einfach einfach nicht gut können. Das ist irgendwie zu räumlich, zu malerisch und dann kann man es nicht mehr richtig testen. Man kann ja jetzt keine Unit- oder Component-Tester für schreiben. Da gibt es weniger, in dem Sinne Linting und Überprüfungsformate.

1:33:44Und dann, ich weiß nicht, ob das stimmt, das habe ich immer so in den Raum reingeworfen, ich persönlich finde, es gibt bessere Dokumentationen, Beispiele, Tutorials über JavaScript, TypeScript, egal, jetzt online, aber weniger viele gute über CSS im Verhältnis mit wie vielen falschen Lösungen ich online schon gesehen habe. Es gibt so ein paar Seiten, die sind brillant, Aber ich hatte auch schon das Gefühl, dass, ja, das ist jetzt vielleicht auch ein bisschen länger her und es entwickelt sich alles weiter.

1:34:17Aber dass es schon eine ziemliche Zeit lang so war und vielleicht noch so ist, die AI gibt dir halt die wahrscheinlichste Antwort zurück. Und die wahrscheinlichste Antwort war halt, ja, da machst du noch einen MinWolf Null dran und dann klappt das schon. Nee. Ja, ja. Ja, das ist halt, also, ich glaube, es gibt ja niemand, wo noch nie gegoogelt hat, warum funktioniert mein Positionsdecki nicht? So ein der Klasse, dieses Teilspiel. Ja, und das ist halt, wir müssen jetzt erst beantworten, warum das nicht funktioniert. Das kannst du genauso gut fragen, warum wird meine Klasse nicht aufgerufen, meine Funktion nicht aufgerufen?

1:34:54Irgendwie werden solche Fragen aber vielleicht doch weniger gestellt. Ich glaube, die werden gestellt. Ich glaube halt nur, es ist halt relativ schwierig, aus unseren Köpfen rauszutreten. Und tatsächlich irgendwie. Weil ich jetzt uns allen mal unterstelle, dass wir irgendwie seit Dekaden schon irgendwie JavaScript und ähnliche Dinge schreiben, dass wir, glaube ich, Wissen angesammelt haben, von dem wir nicht mal wissen, dass es da ist. So dieser globale Charakter von CSS und dann schreibe ich hier noch eine Klasse hin und dann ändere ich das da, schreibe in den Futter was rein, was den Header umstylt.

1:35:25Das sind ja alles Dinge, die man machen kann, nur das kann man ja theoretisch in einem JavaScript-Programm ganz genauso machen. Man kann ja in irgendein Modul was reinschreiben, was irgendwelches DOM anfasst, das mit dem Modul eigentlich inhärent nichts zu tun hat. Man kann irgendwelche globalen Variablen setzen und überschreiben aus jeder beliebigen Zeile Code heraus. Nur das ist so weit entfernt von allem, was wir auch nur entfernt in Betracht ziehen, dass es aus unserer Realität so weit rausdefiniert ist.

1:35:53Und in CSS ist das halt irgendwie nicht so, weil wir die ganze Zeit darüber reden irgendwie, ja, das könnte ja global wirken und irgendwas kaputt machen. Da kann jede Zeile JavaScript auch. Nur wir haben unsere Gehirne in eine Form gebracht, wo diese Möglichkeit gar nicht mehr vorkommt. Das ist eine gefühlte Unmöglichkeit, sowas zu machen. Das hat extrem viel mit Köpfen zu tun und extrem wenig damit zu tun, wie man sich jetzt entscheidet, irgendwie einen Klassennamen zu schreiben.

1:36:21Ich bleibe bei meinem Punkt von ganz zu Beginn. Man muss halt gucken, was für ein Problem habe ich und welche Lösung schmeiße ich da drauf. Und im Idealfall gilt es, Lösungen zu vermeiden und stattdessen Designers so zu systemen, dass Lösungen nicht nötig werden. Und man sollte sich, glaube ich, immer gewahr sein, dass man nicht notwendigerweise immer weiß, was man alles weiß, und was man alles so aus seiner Realität rausdefiniert, was man mit JavaScript alles anstellen könnte, wenn man einfach mal mit dem gleichen leeren Gehirn da rangehen würde im Vergleich, wie man es zu CSS hat.

1:36:51Dann tun sich da plötzlich Möglichkeiten auf. Sachen, die man schreiben kann. Wie schreibt sonst keiner? Auch aus gutem Grund. Sie sind halt da. Sie sind nicht in unseren Köpfen und dadurch weniger real. Aber existieren tun sie. Und wenn man die heraufbeschwört, dann sind die da. Und dann kann man genauso viel Mist machen wie mit CSS. Mit nacktem CSS. Und dann hilft auch kein Framework. Das kann ich auch mit React-Komponenten machen. Am Ende nützt halt eben alles nichts, wenn man nicht weiß, was vor sich geht.

1:37:18Und zu einem gewissen Grad weiß man nie, was vor sich geht, weil das alles zu kompliziert ist für ein Hirn. Und da muss man dann halt irgendwie wirklich so arbeiten, dass man, wie gesagt, das Design so baut, dass es den mentalen Load runterfährt und nicht auf alles Code draufschmeißt. Ja, das ist jetzt besonders leicht geworden, dieser Tage. Nett, das heißt nicht, dass es immer das richtige Werkzeug ist. Nein, nein. Ja, und für mich ist halt Tailwind genauso ein Tool, wo ich genau das erreiche, was du sagst. Also für mich ist das schon so eine Riesenhilfe, genau in dem Bereich das halt so zu lösen.

1:37:56Weil ja, gewisses Frontend-Tooling hat man ja quasi immer. Du willst ja deine JavaScript-Dateien bilden und vielleicht splitten und das willst du nicht jetzt manuell machen mit diesen Chunks. Also ich weiß, dass ich das will, aber ich weiß nicht, ob ich damit recht habe. Ich zweifle ja so ein bisschen. Und du willst ja auch natürlich deine CSS-Datei ein bisschen minimieren und nicht das ganze Zeug auch bundeln und machen und tun und das verteilt haben.

1:38:29Schluss soll eine Datei rausfallen oder mehrere und das ein bisschen so handeln. Und da fand ich jetzt dieses ganze Terminsystem geben. Hat mir schon sehr viele Problemchen von der Schulter weggenommen, genau auch im Tooling-Bereich zu sagen, ja gut, ich habe meine Build-Pipeline, die funktioniert, habe ich nie große Probleme damit, kann ich regelmäßig die Dependencies hochfahren, das Zeug funktioniert weiterhin, ist ganz angenehm. Aber ja, das war natürlich nicht immer so noch vor ein paar Jahren hast du natürlich oh, jetzt habe ich Build Pipeline abgedatet jetzt läuft gar nichts mehr das erlebe ich jetzt auch immer wie weniger dass es gar nicht mehr funktioniert, aber für mich hat genau eigentlich das Problem wo du beschrieben hast, Peter sehe ich eigentlich ähnlich und Tailwind löst halt genau für mich dieses Problem zu sagen ja eben, wieder dieser Global Local Aspekt vom CSS, weil halt, CSS per Definition global ist, klar, JavaScript ja in dem Sinne, den man es jetzt ohne Type-Modul laufen lässt, auch, aber dann bauen halt dir deine Tools diesen IFFE rundherum, dass es nicht mehr global ist.

1:39:50Kann man halt beim CSS nicht einfach so out of the box oder konnte man lang nicht. Und ja, deswegen. Also für mich wäre eine spannende Überlegung, würde Tailwind CSS geben, wenn es CSS-Coping von Anfang an gegeben hätte? Das finde ich eine spannende Frage. Das ist 100% pro, weil du musst halt immer gucken, was ist dein Total Addressable Market am Ende? Und dein Total Addressable Market sind Leute, die mit einem Problem nicht konfrontiert sein wollen.

1:40:20Und nicht vergessen, das gab es ja früher auch für JavaScript, als das irgendwie als uncool galt. Einige von uns sind hier sicherlich alt genug, um sich zu erinnern, als man nicht gefragt hat, ob CSS eine Programmiersprache ist, sondern ob irgendwie JavaScript richtig ernst zu nehmen ist. Und da mussten erst irgendwie so Leute wie Douglas Crockford aus dem Keller gekrochen kommen und irgendwie sagen, ja, guck mal, man kann das, wenn man da anfängt, drüber nachzudenken, auch ein vernünftig machen.

1:40:43Das ist nicht ein Feature, das CSS exklusiv hat, sondern das hatten wir in JavaScript früher auch und dann hattest du Google Web Toolkit und ähnliches. Und das wohnt alles in Köpfen und das sind alles Meinungen von Menschen. Und wenn die halt irgendwie sagen, ich habe keinen Bock auf CSS, aus welchen Gründen auch immer, wo auch immer das durchmotiviert ist, dann hast du dann Markten, dann findest du dafür jemanden, der sagt, wunderbar, für die brauche ich jetzt mal eine schöne Lösung, mit der die glücklich werden. Ist ja auch erstmal nichts verkehrt dran.

1:41:08Ich glaube halt wirklich, dass das mit Funktionsumfängen, die objektiv bemessbar sind, sehr wenig zu tun hat. Das ist sehr viel Meinung und Einstellung und Haltung. Du konntest auch schon immer sauberes JavaScript schreiben. Hat früher keinen interessiert, weil die Backendler sind die einzig richtigen. Hier, gib mir Google Web Toolkit. Ist viel besser, als sich mit JavaScript auseinanderzusetzen. Aber das Fazit ist jetzt, welches? Alle Tools und alle Paradigmen haben vielleicht so ihre Abnehmer und Daseinsberechtigung.

1:41:46Und im Endeffekt ist es wahrscheinlich einfach so, womit fühlt man sich bei der Entwicklung wohl? Und viele Argumente für und wieder kann man im Grunde relativieren. Ich würde sagen, ich glaube auf mein Eingangsstatement, das da war, nimm halt das, was für das, was deine Herausforderung ist, das angemessene Werkzeug ist und setze das nach Kräften korrekt ein. Glaube ich korrekt. Ich glaube, darauf können wir uns einigen. Worauf wir uns nicht werden einigen können im Rahmen des heutigen Abends ist, wo die Grenzen liegen, anhand derer man sich entscheidet, A oder B zu wählen. Aber das ist.

1:42:28Ja auch okay. Ja. Oder eben Probleme hatten, das CSS dann quasi sauber zu schreiben. Und da fand ich halt eben so, diese Ansätze von Tailwind hat dann schon bei vielen Projekten geholfen, um, den Leuten so ein bisschen das zu helfen oder können sie dann in die Komponente schauen, wie wurde es da gelöst und haben sie es ähnlich gelöst und, dann eben auch gesehen, dass sie durch dieses Verwenden von diesen Geschichten, weil sie dann nicht nur Komponentennamen und Klassen verwendet haben, auch gelernt haben, okay, was macht jetzt dieses Einzelne, wenn sie dann eine kleine Modifikation machen mussten, wie mit, Gap erhöhen oder Padding anpassen und so weiter und so fort, weil, Das ist ja das Problem bei CSS. Sehr viele denken immer, ja, man definiert Breiten und Höhen und dann passt es schon irgendwie.

1:43:47Aber meistens ist es ja vielmehr so, dass man die Abstände anpasst und nicht die Größen von einem Element. Und gerade in komponentenbasierten Geschichten, wo du dann vielleicht auch nicht Breakpoints hast im klassischen Sinne, sondern eben Container-Querys verwendest, da umso mehr arbeitest du ja noch vielmehr nur mit den Abständen, dass du die richtig setzt. Und da habe ich dann schon gemerkt, dass da Tailwinds ja eine große Hilfe sein kann.

1:44:17Das ist auch so mein Punkt. Wo ich entscheide, von was nehmen wir jetzt halt? Ja, bitte denkt es auch an die, wo vielleicht noch nicht so dieses Level haben. Wie können sie auch dann aufholen und das dazulernen? Und gleichzeitig auch bei der Entscheidung auch schon erlebt, wo dann alle einbezogen wurden und alle hatten das gleiche Stimmrecht, das war dann auch eher schwierig, weil wenn dann irgendein völliger Neuling sagt, ja, bei Wilsitz so und so machen und jeder weiß, das wird aber nicht funktionieren, ist natürlich dann auch doof.

1:44:49Also es ist auch nicht leicht, also diese Entscheidung quasi zu setzen, welchen Ansatz fahren wir jetzt. Aber ich finde es schon wichtig, immer daran zu denken, dass es für alle dann einen Weg gibt, wo man auch sagen kann, hey, die Leute, wo das dann verwenden können, sich durchs Verwenden auch weiterbilden. Ja. Also, da haben wir ein paar schöne Argumente für die verschiedenen Ansätze, CSS zu schreiben, ausgetauscht, fand ich super. Ich glaube, irgendwie haben wir auch gar nicht so alle zusammen so furchtbar divergierende Meinungen. Oder habe ich zumindest den Eindruck.

1:45:29Außer Peter natürlich. Ich glaube nicht mal, dass ich divergierende Meinungen habe. Ich habe sie auf einem Koordinatensystem an anderen Orten platziert. So. Genau, auf jeden Fall vielen Dank, John, dass du dich angeklingt hast und uns angeschrieben hast und ja, auch Vanessa, die dadurch sozusagen nochmal so. Aufgeschreckt ist und gedacht hat, was haben die denn da eigentlich, was haben die denn da wohl, also wenn der John das schreibt, was haben die denn da erzählt und genau. Tailwind, mein Bettsignal. Ja.

1:46:04Genau. Genau, also vielen Dank. Wer von den Hörenden auch nochmal divergierende Meinung hat, sehr gerne her damit oder zustimmende Meinung. Genau, wie ihr uns erreichen könnt, inklusive dem John, wisst ihr, das wird immer in den Shownotes hinterlegt. Und auch die Dinge, die wir alle genannt haben, habe ich hier alle geöffnet, um dann die Links zu extrahieren. Genau und würde ich sagen hören wir uns nächste Woche wieder und da geht es um ich weiß es eigentlich aber natürlich jetzt weiß ich es wieder nicht, egal es wird was Tolles oder?

1:46:46Cross-Origin-Storage-API genau, Cross-Origin-Storage-API mit Thomas Steiner oder? Ja genau. Alles klar, Ru. Dann liebe Grüße an euch alle und vielen Dank für den schönen Abend hier am virtuellen Kamin. Und dann sehen und hören wir uns bald wieder. Bis dahin. Danke. Tschüss.