Utility First, composant second

• On a souvent tendance à penser que la méthodologie utility-first, comme Tailwind CSS, consiste simplement à égrener des classes dans le HTML.

• Mais cela n'est qu'un aspect superficiel ; l'essentiel de l'approche utility-first est une question de timing pour assembler les composants.

• Les méthodes qui ont été populaires au début de CSS ont provoqué des cauchemars de maintenance.

• La tendance OOCSS essayait de résoudre le problème grâce à la composition de composants. La réutilisabilité a progressé, mais elle s'est heurtée à la difficulté de définir l'étendue des composants.

• Les composants servent à la réutilisabilité, mais il est difficile de savoir à l'avance ce qui sera réutilisé à l'avenir.

• La tendance Atomic CSS voulait régler cela en affectant une seule classe par propriété. La vitesse de développement initiale a augmenté, mais les problèmes de maintenabilité sont réapparus.

• La Source de vérité unique (Single Source of Truth) se brise trop facilement, car on dépend d'un remplacement global (la dépendance aux templates externes est fastidieuse et limitée).

• L'approche utility-first, contrairement à l'Atomic, est favorable aux composants. Et contrairement à l'OOCSS, elle part des utilitaires. Les composants peuvent alors être composés lorsque c'est réellement nécessaire.

• La question n'est plus “quels composants créer ?”, mais “quand les créer ?”.

• Autrement dit, il faut voir utility first comme une synthèse, un héritage et une évolution des deux approches.

• Par conséquent, dans la méthodologie utility-first, les composants doivent être davantage mis en avant. Au lieu de dire “nous autorisons les composants”, il faudrait dire “nous maximisons la réutilisabilité en reportant la création d'un composant jusqu'au moment où il est vraiment nécessaire”.