Utility First, Component Second

• Man denkt bei einem Utility-First-Ansatz in CSS, etwa wie bei Tailwind CSS, oft nur daran, dem HTML eine Menge Klassen anzuhängen.

• Doch das ist nur die Oberfläche; im Kern geht es bei Utility First um die Frage nach dem richtigen Zeitpunkt der Komponentenbildung.

• Bei den frühen, in CSS populären Methoden entwickelte sich schnell ein Wartungs-Albtraum.

• Der OOCSS-Ansatz versuchte, dieses Problem durch Komponentengestaltung zu lösen. Die Wiederverwendbarkeit stieg, aber man stieß auf Schwierigkeiten bei der Definition von Komponentenbereichen.

• Komponenten dienen der Wiederverwendbarkeit, doch das Problem ist: Man weiß nicht, was in Zukunft wiederverwendet werden wird.

• Der Atomic-CSS-Ansatz versucht, das Problem zu lösen, indem für jede Eigenschaft genau eine Klasse vergeben wird. Die Entwicklung wurde dadurch schneller, aber das Wartungsproblem tauchte erneut auf.

• Die "Single Source of Truth" zerbricht viel zu leicht – man verlässt sich dabei auf globale Suchen-und-Ersetzen-Aktionen (die Abhängigkeit von externen Templates ist umständlich und begrenzt).

• Utility First bejaht im Gegensatz zu Atomic CSS explizit die Komponente. Und im Gegensatz zu OOCSS beginnt es mit Utilities. Eine Komponente wird dann gebaut, wenn sie tatsächlich benötigt wird.

• Die Frage, was als Komponente gebaut werden soll, wandelt sich in die Frage, wann sie gebaut werden soll.

• Mit anderen Worten sollte Utility First als eine Kombination und Weiterentwicklung beider Richtungen verstanden werden.

• Deshalb muss Utility First die Komponente noch stärker betonen: Nicht „Wir erlauben Komponenten“, sondern „Wir maximieren die Wiederverwendbarkeit, indem wir die Komponente genau bis zu dem Moment zurückhalten, an dem sie wirklich benötigt wird“.