Je suis relativement d’accord sur la partie css-in-js, mais pas du tout sur les classes utilitaires :p.

Tachyons fait 14kb, c’est… pas lourd du tout. Si on y ajoute l’overhead des multiples classes dans les composants, on reste plus léger que du css modules par exemple. Et on doit etre vaguement identique a du css-in-js.
Je comprend qu’au premier abord les noms de classes paraissent cryptiques, mais en réalité on comprend rapidement la logique de nomage et après ca roule. Et les problèmes de priorité, dans les faits j’en ai jamais rencontré avec Tachyons. On peut aussi avoir des classes utilitaires qui utilisent les variables CSS du thème, c’est pas un problème.

Le fait d’uniformiser les valeurs n’est a mon sens pas un point mineur du tout. Si on veux la même chose dans css-in-js, on se retrouve avec des

const style = css`
padding: ${paddingSize2};
background-color: ${hotpink};
font-size: ${fontSize3};
border-radius: ${borderRadius1};
`
… et c’est pas franchement plus pratique que des classes utilitaires. Le fait de pouvoir injecter des valeurs dynamiques est limite un inconvénient pour moi. Ca va forcement élargir la palette des valeurs utilisées ce qui n’est généralement pas désirable dans une app. A mon sens ca doit rester un besoin exceptionnel, et ne pas rendre ca simple est un avantage.

Pour moi, CSS modules permet d’esquiver les problèmes de conflits que l’on a avec du CSS classique mais impose d’écrire du nouveau CSS pour chaque module. Ca fait grossir la code base, avec du CSS de qualité variable et des problèmes d’homogénéité dans les valeurs. Et en plus ca pèse lourd.
On fait globalement les mêmes compromis avec css-in-js, dans la lourdeur du css généré et avec quelques possibilités en plus.
Alors qu’avec des classes utilitaires, on sort de la logique « un bout de css par composant » et tous les problèmes que ca entraîne, et on n’a pas de problèmes de conflits parce que toutes les règles ont la même priorité. Le compromis, c’est l’apprentissage des noms de classes… pour moi ca vaux le coup :-)