Pourquoi je n'utilise pas Tailwind
Tailwind est partout. Dans les offres d'emploi, les tutoriels, les repos GitHub. Et pourtant je ne l'utilise pas. Voici pourquoi, sans nostalgie ni dogmatisme.
Quand Tailwind est apparu, j'ai regardé avec curiosité. L'idée de ne plus écrire de CSS dans des fichiers séparés, de tout composer directement dans le HTML via des classes utilitaires, c'est séduisant sur le papier. Rapide à démarrer, cohérent par construction, prisé par les équipes.
Mais après l'avoir utilisé sur quelques projets, j'ai arrêté. Pas par conservatisme. Par conviction.
Le HTML devient illisible
Le premier problème est visuel. Un composant Tailwind ressemble à ça :
class="flex items-center gap-4 px-6 py-3 bg-white text-gray-900 rounded-full border border-gray-200 hover:border-gray-400 transition-colors duration-200"
C'est fonctionnel. Mais c'est du bruit. Le HTML, censé décrire la structure et le sens, se retrouve envahi par des décisions visuelles atomisées. On perd la lisibilité de l'un sans vraiment gagner en lisibilité de l'autre.
Avec du CSS nommé, la même chose s'écrit class="btn_primary". Le nom porte l'intention. La règle CSS porte la forme. Chacun à sa place.
CSS natif est plus puissant qu'on ne le pense
Tailwind est né à une époque où le CSS natif était encore limité. Pas de variables custom properties, pas de clamp(), pas de :is(), pas de subgrid, pas de container queries. On bricolait.
Aujourd'hui, CSS natif est un langage mature, puissant, élégant. Les variables permettent un design system complet en quelques lignes. Les fonctions mathématiques remplacent les breakpoints rigides. Les pseudo-classes modernes simplifient des patterns qui nécessitaient auparavant du JavaScript.
Apprendre à s'en passer plutôt que de le maîtriser, c'est passer à côté de quelque chose.
La dette de configuration
Tailwind n'est pas juste des classes dans le HTML. C'est une configuration, un build step, un fichier tailwind.config.js à maintenir, des purges à gérer, des plugins à installer pour ce que le core ne couvre pas.
Pour un projet sur-mesure où je maîtrise chaque ligne de code, c'est une complexité inutile. Mon CSS est un seul fichier. Il se lit du haut en bas. Il n'a pas besoin d'être compilé. Il vit avec le projet, sans dépendances.
Une question de méthode, pas de morale
Je ne dis pas que Tailwind est mauvais. Sur une grosse équipe avec un design system codifié, des dizaines de composants à maintenir et un besoin de cohérence entre développeurs qui ont des niveaux CSS très différents, ça a du sens.
Mais dans un contexte de développement sur-mesure, où chaque site est un objet unique, où le CSS est une expression directe de l'intention visuelle, je préfère écrire le CSS moi-même. Complètement. Sans intermédiaire. C'est plus long au départ. C'est plus précis, plus léger, plus lisible à l'arrivée.
Et honnêtement, c'est aussi ce que je trouve le plus satisfaisant dans ce métier.