Veröffentlichung von Tailwind CSS v4.0

 (tailwindcss.com)
1 Punkte von GN⁺ 2025-01-24 | 1 Kommentare | Auf WhatsApp teilen
  • Tailwind CSS v4.0 ist eine Release, bei der das Framework von Grund auf neu geschrieben wurde, wodurch sich die Build-Performance deutlich verbessert und der Ablauf für Konfiguration und Anpassung stärker auf CSS verlagert
  • Beim Referenzprojekt Catalyst wurde der vollständige Build von 378 ms in v3.4 auf 100 ms in v4.0 beschleunigt, also um das 3,78-Fache; inkrementelle Builds ohne neues CSS verbesserten sich von 35 ms auf 192 µs, also um das 182-Fache
  • Die Installation wurde mit einer einzigen Zeile @import "tailwindcss" und standardmäßigen Zero-Config-Vorgaben vereinfacht; Vite-Nutzer können statt PostCSS @tailwindcss/vite verwenden
  • v4.0 nutzt moderne CSS-Funktionen wie Cascade Layers, @property, color-mix() und Logical Properties und führt automatische Content-Erkennung sowie integrierte @import-Verarbeitung ein
  • Container Queries, 3D-Transforms, eine erweiterte Gradient-API, @starting-style, not-*, field-sizing, color-scheme, inert und mehr sind jetzt Kernfunktionen, wodurch die Abhängigkeit von separaten Plugins sinkt

Hochleistungs-Engine von Grund auf neu geschrieben

  • Tailwind CSS v4.0 ist eine Version, bei der das Framework auf Basis jahrelanger Architektur-Erfahrung von Grund auf neu entwickelt wurde
  • In internen Projekt-Benchmarks sind vollständige Rebuilds mehr als 3,5-mal schneller und inkrementelle Builds mehr als 8-mal schneller geworden
  • Die medianen Build-Zeiten auf Basis von Catalyst sind wie folgt
    • Vollständiger Build: v3.4 378 ms → v4.0 100 ms, Verbesserung um das 3,78-Fache
    • Inkrementeller Rebuild mit neuem CSS: 44 ms → 5 ms, Verbesserung um das 8,8-Fache
    • Inkrementeller Rebuild ohne neues CSS: 35 ms → 192 µs, Verbesserung um das 182-Fache
  • Inkrementelle Builds, bei denen kein neues CSS kompiliert werden muss, sind über 100-mal schneller und werden im Mikrosekundenbereich abgeschlossen
    • Je länger man an einem Projekt arbeitet, desto häufiger verwendet man bereits genutzte Klassen wie flex, col-span-2 oder font-bold erneut, sodass solche Builds oft auftreten

Nutzung der modernen CSS-Plattform

  • v4.0 nutzt die Weiterentwicklungen der Web-Plattform seit Tailwind CSS v3.0 aktiv aus
  • Die wichtigsten zugrunde liegenden CSS-Funktionen sind
    • Native Cascade Layers: erlauben eine feinere Kontrolle darüber, wie unterschiedliche Stilregeln miteinander interagieren
    • Registered Custom Properties: ermöglichen Gradient-Animationen und verbessern die Performance auf großen Seiten deutlich
    • color-mix(): erlaubt die Anpassung der Deckkraft aller Farbwerte einschließlich CSS-Variablen und currentColor
    • Logical Properties: vereinfachen RTL-Unterstützung und reduzieren die Größe des generierten CSS
  • Diese Funktionen vereinfachen auch die interne Implementierung von Tailwind, verkleinern die Fehleroberfläche und erleichtern die Wartung

Vereinfachte Installation und Build-Integration

  • Der Installationsablauf wurde mit weniger Schritten und Boilerplate gestrafft
    • npm i tailwindcss @tailwindcss/postcss
    • @tailwindcss/postcss zum PostCSS-Plugin-Setup hinzufügen
    • In der CSS-Datei @import "tailwindcss" verwenden
  • In v4.0 kann Tailwind statt über die Direktive @tailwind mit einer CSS-Zeile eingebunden werden
  • Es gibt einen Zero-Config-Ablauf, mit dem man ohne jegliche Konfiguration starten kann, einschließlich der Pfade zu Template-Dateien
  • Ohne zusätzliches externes Plugin werden @import-Regeln gebündelt; für Vendor Prefixing und die Umwandlung moderner Syntax wird intern Lightning CSS verwendet
  • Vite-Nutzer können statt PostCSS @tailwindcss/vite wählen
    • Tailwind CSS v4.0 ist bereits als PostCSS-Plugin schnell, mit dem Vite-Plugin ist aber noch bessere Performance möglich

Automatische Content-Erkennung und integrierte Imports

  • Die in v3 erforderliche Konfiguration des content-Arrays wird in v4.0 durch automatische Erkennungsheuristiken ersetzt
  • Einträge in .gitignore werden automatisch ignoriert, damit keine Abhängigkeiten oder nicht versionierte generierte Dateien gescannt werden
    • Beispiele: /node_modules, /coverage, /.next, /build
  • Binäre Erweiterungen wie Bilder, Videos oder .zip werden ebenfalls automatisch ignoriert
  • Wenn standardmäßig ausgeschlossene Quellen explizit hinzugefügt werden müssen, kann in der CSS-Datei die Direktive @source verwendet werden
    • @source "../node_modules/@my-company/ui-lib";
    • @source verwendet dieselben Heuristiken, sodass binäre Dateitypen ohne separate Erweiterungsangabe ausgeschlossen werden
  • Vor v4.0 war zum Inline-Einfügen anderer CSS-Dateien per @import ein separates Plugin wie postcss-import nötig; jetzt ist mit der integrierten Import-Unterstützung kein weiteres Tool mehr erforderlich
    • Das Import-System wurde speziell für Tailwind CSS entwickelt und ist eng in die Engine integriert, wodurch es schneller arbeitet

CSS-first-Konfiguration und Theme-Variablen

  • Eine der großen Änderungen in v4.0 ist, dass die Projektkonfiguration nicht mehr in JavaScript, sondern direkt in CSS erfolgt
  • Statt einer Datei tailwind.config.js kann die Anpassung mit @theme in der CSS-Datei vorgenommen werden, die Tailwind importiert
    • Design-Tokens definieren
    • Benutzerdefinierte Utilities definieren
    • Benutzerdefinierte Variants definieren
  • Die in @theme definierten Design-Tokens werden standardmäßig als CSS-Variablen bereitgestellt
    • Beispiele: --font-display, --breakpoint-3xl, --color-avocado-500, --ease-fluid
  • Diese erzeugten CSS-Variablen können zur Laufzeit in normalem CSS referenziert werden
    • Wiederverwendung in Inline-Styles
    • Übergabe an Bibliotheken wie Motion zur Animationsverarbeitung

Dynamische Utility-Werte und Variants

  • v4.0 vereinfacht viele Utilities und Variants so, dass bestimmte freie Werte ohne Konfiguration akzeptiert werden
  • Für Grids können gewünschte Größen ohne separate Konfiguration verwendet werden
    • Beispiel: grid grid-cols-15
  • Auch benutzerdefinierte boolesche Data-Attribute lassen sich ohne vordefinierte Deklaration ansprechen
    • Beispiel: data-current:opacity-100
  • Spacing-Utilities wie px-*, mt-*, w-*, h-* werden dynamisch aus einer einzigen Spacing-Scale-Variablen abgeleitet
    • Beispiel: --spacing: 0.25rem
    • w-17 wird in der Form calc(var(--spacing) * 17) erzeugt
  • Das mit v4.0 veröffentlichte Upgrade-Tool vereinfacht die Syntax in den meisten Fällen automatisch, wenn es erkennt, dass freie Werte nicht mehr nötig sind

Farbpalette und Container Queries

  • Die gesamte Standard-Farbpalette wurde von rgb auf oklch umgestellt
    • Dadurch wird ein größerer Gamut jenseits der Grenzen des sRGB-Farbraums genutzt, was zu lebendigeren Farben führt
    • Da versucht wurde, das Gleichgewicht zwischen den Farben aus v3 beizubehalten, sollte sich das Upgrade bestehender Projekte nicht wie eine Breaking Change anfühlen
  • Unterstützung für Container Queries gehört in v4.0 zum Core, sodass das Plugin @tailwindcss/container-queries nicht mehr erforderlich ist
  • Mit der neuen Variant @max-* lassen sich Max-Width-Container-Queries verwenden
  • Wie bei normalen Breakpoint-Variants können @min-* und @max-* kombiniert werden, um Bereiche für Container Queries zu definieren

3D-Transforms und erweiterte Gradient-API

  • v4.0 ergänzt eine API für 3D-Transforms
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • Auch die Gradient-Funktionen wurden erweitert, sodass sich ohne eigenes CSS vielfältigere Effekte erzeugen lassen
  • Lineare Gradients können einen Winkelwert annehmen
    • Beispiel: bg-linear-45
    • Das bisherige bg-gradient-* wurde in bg-linear-* umbenannt
  • Der Interpolationsmodus von Gradient-Farben kann über Modifier gesteuert werden
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • Die Standardinterpolation in v4.0 ist OKLAB; Modifier für andere Farbräume können ebenfalls verwendet werden
  • Mit den neuen Utilities bg-conic-* und bg-radial-* lassen sich konische und radiale Gradients erstellen
    • Sie funktionieren zusammen mit vorhandenem from-*, via-* und to-*
    • Eingeschlossen ist Unterstützung für freie Werte zur Detailsteuerung wie Interpolationsmodus und Gradient-Position

Neue Variants und Utilities

  • Die neue Variant starting unterstützt CSS @starting-style
    • Damit lassen sich Property-Transitions erzeugen, wenn ein Element erstmals angezeigt wird
    • Elemente, die auf der Seite erscheinen, können ohne JavaScript animiert werden
    • Die Browser-Unterstützung ist für viele Teams möglicherweise noch nicht ganz ausreichend, nähert sich aber diesem Punkt
  • Die neue Variant not-* unterstützt die CSS-Pseudoklasse :not()
    • Beispiel: not-hover:opacity-75
    • Auch Media Queries und @supports-Queries können negiert werden
  • Darüber hinaus fügt v4.0 die folgenden Utilities und Variants hinzu
    • inset-shadow-*, inset-ring-*: bis zu vier Box-Shadow-Layer können auf einem einzelnen Element gestapelt werden
    • field-sizing: unterstützt automatische Größenanpassung von Textareas ohne JavaScript
    • color-scheme: entfernt helle Scrollbars im Dark Mode
    • font-stretch: passt Variable Fonts mit unterschiedlichen Breiten an
    • inert: stylt nicht interaktive Elemente, die mit dem Attribut inert markiert sind
    • nth-*: unterstützt Styling der nth-Familie
    • in-*: funktioniert ähnlich wie group-*, aber ohne group-Klasse
    • :popover-open: zielt mit der bestehenden Variant open auch auf geöffnete Popovers
    • Descendant-Variant: stylt alle untergeordneten Elemente

Einstieg und Upgrade-Pfad

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-24
Meinungen auf Hacker News

  • Ich habe Tailwind früher scharf für mehrere Schwächen und seine tatsächliche Inkompatibilität mit modernen „reinen“ Web-Ansätzen kritisiert, aber der große Fortschritt in v4 freut mich sehr.
    Dass man auf Tailwind-Themes als native CSS-Variablen zugreifen kann und die Dokumentation sogar ein Beispiel für eine Button-Komponente enthält, die in einem externen Stylesheet mit nativen Variablen geschrieben ist, ist eine enorme Veränderung.
    Auch dass man es nur mit CSS konfigurieren kann, ist großartig; Tailwind fühlt sich jetzt nicht mehr wie ein JavaScript-artiges „virales“ Framework an, das vernünftige Architekturen verschlingt, sondern wie ein Utility, das man jedem Projekt hinzufügen kann.
    Ob die Kritik der letzten Jahre Wirkung gezeigt hat oder ob man selbst zu guten Schlussfolgerungen gekommen ist: Ein großer Teil der Pro-/Contra-Debatte um Tailwind wirkt jetzt weniger relevant, und das ist eine sehr gute Sache. Jetzt kann man sich darauf konzentrieren, Produkte zu bauen.

    • In der praktischen Nutzung bin ich weiterhin kritisch, aber es ist erstaunlich, wie gut Tailwind zu KI-generierten Workflows passt.
      Weil sich alles systematisch ausdrücken lässt, funktioniert es wirklich gut, und darin steckt etwas äußerst Nützliches.
    • Dass die Pro-/Contra-Debatte um Tailwind nicht mehr relevant sei, sehe ich anders; als Designer/Design Engineer habe ich zwei Probleme damit.
      Erstens haben JavaScript-/Tailwind-Engineers die Design-Diskussionen an sich gerissen. Statt „Utility-first“, „ungenutzten Code entfernen“ und „typsicherem CSS“ geht es bei Designsystemen eher um Fragen wie, ob man in der Typografie Perfect Fifth oder Perfect Fourth verwenden sollte.
      Zweitens erschwert Tailwind die Beteiligung am tatsächlichen Produktionsprozess. Designentscheidungen werden in schwer verständlichen React-Komponenten-Ausdrücken wie flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)] vergraben.
      Für JavaScript-Engineers mag das nachvollziehbar sein, für systematisches Design ist es aber eine Hürde. Statt präzise mathematische Beziehungen in CSS auszudrücken, nutzt man letztlich bequemere Inline-Styles.
    • Ich hätte gern nur die Farbpalette von Tailwind CSS.

  • CSS ist deutlich einfacher zu benutzen als früher, und die meisten Browser verhalten sich inzwischen konsistent.
    Es ist lernenswert, weil man keinen Build-Schritt braucht und das Markup nicht mit übermäßig viel Code zumüllt.
    Man kann in HTML auch direkt das Attribut style verwenden, was früher wegen der Trennung von Zuständigkeiten vermieden wurde. Daher frage ich mich, warum man nun einen ähnlichen Ansatz wieder einführen will. Vielleicht nur, um ein paar Zeichen zu sparen?
    Das Attribut style wirkt sogar intuitiver, weil man den Code im Kopf nicht erst umwandeln muss. Ich sehe den Reiz nicht recht.

    • Mit dem Attribut style kann man einiges nicht tun. Zum Beispiel Pseudoklassen wie :hover, :focus, Pseudoelemente wie ::before, ::after, Media Queries sowie Keyframes und Animationen.
      In großen Projekten ist auch die Developer Experience nicht gut.
      Das bald standardisierte @scope ist dagegen eine gute Ergänzung, um Styles nahe am Einsatzort zu platzieren: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • Heutzutage wird Tailwind häufig zusammen mit einem Komponenten-Abstraktionssystem verwendet, das als Abstraktionsschicht statt als bloße CSS-Klassen dient.
      Komponentenabstraktion trennt Bedeutung und Styling stärker. In beiden Fällen muss man die Abstraktion „hero“ finden, aber in der Komponentenwelt abstrahiert man nicht nur die Styles, sondern auch die Namen der HTML-Tags.
      So oder so sind die „Style-Details“ vom „Content“ in der Seiten-Quelldatei getrennt. Für Separation of Concerns, also eine bessere Trennung von Inhalt und Darstellung, kann man einen Build-Schritt in Kauf nehmen.
    • Der Reiz liegt darin, dass man keine CSS-Klassennamen erfinden muss, dass es direkt neben dem HTML steht und dadurch gut lesbar ist, und dass die Benennung standardisiert ist, sodass überall dieselben Regeln gelten.
      Außerdem muss man weniger separate Dateien pflegen und weniger ungenutzte Komponenten entfernen.
      Man kann Media Queries verwenden, was mit dem style-Attribut nicht ging, und es besteht nicht die Gefahr, Klassen zu ändern, die an anderer Stelle genutzt werden. Der globale Scope von CSS hat Vorteile, ist aber auch riskant.
    • Das ist die Folge davon, dass die enge Kopplung an React viel zu selbstverständlich geworden ist.
      Styles gelten als etwas, das zu Komponenten gehört, nicht zu einem Designsystem. Das JavaScript-first-Engineering-Ökosystem braucht mehr designgetriebene Unternehmen, die die Stärke von modernem CSS und systematischem Design kennen.
    • Wenn man sich die Zahl der Dateien ansieht, die man in großen Projekten verwalten muss, wirkt Tailwind ziemlich attraktiv.
      Der normale .css-Ansatz führt zu seltsamen Namen, Duplikaten und potenziellen Konflikten. css modules sind zwar eine Option, verdoppeln aber pro Komponente/Seite faktisch die Anzahl der Dateien.
      sass oder less fühlen sich an, als würden sie die Probleme von css modules und normalem .css miteinander vermischen.
      Ich mag oder hasse Tailwind nicht grundsätzlich; anfangs mochte ich es überhaupt nicht, aber in einem Projekt mit über 200 Dateien aus Komponenten und Seiten erkennt man den Wert.

  • Meine erste Reaktion auf Tailwind war: „lästig“. Ich kenne CSS bereits, und es fühlte sich an, als müsste ich CSS jetzt noch einmal neu lernen.
    Es wirkt ähnlich wie bei Eltern, die ihrem Kind bei den Mathe-Hausaufgaben helfen wollen, nur um festzustellen, dass die Methode in der Schule heute völlig anders ist als früher: Die eigene Lösung ist immer noch korrekt, wird aber nicht akzeptiert, und das Kind ist genervt, weil es zwei Systeme zusammenbringen muss.
    Ich verstehe die Stimmung im Team, dass man es einfach nutzen sollte, weil es gut funktioniert und gut skaliert, und ich habe das auch erlebt.
    Trotzdem bevorzuge ich weiterhin normale Stylesheets, die auf Klassen oder Tags zielen. Erst recht, seit CSS nun verschachtelte Selektoren unterstützt.
    Es gibt zwar Probleme bei der Verwaltung von Stylesheets, und mir gefällt der Ansatz wie bei Remix/React Router, CSS-Dateien auf Routenebene zu definieren und anzuwenden. Wenn das nicht reicht oder dynamische Styles in einer .css-Datei zu kompliziert werden, ist style={{...}} immer noch möglich.
    CSS ist mächtig, flexibel und skalierbar; Tailwind fühlt sich für mich daher eher wie eine Einschränkung als wie eine Verbesserung an. Warum es weiter so beliebt ist, weiß ich nicht genau, aber ich denke, in 3 bis 4 Jahren sind alle wieder zu etwas anderem weitergezogen.

    • Anfangs war es frustrierend, weil es sich anfühlte, als müsste ich CSS neu lernen, und früher habe ich dasselbe Argument vertreten.
      Aber durch Beiträge zu Open-Source-Projekten, die Tailwind verwenden, habe ich mich daran gewöhnt, und inzwischen empfinde ich es anders.
      Tailwind ist im Kern eher eine Kurzschreibweise für style={{…}}. Dinge, die in einer .css-Datei oder einem Style-Objekt mehrere Zeilen brauchen würden, erledigt eine Utility-Klasse mit ungefähr 15 Zeichen.
      Die Zeit, in der ich nach Dingen wie „visual text replacement css“ gesucht oder CSS-Cheatsheets und acht Jahre alte CSS-Tricks-Artikel durchwühlt habe, ist stark zurückgegangen. Stattdessen schaue ich fast immer in die Tailwind-Doku und finde schnell die Utility-Klasse, die das Gewünschte tut.
      Erstaunlich viel davon landet im mentalen Cache, und es fühlt sich deutlich besser an, als alles CSS auswendig lernen zu wollen, das man für Layout-Arbeiten braucht.
    • Ich denke, das liegt daran, dass jetzt die ganze Komponente in einer Datei steckt.
      Man muss CSS nicht separat anfassen, und die Styles stehen direkt bei dem Element, auf das sie angewendet werden, sodass man nichts gegeneinander abgleichen muss.
      Mit dem css-Attribut ginge das zwar auch, aber das Problem ist, dass alle gelernt haben, dass das der falsche Weg sei; außerdem ist eine Zeichenkettenliste mit mehreren Utilities einfacher als ein reines CSS-Objekt.
    • Einschränkungen reduzieren die mögliche Komplexität, und deshalb gewinnt Tailwind.
      Es ist ein großer Fortschritt, weil es ein kombinierbarer, standardisierter, modularer Wrapper über einem riesigen, komplexen System ist.
    • Ich lerne mit meinem Kind Mathe, und es ist nicht anders als das, was ich gelernt habe; ich kann die Aufgaben immer noch schnell lösen.
      In sozialen Medien gibt es dagegen Beiträge, die Multiplikation und Division durcheinanderwerfen und behaupten, es gebe nur eine richtige Antwort. Tailwind ist nicht so schlimm, aber aus der Perspektive eines Älteren wirkt es eher in diese Richtung.

  • Ich mag Tailwind. Ich habe es in den letzten vier Jahren in drei Projekten verwendet, und es war intuitiv, gut dokumentiert und einfach.
    Ich vermisse die Zeiten von emotion und styled-components nicht, in denen man jedem gestylten div im Projekt einen Namen geben musste.
    In Tailwind ist ein Container einfach ein div mit ein paar Klassen. Es gibt weniger Namensdiskussionen, und weniger Denk- und Review-Zeit wird fürs Benennen verschwendet.

    • Dieses Problem, dass man sich für jedes styled div einen Namen überlegen muss, sehe ich oft erwähnt, und es wundert mich etwas.
      Ich habe kaum je länger als eine Sekunde darüber nachgedacht, wie ich etwas benennen soll. Ist das für manche wirklich ein Blockadepunkt? Ich frage mich ernsthaft, ob man an dieser Stelle wirklich so gelähmt sein kann.
    • Wenn du von „ein paar Klassen“ sprichst, arbeitest du offenbar mit sehr guten Product Ownern.
      Die Leute, die ich erlebt habe, haben jedes erdenkliche Detail endlos spezifiziert. Sie behandeln Webformulare wie ihre persönliche HGTV-Renovierung.
      Als ich Tailwind einmal ausprobierte, gab es in meinem Markup um eine Größenordnung mehr Klassen als Markup selbst, und es wurde schnell schwer lesbar.
    • Ich habe es in mehreren Projekten ausprobiert, mochte es aber nicht. In großen Projekten wird es schnell unübersichtlich und fühlt sich wie das neue Bootstrap an.
      Im Moment bin ich mit einem CSS-in-JS-Workflow zufrieden: klassische CSS-Schreibweise mit LLM-Unterstützung. Ich zeige dem LLM ein Bild und bitte um eine Komponente, und sie kommt direkt mit passenden Namen zurück.
    • Wenn ich die Wahl habe, ist das einer der Hauptgründe, React zu meiden.
      Styling in React ist nicht besonders gut, und selbst mit Tailwind ist es nur die weniger schlechte Option.
      Wenn man ein Frontend-Framework und einen Build-Schritt nutzt, sind je nach Einsatzzweck Svelte und Astro gut. Man kann mit normalem CSS stylen, und wenn man Komponenten klein hält, braucht man kaum Klassennamen.
      Man verwendet Elementselektoren und lässt das Framework zur Build-Zeit die Styles scopen.

  • Ich habe Tailwind auf meiner Website ausprobiert und mochte es ziemlich, vielleicht aber aus etwas anderen Gründen als den üblichen.
    Der eigentliche Wert von Tailwind liegt darin, dass man alle Styles, die ein Element beeinflussen, an einer Stelle lesen kann.
    Die Klassennamen können lang werden, aber eine lange Zeile zu lesen ist viel schneller, als jedes Mal die Browser-Entwicklertools zu öffnen oder in einem oder mehreren Stylesheets hoch- und runterzuspringen.
    Wenn ich später zu dem Code zurückkomme, kann ich ihn selbstbewusst ändern, ohne Angst zu haben, versehentlich ein anderes Element zu verändern.
    Die kaskadierende Natur von CSS ist weiterhin nützlich, aber meistens möchte ich Styles auf ein einzelnes Element begrenzen. Für den Rest kehre ich zu CSS zurück, aber tatsächlich schreibe ich nur sehr wenig CSS. Meistens will ich nur Abstände anpassen.

    • Genau das ist meiner Meinung nach der Grund, warum Tailwind gut und bequem ist.
      Mir gefällt auch, dass „Wie mache ich X?“ keine 30-minütige Recherche ist, sondern mit einer schnellen Suche in der Doku erledigt ist.
    • Werkzeuge, die alle auf ein Element angewendeten Styles anzeigen, gibt es auch in IDEs. Zum Beispiel „Show Applied Styles for Tag“ in IntelliJ oder auch die Chrome-Entwicklertools, die das gut lesbar darstellen.
      Die Tailwind-Schnipsel in diesem HN-Thread sehen im Vergleich dazu ziemlich abschreckend aus.
    • Ich stimme bis zu einem gewissen Grad zu, aber dasselbe Problem bleibt bestehen.
      Wenn man einem div text-xl hinzufügt und darin verschachtelte div- und span-Elemente stehen, erben sie alle text-xl; um bei den verschachtelten Elementen zu sehen, was text-xl verursacht, muss man am Ende doch die Elementhierarchie nach oben zurückverfolgen.
      Insgesamt ist es aber trotzdem etwas einfacher.

  • Formulierungen wie „kürzere Build-Zeiten“, „keine @tailwind-Direktiven mehr“, „keine JavaScript-Konfiguration“ und „für das moderne Web entworfen“ klingen für mich so:
    CSS kann inzwischen alles, was wir früher selbst gemacht haben, aber tun wir weiter so, als bräuchten wir es noch

    • Wenn man es schon hassen will, sollte man zumindest versuchen zu verstehen, was es ist und warum Leute es nutzen
    • Das Verkaufsargument von Tailwind war von Anfang an: „fast Inline-CSS, aber weniger umständlich als das style-Attribut und viel einfacher zu optimieren“
    • Ich frage mich, was man früher mit normalem CSS nicht machen konnte, sodass Tailwind nötig war
      Tailwind entspricht CSS doch fast 1:1, oder?
    • Ich frage mich, ob du es wirklich so aufgefasst hast
      Ich verstehe, wenn man Tailwind nicht mag, aber statt einen Strohmann anzugreifen, wäre es besser zu sagen, was genau man an Tailwind nicht mag
      Es ist auch nicht gut, das Open-Source-Projekt anderer Leute und die Menschen, die es sinnvoll nutzen, herabzusetzen

  • Ich würde gern Leute fragen, die sich mit CSS gut auskennen. Ich tue das nicht
    Ich aktualisiere gerade ein privates Phoenix-Projekt auf 1.7, und weil Phoenix inzwischen standardmäßig Tailwind verwendet, wollte ich es statt Bootstrap ausprobieren
    Bisher sah die Bootstrap-Version „ganz okay“ aus, aber die Tailwind-Version wirkt wie ein Durcheinander
    Was ist der einfachste Weg, brauchbar aussehende Defaults zu bekommen, ohne versuchen zu müssen, Designer zu werden? Oder sollte ich einfach wieder Bootstrap installieren und fertig?

    • In dem Fall würde ich Bootstrap wieder installieren
      Tailwind gibt dir Werkzeuge, wenn du das Design kontrollieren willst, aber am Ende musst du das Design selbst kontrollieren
      Wenn du einfach etwas willst, das gut aussieht und auch ein Bootstrap-Gefühl haben darf, ist Bootstrap richtig
      Theoretisch gibt es Projekte, die Bootstrap auf Tailwind neu implementieren und dir einen Bootstrap-artigen Ausgangspunkt zusammen mit der Stärke von Tailwind geben können, aber in der Praxis habe ich noch keines gesehen, das besser funktioniert als einfach Bootstrap zu verwenden
    • Für diesen Zweck nutze ich DaisyUI. Eine Beispiel-Demo-Site gibt es hier: https://nwk-landing-kit.netlify.app
      Die DaisyUI-Dokumentation ist hier: https://daisyui.com
    • Wenn du Bootstrap-ähnliche Komponenten suchst, ist https://flowbite.com/ kostenlos einen Versuch wert
      Auch für Tailwind gibt es kostenpflichtige Komponenten, die man einfach kopieren und einfügen kann. Wenn man sich eingearbeitet hat, ist es praktisch, dass man Flowbite-Komponenten nach und nach anpassen kann
    • Hängt davon ab, wer bezahlt
      Wenn du Jobsicherheit hast und an Dingen herumprobieren willst, kannst du mit Tailwind spielen. Trendbewusste und lautstarke Leute scheinen Tailwind im Allgemeinen zu mögen
      Wenn es aber dein eigenes Projekt ist, du es selbst finanzierst oder eine Deadline hast, ist es besser, das bereits bekannte Bootstrap zu verwenden und sich darauf zu konzentrieren, die Arbeit fertigzubekommen, statt sich in einem Abnutzungskrieg um die UI zu verlieren
    • Tailwind und Bootstrap zu vergleichen ist eher wie Äpfel mit Apfelkuchen zu vergleichen
      Tailwind liefert Klassen, die man stapelt, um Komponenten zu bauen
      Mit einer UI-Komponenten-Quelle dazu wäre es einfacher. Ich habe früher TailwindUI verwendet, aber das war kostenpflichtig; es dürfte auch gute kostenlose Alternativen geben

  • In der Diskussion „Tailwind oder nicht“ gibt es ein klares Muster. Es wiederholt sich jedes Mal, wenn Tailwind erwähnt wird
    Es gibt Leute, die es nie länger als 30 Minuten ernsthaft benutzt haben, es nur kurz ausprobiert oder nur die Doku überflogen haben. Sie mögen Tailwind nicht und bevorzugen Dinge wie „reines CSS“
    Auf der anderen Seite gibt es Leute, die es in echten Projekten und in Teams mit mehr als einer Person eingesetzt haben. Sie verstehen den Wert, akzeptieren die Trade-offs und mögen es
    Ich habe viele gesehen, die von der ersten Gruppe in die zweite gewechselt sind, aber fast niemanden, der von der zweiten wieder in die erste zurückgegangen ist
    Deshalb ist Tailwind erfolgreich. In den Augen von Puristen mag es nicht schön sein, aber für Menschen, die bauen, und für Pragmatiker ist es wirklich hervorragend

    • Ich glaube, ich passe in keine der beiden Gruppen so richtig
      Ich bin nicht gegen Tailwind, aber der Grund, warum ich es noch nicht verwendet habe, ist, dass ich nicht klar sehe, warum es ein besserer Ansatz sein soll als andere Optionen wie Web Components oder React Styled Components
      Das größte Problem ist, dass Tailwind HTML mit unzähligen Utility-Klassen überlädt und es dadurch schwer lesbar und wartbar macht
      Ich verstehe, dass das besser ist als riesige globale CSS-Dateien und klassisches CSS auf Basis von Tag-Namen, aber es gibt bereits Möglichkeiten, komponenten-gescoptes CSS zu verwenden, ohne den globalen Namensraum zu verschmutzen. Web Components und Styled Components sind Beispiele dafür
      Beide binden Styles direkt an Komponenten oder allgemeiner an eine bestimmte Gruppe von HTML-Tags, wodurch leichter zu sehen ist, welche Styles wo angewendet werden
      Man braucht keine globalen Klassennamen, und die Sorge vor unerwünschten Nebenwirkungen oder Konflikten ist geringer. Entfernt man eine Komponente, werden die zugehörigen Styles ebenfalls entfernt, sodass man sich keine Sorgen um ungenutztes CSS machen muss. Dank Shadow DOM besteht auch kein Risiko, dass Styles einer Komponente unbeabsichtigt andere Komponenten beeinflussen
      Mir ist wichtig, HTML kurz und lesbar zu halten, indem ich präsentationsbezogene Styles nicht direkt ins Markup mische. Wenn wie bei Tailwind alle Styles im class-Attribut landen, entstehen lange Klassenlisten in einer Zeile, und wenn dazu noch echte Klassennamen kommen, wird das HTML unübersichtlich
      Es ist schwer, auf einen Blick zu erkennen, welche Styles angewendet werden, und auch sauberes Einrücken ist schwierig. Das erinnert mich an mehrere Gründe, warum man früher von Inline-style-Attributen in HTML weggekommen ist
      Ich hasse Tailwind nicht, aber in Bezug auf Lesbarkeit, Wartbarkeit und Trennung der Verantwortlichkeiten sehe ich keinen klaren Vorteil gegenüber Web Components oder Styled Components, und ich habe noch große unbeantwortete Bedenken
      Ich habe die Dokumentation gelesen, es aber nicht benutzt, und es fällt mir schwer zu verstehen, warum ich Tailwind statt anderer Optionen wählen sollte. Die Tatsache, dass mitten in gewöhnlichem HTML extrem viele Klassen auftauchen, macht für mich beides schwer lesbar

  • Ich erkenne an, dass es Leute gibt, die Tailwind sinnvoll einsetzen und damit produktiv sind. Aber da Tailwind inzwischen überall ist, sieht man auch überall diesen sauberen, aber austauschbaren Look

    • Das verwechselt Tailwind mit TailwindUI/shadcn usw.
      Im Allgemeinen beeinflusst Tailwind den Stil nicht stärker als normales CSS. Es gibt ein paar Ausnahmen: Dinge wie Schatten sind etwas stärker standardisiert, und die Indigo-Farbpalette hat zuletzt auch außerhalb davon Einfluss genommen
    • Tailwind liefert sinnvolle Defaults, hat aber keinen großen Einfluss auf das Design
      Die Leute neigen nur dazu, Websites auf eine bestimmte Art zu gestalten. Besonders, wenn sie es zusammen mit ShadCn verwenden
    • Für mich fühlt sich das eher wie etwas Gutes an. Tailwinds Optionen sind gut gestaltet und funktionieren gut
      Ich sehe das ähnlich wie bei Inter als Website-Schriftart, die wie eine neue Helvetica verwendet wird. Wenn viele Leute sie nutzen und sie gut aussieht, warum sollte man sie dann nicht verwenden?
    • Früher hat man so etwas auch über Bootstrap gehört, aber die Bootstrap-Websites, die ich gebaut habe, sahen einander nicht ähnlich
      Bootstrap bot schon lange vor Tailwind sehr viele Utility-Klassen, sparte viel Zeit und zwang einem keinen bestimmten Look auf
      Man musste nur die gewünschten Klassen importieren. Natürlich wäre es etwas anderes gewesen, wenn man die Sass-Quelldateien nicht heruntergeladen hätte, aber das wäre eine törichte Entscheidung gewesen
    • Meine Sicht auf dieses Problem ist, dass gute UI-Frameworks, also Kombinationen aus Tailwind und Komponenten, noch selten sind
      Deshalb verwenden die meisten Projekte eine sehr kleine Zahl von Frameworks. Wenn 4–5 weitere hochwertige UI-Projekte entstehen, insbesondere mit stärker unterschiedlicher Stilrichtung, würde die Vielfalt zunehmen
      Wie bei vielen kreativen Arbeiten scheint auch Design erstaunlicherweise von sehr wenigen Menschen geprägt zu werden
      Ich wünschte, mehr Leute wüssten das. Es gibt vermutlich talentierte Menschen, die nichts bauen, weil sie denken: „Selbst wenn ich etwas mache, hört niemand darauf“
      Aber wenn einige von ihnen es versuchen, könnten sie meiner Meinung nach einem großen Teil des Webs neue UIs eröffnen

  • Tailwind ist ein Beleg für die Vorteile von Inline-Styles – also dafür, Dinge zu stylen, ohne ihnen Namen zu geben –, für die Universalität von Strings und zugleich für deren Grenzen
    Ich bin gespannt auf das, was als Nächstes kommt, und bis dahin werde ich Tailwind widerwillig verwenden