Wenn wir über Frameworks mit Utility-Klassen kritisieren, dann lasst uns fair damit umgehen

Ich bin hier nicht, um einen Schutzschild für CSS-Utility-Frameworks hochzuhalten. Ich mag diesen Ansatz selbst nicht besonders, und nichts ist über faire Kritik erhaben. Aber *fair* ist hier ein Schlüsselwort. Ich kann Ihnen nicht sagen, wie oft ich Utility-Styles mit Inline-Styles verglichen habe. Sarah Dayan hat es satt

[...] trotz zahlreicher Versuche, gängige Trugschlüsse zu widerlegen, müssen Enthusiasten von Utility-First weiterhin eine erstaunliche Menge an Missverständnissen richtigstellen. Und mit Abstand **ist das am meisten abgenutzte, überstrapazierte Klischee, dass Utility-Klassen nur Inline-Styles sind.**

Ich denke, dieser Vergleich wird es verdeutlichen

<div style="color: #3ea8ca;"></div>

<div class="color-blue"></div>

Das erste div hat eine `color`, die direkt in HTML gesetzt ist, und zwar ein extrem spezifischer Blautonwert. Das zweite hat eine `color`, die außerhalb von HTML gesetzt wird, mittels eines Klassennamens, mit dem Sie die Blautönung in CSS konfigurieren können. Sicher, die zweite ist ein ziemlich eingeschränkter Klassenname, da er, wie der Name schon sagt, nur eine Aufgabe erfüllt, aber er bietet immer noch eine gewisse Abstraktion, da die blaue Farbe geändert werden kann, ohne das Markup zu ändern. Es ist die gleiche Geschichte mit einer Utility-Klasse für Größen, sagen wir `size-xl`. Das ist auch eine Abstraktion, die wir verwenden könnten, um den Abstand eines Elements in CSS zu definieren, indem wir diesen Klassennamen als Selektor verwenden. Aber wenn wir `style="padding: 10px;"` direkt auf dem Element in HTML verwenden würden, ist das eine absolute Angabe, die eine Änderung des Wertes im Markup erfordert.

Um fair zu sein (was wir ja wollen), gibt es ziemlich viele Klassen in Utility-Frameworks, die so benannt sind, dass sie extrem nah an Inline-Styles agieren. Zum Beispiel bedeutet `top-0` in Tailwind `top: 0`, und es gibt keine Konfiguration oder Abstraktion dafür. Es ist nicht so, dass diese Klasse in CSS mit einem anderen Wert als Null aktualisiert wird, weil es im Namen steht. "Utility" ist eine gute Beschreibung dafür. Es ist sehr ähnlich wie ein Inline-Style.

All diese mit intelligenten Standardwerten konfigurierbaren Dinge bringen Utility-basierte Frameworks in eine andere Kategorie. Inline-Styles bieten keine Einschränkungen, wie Sie Dinge gestalten (außer harten Einschränkungen wie keine Pseudoelemente oder Media Queries), während eine begrenzte Anzahl von Utility-Klassen ziemlich viele Styling-Einschränkungen bietet. Diese Einschränkungen sind oft *wünschenswert*, da sie zu einem konsistenten und ansprechenden Design führen, anstatt zu einem inkonsistenten und schlampigen.

Um eine Metapher zu verwenden, die ich einmal in einem leicht anderen Kontext gehört habe: **Frameworks mit Utility-Klassen sind wie Banden-Bowling für Styling.** Verwenden Sie die Klassen, und es wird schon gutgehen. Sie werden vielleicht keinen Strike erzielen, aber auch keinen Gutterball.

Eine weitere unfaire Kritik, die ich in Gesprächen über Utility-Frameworks höre, ist, dass **man viel mehr CSS mitliefert.** Wenn Sie das tun, dann machen Sie definitiv etwas falsch. Meiner Meinung nach besteht der Hauptzweck dieses Ansatzes darin, *weniger* CSS auszuliefern (nur die Klassen, die Sie verwenden). Ich werde als Erster sagen, dass ein Build-Prozess, der dies genau und perfekt tut, tricky ist und zu einer ungesunden Menge technischer Schulden führen könnte, aber ich gebe zu, dass das Ausliefern von weniger CSS gut für die Leistung ist, wenn man es richtig macht. Tailwind ermutigt und hilft insbesondere dabei.

All das gesagt, denke ich, dass es alle möglichen Dinge gibt, die man an diesem Ansatz kritisieren kann. Zum Beispiel mag ich es persönlich nicht, all diese Klassen anzusehen. Ich mag es einfach nicht. Ich bin kein Absolutist, was perfekt abstrakte Klassen angeht, aber 10-20 Klassen auf einem Div nach dem anderen zu sehen, stört mich bei dem, was ich beim Templating von HTML tun möchte. Es fühlt sich schwieriger an, zu refaktorieren. Es fühlt sich schwieriger an, semantisch zu verstehen, was vor sich geht. Es ist schwieriger, diese Liste nach anderen Klassen zu parsen, die ich für nicht-stilistische Dinge benötige. Einige der Vorteile, die ich von Utilities erhalte, wie z. B. das Isolieren von Stilen genau dort, wo ich sie brauche, erhalte ich oft durch andere Werkzeuge.

Ich denke auch, dass Utility-Frameworks am besten in JavaScript-Komponenten-Setups mit Hot Module Reloading funktionieren. Andernfalls neigen HTML-Änderungen dazu, eine vollständige Seitenaktualisierung auszulösen. Zum Beispiel ist ein Tool wie Browsersync ziemlich gut. Es injiziert CSS, wenn sich Ihr CSS ändert. Aber es kann keine neuen HTML-Injektionen durchführen; es aktualisiert nur die Seite. Ohne Hot Module Reloading, was im Allgemeinen nicht für Ihre generischen HTML-Websites oder Static Site Generators gilt, erhalten Sie eine schlechtere DX während der Entwicklung.