00:00:00Für einige der neuen Projekte, an denen ich arbeite – eigentlich für die meisten meiner aktuellen Projekte –
00:00:05habe ich mich inzwischen von Tailwind verabschiedet. Ich nutze Tailwind in diesen Projekten nicht mehr,
00:00:11und dementsprechend auch kein ShadCN. Dafür gibt es einen Grund. Und der Grund ist nicht, dass Tailwind schlecht wäre,
00:00:18natürlich nicht. Ganz im Gegenteil. Es ist eine fantastische Library. Das möchte ich ganz klar betonen.
00:00:22Ich fühle mich auch fast ein wenig schlecht dabei, dieses Video, diese Episode hier zu machen, denn
00:00:27erst vor ein paar Wochen habe ich über die massiven finanziellen Probleme gesprochen, vor denen Tailwind damals stand.
00:00:32Seitdem hat sich die Lage glücklicherweise deutlich gebessert. Viele neue Sponsoren sind an Bord gekommen, und ich denke,
00:00:38dass sie jetzt finanziell viel besser dastehen. Denn natürlich ist Tailwind absolut großartig.
00:00:43Es gibt Leute, die mit viel Herzblut und Energie an diesem Projekt arbeiten. Mein Punkt ist also nicht,
00:00:49dass es schlecht ist, und ich will auch niemanden davon überzeugen, es nicht zu nutzen. Ich nutze diesen Kanal einfach nur,
00:00:56um meine Gedanken, meine Meinung und ein paar Einblicke in meine Arbeitsweise zu teilen. Ich dachte, das könnte
00:01:01interessant sein. Warum nutze ich Tailwind also nicht mehr, wenn ich es doch toll finde? Nun, ich muss etwas weiter ausholen.
00:01:07Vor ein paar Jahren, bevor die KI-Revolution kam oder bevor KI so gut im Programmieren wurde,
00:01:15habe ich Tailwind so wie die meisten Leute genutzt, wie wohl die meisten Entwickler überall. Vor allem aus einem Grund:
00:01:21Es erlaubte mir, Code extrem schnell zu iterieren. Ich habe nie wirklich Figma
00:01:28oder ähnliche Tools genutzt, natürlich auch, weil ich meistens alleine arbeite.
00:01:34Und wenn ich alleine an meinen Projekten arbeite, brauche ich diese Design-Tools nicht unbedingt. Für mich
00:01:40war es immer schneller, Designs direkt im Code weiterzuentwickeln. Ich konnte Code schreiben,
00:01:45und da man bei Tailwind die Klassen direkt im DOM bzw. im JSX-Code hat, konnte man
00:01:50diesen Code und die Styles sehr schnell anpassen und verschiedene Looks ausprobieren. Mal kurz den Abstand ändern –
00:01:57das war einfach ein extrem effizienter Workflow. Und das war für mich – und vielleicht auch
00:02:04für einige andere Entwickler – der Hauptgrund für Tailwind. Ich weiß, dass für viele andere,
00:02:10vielleicht sogar die Mehrheit, ein weiterer wichtiger Grund ist, dass sie CSS einfach hassen. Ich weiß, CSS ist bei
00:02:17Webentwicklern nicht gerade beliebt. Und ich verstehe, warum. Es kann sehr komplex wirken. Es gibt Hunderte und Tausende
00:02:23von Eigenschaften und Werten. Ja, das kann einschüchternd sein. Ich muss allerdings sagen,
00:02:31modernes CSS hat sich enorm weiterentwickelt. Viele Dinge sind heute einfacher als früher. Flexbox zum Beispiel
00:02:37ist zwar nicht mehr neu, hat aber vieles erleichtert. Und denkt an Flexbox in anderen Bereichen,
00:02:44wo die Farbbleitung jetzt viel einfacher ist als früher. Es gibt jetzt relative Farben in CSS.
00:02:51Übrigens habe ich auf meinem Akatamine-Kanal einige Videos veröffentlicht, in denen ich über moderne Browser-
00:02:55und CSS-Features spreche, wie Farben, relative Farben oder Container Queries, die ebenfalls fantastisch sind,
00:03:01um dynamisch anpassbare Komponenten zu bauen, die nicht vom Viewport abhängen, sondern vom verfügbaren Platz
00:03:08der Komponente. CSS hat also einen weiten Weg zurückgelegt. Das Ding ist, man kann all diese
00:03:14modernen CSS-Features im Grunde auch mit Tailwind nutzen, aber man kann eben auch pures CSS schreiben –
00:03:23und das geht heute dank KI sogar noch einfacher. Denn selbst wenn man CSS hasst,
00:03:28kann es reichen, über bestimmte Features und deren Browser-Support Bescheid zu wissen. Man kann die KI auf die
00:03:34Features hinweisen, die sie nutzen soll, ein paar MDN-Artikel zur Erklärung hinzufügen, und die KI
00:03:39schreibt den Code für einen. Man fragt sich vielleicht: Warum sollte man das tun? Warum nicht einfach Tailwind nutzen?
00:03:45Es bietet schließlich auch all diese modernen Features. Dafür gibt es für mich etwa anderthalb Gründe.
00:03:51Der weniger wichtige Grund ist, dass Tailwind vielleicht nicht immer sofort alle neuesten Features unterstützt.
00:03:58Viel wichtiger ist: Die KI kennt definitiv nicht alle Tailwind-Features. Tailwind hat zwar
00:04:05viele Funktionen, aber die KI nutzt nicht alle. Sie verwendet oft dieselben paar Klassen und manchmal sogar
00:04:13eine veraltete Syntax, wodurch man bestimmte Vorteile verpasst. Das Gleiche kann einem natürlich auch
00:04:17bei nativem CSS passieren. Wenn man der KI nicht sagt, dass sie ein bestimmtes Feature nutzen soll,
00:04:22tut sie es vielleicht nicht. Aber man kann sich über die wichtigsten CSS-Features informieren und
00:04:29der KI dann sagen, dass sie diese nutzen soll. Aber klar, der Punkt ist valide: Man könnte dasselbe auch bei Tailwind machen
00:04:34und der KI sagen, sie soll bestimmte Tailwind-Features nutzen. Es ist bloß vielleicht einfacher, ein paar CSS-Kernkonzepte
00:04:40zu benennen als spezifische Tailwind-Klassen. Aber wie gesagt, das ist nicht mein Hauptpunkt. Mein Hauptpunkt ist,
00:04:48dass ich schon immer versucht habe, die Anzahl der genutzten Libraries in meinen Projekten zu reduzieren.
00:04:53Der Grund dafür ist zweierlei. Zum einen erstelle ich Bildungsinhalte, daher bin ich es gewohnt,
00:05:01dass externe oder zusätzliche Libraries eher ein Nachteil sind. Wenn ich einen Kurs über React mache
00:05:07und darin auch Tailwind verwende, und es gibt dort eine einschneidende Änderung (Breaking Change),
00:05:12funktionieren plötzlich Teile meines Codes oder des Kurses nicht mehr. Dann bekomme ich viele Fragen von
00:05:17Studierenden, obwohl sich am Hauptthema React gar nichts geändert hat. Ich weiß, das ist ein spezielles Problem,
00:05:23das vor allem mich betrifft und nicht die meisten Websites. Aber selbst wenn man eine normale
00:05:29Website baut, ist es meiner Meinung nach eine gute Idee, so wenig Drittanbieter-Libraries wie möglich zu nutzen.
00:05:38Man sollte natürlich nicht krampfhaft jede Library verbannen. Es gibt gute Gründe, bestimmte Libraries zu nutzen.
00:05:44Wenn man zum Beispiel eine Website mit einem Rich-Text-Editor baut, ist etwas wie TipTap absolut sinnvoll,
00:05:50bevor man versucht, einen eigenen Editor zu bauen. Mit KI ist das zwar heute bis zu einem gewissen Grad einfacher,
00:05:54aber man wird auf viele Spezialfälle oder Probleme stoßen, die man dann selbst lösen muss.
00:05:59Zwar mit Hilfe von KI, aber auch die macht nicht alles richtig, wie man weiß, wenn man schon damit gearbeitet hat.
00:06:06Es gibt also Gründe für Drittanbieter-Libraries. Ich sage nur, dass das Styling – wie erklärt –
00:06:11etwas ist, das man tatsächlich gut ersetzen kann. Nochmal: Ich sage nicht, dass jeder das so machen sollte,
00:06:16aber für mich funktioniert es sehr gut. Und daher ist es eine Library, die ich einsparen kann, weil
00:06:21es mir nichts ausmacht, den CSS-Code der KI zu prüfen und Probleme mit purem CSS zu beheben,
00:06:28wenn mal etwas schiefgeht – denn natürlich geht bei der Nutzung von KI irgendwann mal etwas schief.
00:06:37Aber das stört mich nicht. Wenn man es absolut hasst, CSS-Code anzuschauen, ist das natürlich keine Option.
00:06:44Für mich bedeutet es jedoch, dass ich die Tailwind-Library loswerden kann. Ich kann zum Beispiel auch ShadCN
00:06:50weglassen, weil ich meine eigenen Komponenten baue. Und ShadCN ist zwar keine
00:06:56klassische Library, nutzt aber im Hintergrund Radix UI – eine Library, deren Wartungsstatus
00:07:00meines Wissens nach derzeit etwas fragwürdig ist. Und da haben wir das eigentliche Problem,
00:07:08warum ich Libraries vermeiden will – auch abseits von Bildungsinhalten. Jede Library,
00:07:16die man einem Projekt hinzufügt, kann zur Last werden, wenn sie nicht mehr gepflegt wird.
00:07:21Sicherheitslücken werden dann vielleicht nicht mehr geschlossen, Fehler nicht mehr behoben.
00:07:29Styling-Fehler zum Beispiel. Neue Features kommen nicht mehr hinzu. Wenn es ein neues CSS-Feature gäbe
00:07:35und Tailwind nicht mehr gewartet würde (was es natürlich wird), dann könnte man dieses Feature
00:07:41vielleicht nie nutzen. Und bei Tailwind waren wir ja fast schon an diesem Punkt.
00:07:46In dem Video, in dem ich über deren Probleme sprach, gab es einen Post vom Hauptentwickler,
00:07:52in dem er sagte: Wenn sie das Finanzierungsproblem nicht lösen, könnte Tailwind zu Abandonware werden.
00:07:58Vielleicht war das etwas drastisch formuliert, vielleicht auch, um Aufmerksamkeit zu erregen. Nichtsdestotrotz
00:08:03besteht bei den meisten Libraries das Risiko, dass sie in Zukunft nicht mehr weiterentwickelt werden,
00:08:11je nachdem, wer überhaupt daran arbeitet. Und deshalb nutze ich persönlich auch gerne wieder pures CSS.
00:08:17Das ist mir wichtig, weil ich das früher schon immer so gemacht habe. Und ich kann es nicht oft genug sagen:
00:08:22Ich wünsche Tailwind nur das Beste und nutze es nach wie vor in vielen Projekten. Es ist nicht so,
00:08:28dass ich es hassen würde. Ich experimentiere nur gerade in einigen Projekten damit, es wegzulassen.
00:08:35Und egal, ob es für euch um Tailwind geht oder um etwas völlig anderes – ich würde mir,
00:08:41und das galt auch schon vor der KI-Ära, immer zweimal überlegen, ob ich eine Drittanbieter-Library nutze.
00:08:46Es gibt viele gute Gründe dafür. Zum Beispiel ist Better Auth für die Authentifizierung großartig.
00:08:53Das würde ich definitiv nutzen. Aber wenn es eine Library ist, die man leicht ersetzen kann,
00:08:57lohnt sich vielleicht ein zweiter Blick oder ein zweiter Gedanke.
00:09:04it might be worth a second look or thought, I guess.