Brent Jackson sagt, dass CSS-Utility-Bibliotheken teilweise versagt haben
Irgendwann müssen Sie einmalige Stile hinzufügen, die von der verwendeten Bibliothek einfach nicht abgedeckt werden, und es gibt nicht immer einen klaren Weg, das zu erweitern, womit Sie gerade arbeiten. Ohne einen klaren Weg, solche Dinge zu handhaben, fügen Entwickler dazu neigen, inkonsistente Hacks und nur angehängte Stile hinzuzufügen.
Ich habe das Gefühl, die Tailwind-Leute würden widersprechen. Ich habe hier keine bestimmte Meinung, ich stelle nur fest, dass Tailwind eine glühendere Fangemeinde zu haben scheint als in den frühen Tagen von Basscss/Tachyons.
Brent sagt weiter, dass CSS-in-JS dasselbe Problem löst, aber auf bessere Weise
CSS-in-JS-Bibliotheken helfen dabei, viele der gleichen Probleme zu lösen, auf die sich Utility-basierte CSS-Methoden (und mehr) konzentrierten, und zwar auf eine viel bessere Weise. Sie verbinden Stile direkt mit Elementen, ohne dass Namen vergeben oder Abstraktionen in Klassenselektoren erstellt werden müssen. Sie vermeiden nur angehängte Stylesheets mit Kapselung und gehashten Klassennamen. Diese Bibliotheken funktionieren mit bestehenden Build-Tools und ermöglichen Code-Splitting, Lazy Loading und Dead-Code-Eliminierung mit praktisch null Aufwand, und sie erfordern keine zusätzlichen Tools wie Sass oder PostCSS. Viele Bibliotheken enthalten auch CSS-Performance-Optimierungen, wie z. B. Critical CSS, die standardmäßig aktiviert sind, sodass Entwickler keine zusätzlichen Tools benötigen oder nicht einmal darüber nachdenken müssen.
Kein Wunder, dass die Leute davon schwärmen.
Der Rückschritt bezieht sich auf die Tatsache, dass CSS-in-JS offener ist und nicht so sehr auf Konsistenz setzt. Da bin ich mir nicht sicher. Es scheint, als ob, wenn Sie bereits komponentenbasiert entwickeln, die Konsistenz irgendwie mitkommt, noch bevor Sie Design-Tokens und dergleichen verwenden – was ein CSS-in-JS-Ansatz ebenfalls fördert.