Deux années avec Tailwind CSS, quel bilan?

Tailwind ou pas Tailwind ? Ce framework CSS, fondé sur la méthodologie atomique, divise les rangs des intégratrices et intégrateurs. Chaque camp y trouve des arguments souvent très tranchés : on aime pas du tout ou bien on adore, il reste peu de place pour le "ça dépend".

Au sein de notre agence web Alsacréations, spécialisée dans les domaines front-end et dans l'accessibilité, nous avons expérimenté Tailwind depuis un peu plus de deux années à présent. Cet article détaille les leçons que nous avons tirées de l'usage ce framework.

Quelques précisions concernant notre contexte d'agence : nous ne sommes pas une start-up, nous intégrons des maquettes fournies par le client ou designées en interne et validées par le client. Même s'il nous arrive d'appliquer un framework pour un client (Bootstrap, Tailwind), notre expérience de plusieurs (dizaines d')années en intégration nous interdit le design de nouvelles pages "à l'arrache" comme certains pourraient être tentés de le faire avec ce genre d'outils.

Le mois de juin 2020 marque notre première intégration pour un client réalisée à l'aide de Tailwind CSS, puis une demi-douzaine de projets ont suivi. Sans oublier quelques projets personnels ou secrets.

En novembre 2020 nous publions sur Alsacréations l'article "Tailwind CSS, découverte du framework original et innovant". Quelques mois plus tard paraissent nos Guidelines Tailwind CSS publiques.

Enfin, en mai 2021, nous publions une sorte de synthèse sur la question : "Quels framework et méthodologie CSS choisir ?".

Point de départ : quelles étaient les problématiques à résoudre ?

Aucun projet d'intégration ne se déroule à la perfection, surtout dans la durée, et même au sein d'une agence web qui se considère comme compétente en la matière.

Rien que du côté CSS, les écueils que peut traverser un projet sont nombreux :

1. Séparation entre le fond (HTML) et la forme (CSS) : chacun devrait pouvoir s'occuper de son job et rester indépendant de l'autre.
2. Duplications des sélecteurs CSS (difficile de trouver, renommer, déplacer, supprimer les sélecteurs)
3. Collisions de noms (difficile de trouver des noms cohérents au fur et à mesure que le projet grossit + risque de choisir un nom déjà existant et d'écraser une partie des styles)
4. Spécificité des sélecteurs (ajouter du poids pour écraser un sélecteur a un effet "boule de neige" pour la prochaine modification à opérer)
5. Cascade (les règles de cascade CSS ne favorisent pas la compréhension ou la maintenabilité)
6. Code mort (le code inutilisé s'accumule au fur et à mesure que le projet grossit)

Notre expérience nous a souvent permis d'atténuer ces problèmes. Et quand je parle d'expérience, j'y inclus les différentes méthodologies que nous avons pu adopter chez Alsacréations : OOCSS dans un premier temps, BEM (un peu) et enfin Tailwind CSS.

Que nous apporte Tailwind CSS ?

Nous avons pu constater au cours de ces deux années d'usage que les promesses faites par Tailwind sont parfaitement tenues.

Les points suivants comptent parmi les plus retenus et cités dans notre agence :

• Résout plusieurs problématiques principales de CSS (nommage, spécificité, code mort, duplication des sélecteurs).
• Les classes utilitaires (espaces, polices, couleurs) permettent de gérer très finement les styles et leurs variations. Elles sont une bénédiction.
• L'outil s'adaptate à différents contextes (responsive, survol/focus, dark mode, etc.).
• Pourvu d'un écosystème riche (tutoriels, bibliothèques de composants, plugins navigateurs, plugins IDE : VSCode Tailwind Intellisense, etc.)
• Impose le même environnement et méthodologie pour tout le monde.

Les inconvénients de Tailwind

Sans surprise, TailwindCSS n'est pas exempt de désagréments. Voici une petite énumération que nous avons pu étabir en interne :

• Lecture du code HTML rendue fouillie et complexe (admettons-le, ça pique les yeux !)
• Nécessite une rigueur (guidelines) pour ne pas écrire n'importe quoi et dans n'importe quel ordre. Dans Tailwind, nous respectons encore plus l'ordre des propriétés
• Besoin d'un pense-bête Tailwind, parce que... items-baseline backdrop-invert-0 md:row-start-5 sm:content-around leading-snug dark:tracking-wider 🤷‍♂️
• Impossible de trouver des éléments précis dans le code (modale, wrapper, navigation, etc.).
• Inadapté pour les layouts "complexes" (gabarits, grilles non régulières, flexbox, etc.).
• Inadapté pour pas mal de fonctionnalités (transitions, animations, filtres, transformations)
• Durée de vie d'un Framework (comparé à la durée de vie de CSS ou d'une méthodologie)

Pour finir sur ce sujet, un témoignage assez évocateur :

Tailwind peut avoir un impact non négligeable sur certaines performances de chargement lorsqu'il y a de nombreuses répétitions de blocs (exemple vécu sur un projet client dont le menu généré pesait 40 Ko à cause des seules classes Tailwind)

Alors on fait quoi en pratique ?

Nous ne sommes sans doute pas les seuls dans ce cas, mais au quotidien on adapte Tailwind à notre sauce interne :

• On ajoute des noms "sémantiques" aux composants (pour pouvoir les retrouver, les désigner)
• On réserve les classes utilitaires pour un usage répétitif (marges, padding, gouttières, couleurs, typo)
• On s'équipe de plugins pour s'en sortir (ex. Tailwind Intellisense)
• On a toujours un onglet de navigateur ouvert avec la Doc de Tailwind ou un pense-bête tel que celui de Flowbyte ou Umeshmk

Nous sommes parfaitement conscients que nous n'employons pas ce framework "comme il faudrait" mais plutôt d'une façon hybride, cumulée avec d'autres méthodologies dans lesquelles nous piochons des idées à appliquer.

Vers l'après-Tailwind ?

Nous nous trouvons actuellement dans une phase de transition où l'on s'est remis à tester de nouvelles méthodologies et approches.

En toute transparence, Tailwind CSS ne nous convient pas à 100%. Ou plutôt, cela dépend des types de projets : sur certains projets, il nous paraît naturel de l'employer tandis que sur d'autres typologies il devient contre-productif.

Il est tout à fait probable qu'aucune méthodologie ne nous convienne parfaitement pour l'ensemble de nos prestations d'intégration et seul l'avenir nous le dira.

En attendant, un nouveau challenger est entré en jeu et nous commençons à le tester en production : Cube CSS.

CubeCSS n'est pas un framework mais une méthodologie plus générale. Pour le moment, nous la trouvons très prometteuse, mais laissez-nous le temps de l'expérimenter et… de vous partager nos conclusions dans un prochain article !