Heim >Web-Frontend >js-Tutorial >Gedanken zu CSS-in-JS und Utility-First CSS (Tailwind)

Gedanken zu CSS-in-JS und Utility-First CSS (Tailwind)

Linda Hamilton
Linda HamiltonOriginal
2025-01-26 08:33:09458Durchsuche

Thoughts on CSS-in-JS and Utility-First CSS (Tailwind)

Jüngste UI-Entwicklungsaufgaben bei der Arbeit boten eine wertvolle Gelegenheit, CSS-in-JS und Utility-First-CSS (Tailwind) noch einmal zu bedenken. Meine tägliche Arbeit beinhaltet selten die Arbeit an der Benutzeroberfläche, daher war dies eine erfrischende, wenn auch etwas eingerostete Erfahrung. Mein Ziel ist es hier, einen unvoreingenommenen Vergleich beider Ansätze anzubieten und mich dabei auf den Entwicklungsworkflow und die Tools zu konzentrieren.

Tailwind CSS

Die Wahl unseres Teams für Tailwind war eher spontan, getrieben von dem Wunsch nach Effizienz. Während die Vertrautheit unterschiedlich war und eine gewisse Skepsis herrschte, war die Zeitersparnis ein überzeugender Faktor.

Positive Aspekte

Integration, benutzerdefinierte Variablenerstellung und Theme-Entwicklung verliefen bemerkenswert einfach. Das Erweitern oder Erstellen neuer Themes erwies sich als intuitiv:

<code>@import "tailwindcss";
@theme {  
  --font-script: Comic-sans; // theme extension
  --color-*: initial;  // default overrides
  --color-white: #fff;
  ...
}</code>

Die Einbeziehung von Basisstilen, sogar etwas so Einfachem wie das Entfernen von Standardrändern und Polsterungen, war eine erhebliche Zeitersparnis. Dadurch wurde der Arbeitsablauf erheblich rationalisiert.

Tailwind strebt ein intuitives Erlebnis an, was ihm weitgehend gelingt. Einige Aspekte fühlen sich jedoch weniger intuitiv an. Konventionen zur Benennung von Klassen sind zwar im Allgemeinen klar (z. B. p für Auffüllung, mb für Rand unten), weisen jedoch gelegentlich Inkonsistenzen auf (z. B. rounded für border-radius). Dies kann durch benutzerdefinierte Theme-Definitionen gemildert werden:

<code>@theme { 
  --border-radius: var(--rounded);
  --border-radius-none: var(--rounded-none);
  --border-radius-full: var(--rounded-full);
  // ...etc.
  --rounded*: initial;
}</code>

Gesamteindrücke

Lesbarkeit und Wartbarkeit waren weniger problematisch als erwartet. Während die Syntax eine Anpassungszeit erforderte und IntelliSense von VS Code gelegentlich verzögerte, blieb der Code überschaubar und einfach zu navigieren, selbst wenn mehrere Klassen auf kleine Elemente angewendet wurden.

Wichtiger Hinweis: Vermeiden Sie es, sich zu sehr auf @apply zu verlassen. Dies kann zum unerwünschten Ergebnis von „Tailwind-in-CSS“ führen.

Serverseitiges Rendering (SSR)

Entscheidend ist, dass Tailwind während des Tests keine SSR-Probleme aufwies. Die nahtlose Integration war ein wesentlicher Vorteil.

CSS-in-JS (Emotion)

Im Zeitraum 2024–2025 verzeichnen CSS-in-JS-Lösungen einen Rückgang der Beliebtheit, was vor allem auf die Zunahme von Serverkomponenten in Frameworks wie React zurückzuführen ist.

Siehe: https://www.php.cn/link/9cb4d40fce0492278209290ee3e4ae31

Wichtige Herausforderungen

Das Hauptproblem ergibt sich aus der Abhängigkeit von der Kontext-API von React. Das Mischen von Server- und Clientkomponenten in einer React-Anwendung kann zu Datenverlust führen und korrekte Stilaktualisierungen bei erneuten Renderings verhindern. Diese Einschränkung ist vielen CSS-in-JS-Bibliotheken eigen.

Es gibt zwar kompatible Alternativen, das zugrunde liegende Problem bleibt jedoch bestehen. Der Blog von Joshua Comeau bietet einen hervorragenden Kontext zu diesem Thema.

Retrospektive

Im Nachhinein fühlte sich die Umstellung auf CSS-in-JS weniger vorteilhaft an als zunächst erwartet. Während die enthaltene Entwicklungserfahrung (alles in einer Datei) zunächst ansprechend war, erwies sich dieser Vorteil mit der Zeit als weniger bedeutend.

Langfristige Überlegungen

CSS-in-JS führte zu einem erhöhten Tipp- und Konfigurationsaufwand. Im Vergleich zu Tailwind fühlte es sich weniger effizient an. Während das bedingte Passen von Requisiten Kraft und Flexibilität bietet:

<code>@import "tailwindcss";
@theme {  
  --font-script: Comic-sans; // theme extension
  --color-*: initial;  // default overrides
  --color-white: #fff;
  ...
}</code>

Dies kann auch das Verständnis und die Umgestaltung des Codes erschweren. Übermäßiges Überschreiben von Stilen weist auf mögliche Inkonsistenzen im Designsystem hin:

<code>@theme { 
  --border-radius: var(--rounded);
  --border-radius-none: var(--rounded-none);
  --border-radius-full: var(--rounded-full);
  // ...etc.
  --rounded*: initial;
}</code>

Bei neuen Projekten würde ich CSS-in-JS wahrscheinlich vermeiden.

CSS-Variablen und Theming

CSS-Variablen sind von unschätzbarem Wert. Das einmalige Definieren einer Palette und deren Wiederverwendung in allen Komponenten vereinfacht das Styling und bietet ein ähnliches Erlebnis wie die Verwendung vordefinierter Komponentenvarianten.

<code>const Button = styled.button`
  background: ${props => props.variant === 'primary' ? "#ddd" : "#fff"};
`;

render(
  <div>
    <Button variant="primary">Primary</Button>
  </div>
);</code>

Postprozessoren und Konfiguration

Postprozessoren (z. B. PostCSS) sind für die Optimierung von CSS unerlässlich. Sie bieten erhebliche Vorteile:

  • cssnano: Entfernt nicht verwendeten Code.
  • postcss-nested: Aktiviert verschachteltes CSS ähnlich wie Sass.
  • stylelint: Bietet Flusenfunktionen.
  • autoprefixer: Fügt Herstellerpräfixe hinzu (wenn auch jetzt weniger kritisch).
  • postcss-import: Aktiviert @import-Anweisungen.

(Vollständige Liste: https://www.php.cn/link/2d280461b029134123f1f1a356e176b1)

Postprozessoren erhöhen zwar den Overhead, verbessern aber das Entwicklererlebnis und die CSS-Leistung. Die Vorteile überwiegen oft die Anfangsinvestition.

Lightning CSS

Lightning CSS (eine Rust-basierte Alternative zu PostCSS) bietet schnellere Build-Zeiten und viele der gleichen Funktionen. Es lohnt sich, einen Blick darauf zu werfen, wenn Sie eine gut integrierte Lösung suchen.

Zusammenfassung

Die CSS-Landschaft entwickelt sich rasant weiter und es entstehen ständig neue Tools und Ansätze. Meine Erfahrungen mit Tailwind und CSS-in-JS waren aufschlussreich und zeigten sowohl deren Stärken als auch Schwächen auf. Die Auswirkungen von RSC auf zukünftige CSS-Tools sind erheblich und erfordern weitere Überlegungen.

Das obige ist der detaillierte Inhalt vonGedanken zu CSS-in-JS und Utility-First CSS (Tailwind). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn