Tailwind est génial. Pourtant, j'arrête de l'utiliser.

L'auteur annonce qu'il n'utilise plus Tailwind ni shadcn pour ses nouveaux projets personnels et professionnels. Il souligne immédiatement que ce choix n'est pas dû à une baisse de qualité de Tailwind, qu'il considère toujours comme une bibliothèque incroyable. Il évoque brièvement les anciens problèmes financiers de Tailwind, désormais résolus grâce à de nouveaux sponsors, pour ne pas nuire à l'image du projet. Cette section sert à clarifier son intention : partager une réflexion personnelle sur sa méthode de travail plutôt que de critiquer l'outil. Il exprime son respect pour les développeurs derrière Tailwind tout en introduisant son changement de cap.

Avant l'essor de l'IA, l'avantage majeur de Tailwind était la vitesse fulgurante d'itération sur le design directement dans le code. Travaillant souvent seul, l'auteur explique qu'il préférait se passer d'outils comme Figma pour ajuster ses styles via les classes en ligne dans le JSX. Cette approche permettait de tester instantanément des variantes de marges ou de couleurs sans changer de fichier. Tailwind répondait ainsi parfaitement au besoin de productivité pour les développeurs travaillant en solo. L'auteur reconnaît que c'est cette efficacité qui a fait le succès de l'outil auprès de la communauté.

Cette section explore pourquoi le CSS vanilla est redevenu attractif grâce aux évolutions techniques récentes comme les "container queries" et les couleurs relatives. L'auteur admet que le CSS peut être intimidant, mais précise que l'IA peut désormais écrire du code complexe à la place du développeur. En fournissant une documentation MDN à une IA, on peut obtenir des styles modernes sans avoir à mémoriser chaque propriété. Il mentionne également ses propres tutoriels sur Academind pour illustrer la puissance actuelle des navigateurs. Le CSS n'est plus le fardeau qu'il était autrefois pour ceux qui n'aiment pas l'écrire manuellement.

L'auteur explique que l'IA ne maîtrise pas toujours l'immense catalogue de classes de Tailwind et utilise souvent des syntaxes datées. Il est parfois plus simple de demander à l'IA d'utiliser une fonction CSS spécifique que de chercher la classe Tailwind correspondante. Même si Tailwind supporte les fonctions modernes, le passage par une couche d'abstraction supplémentaire peut créer des frictions inutiles lors de l'utilisation de modèles de langage. L'idée est qu'il est souvent plus direct de nommer des fonctions natives. Cette réflexion pousse l'auteur à privilégier la source originale du style : le CSS pur.

L'un des arguments principaux est la volonté de réduire le nombre de dépendances pour éviter les problèmes de maintenance à long terme. Pour un éducateur, un changement majeur dans une bibliothèque comme Tailwind peut rendre tout un cours vidéo obsolète, générant frustration et support supplémentaire. L'auteur cite l'exemple de Tiptap pour illustrer qu'il accepte les bibliothèques quand la complexité technique est trop élevée pour être gérée seul. Cependant, il estime que le styling est un domaine où l'on peut facilement se passer d'outils externes. Il préfère garder la main sur son code CSS pour garantir la pérennité de ses projets et de son contenu.

L'auteur aborde les risques de sécurité et les bugs qui persistent lorsque des bibliothèques comme Radix UI ou Tailwind cessent d'être activement maintenues. Il rappelle que Tailwind a frôlé l'abandon par le passé en raison de soucis de financement, ce qui souligne la fragilité des outils tiers. Bien qu'il continue d'utiliser Tailwind sur d'anciens projets, il encourage une réflexion critique avant d'ajouter n'importe quelle dépendance. Il conclut en suggérant que si une bibliothèque peut être remplacée par du code natif sans perte majeure de productivité, cela en vaut la peine. Son message final est un appel à la prudence et à l'évaluation systématique du rapport bénéfice/risque des outils externes.