Pourquoi j'ai abandonné les frameworks CSS pour Tailwind — et ce qui a changé
Après des années à lutter contre les guerres de spécificité et les kiloctets inutilisés, voici ce qui m'a finalement convaincu de faire le changement — et l'impact mesurable sur mon workflow et les performances de mes clients.
Le problème des frameworks CSS traditionnels
J'ai passé trois ans à construire des projets avec Bootstrap et Bulma. Ce sont d'excellents frameworks — je ne prétendrai pas le contraire. Mais plus je les utilisais, plus je me retrouvais à lutter contre le système plutôt qu'à travailler avec lui.
Chaque nouveau projet commençait de la même manière : importer le framework, immédiatement surcharger la moitié, écrire une montagne de CSS personnalisé pour annuler les valeurs par défaut, puis passer 40 % du temps de développement à déboguer les problèmes de spécificité. Le bundle CSS final faisait généralement 80 à 120 ko, dont seulement 15 % environ était réellement utilisé.
"Le moment où vous commencez à écrire
!importantpour remplacer les valeurs par défaut d'un framework, quelque chose a fondamentalement mal tourné."
Ce qui m'a fait donner une vraie chance à Tailwind
J'ai longtemps rejeté Tailwind. L'approche par classes utilitaires semblait désordonnée dans le HTML, et j'étais convaincu qu'elle rendrait les modèles illisibles. Puis un client m'a demandé de maintenir un projet Tailwind existant, et je n'avais pas le choix.
Deux semaines plus tard, j'étais converti. Voici ce qui a changé mon avis :
- Pas de changement de contexte. J'ai arrêté de passer constamment entre les fichiers HTML et CSS. Tout est dans le balisage.
- Zéro guerre de spécificité. Les classes utilitaires sont toutes des sélecteurs à un seul niveau. Vous ne luttez jamais contre la cascade.
- Bundles finaux minuscules. PurgeCSS (maintenant intégré) signifie que les builds de production font typiquement 5 à 15 ko. Ma moyenne est passée de 110 ko à 8 ko.
- Le design system, c'est la config. Espacement, couleurs, typographie — tout est centralisé dans
tailwind.config.js.
L'impact sur les performances réelles
J'ai reconstruit le site marketing d'un client avec Tailwind CSS + Alpine.js, en remplacement de leur stack WordPress + Bootstrap 4. Les résultats après un mois étaient indéniables :
- Score de performance Lighthouse : 47 → 96
- Bundle CSS : 118 ko → 7 ko
- Temps jusqu'au premier affichage de contenu : 3,8 s → 0,9 s
- Taux de rebond : -22 %
Ce qui me manque encore des frameworks traditionnels
Tout n'est pas parfait. Quelques éléments pour lesquels j'utilise encore des plugins ou des composants personnalisés :
- Composants complexes préconstruits comme les modales, les menus déroulants et les sélecteurs de date
- Stylisation de validation de formulaire (même si Alpine.js gère bien la partie logique)
- Systèmes de grille opinionés — la grille de Tailwind est puissante mais verbeuse pour des mises en page complexes
L'écosystème a largement rattrapé son retard. Headless UI, Flowbite et Preline couvrent la plupart des lacunes. Et Alpine.js gère la couche d'interactivité magnifiquement sans ajouter de poids.
Ma recommandation
Si vous construisez quelque chose de personnalisé — un produit SaaS, un portfolio, une landing page — Tailwind est le bon outil. La courbe d'apprentissage initiale est d'environ une semaine. Après cela, vous livrerez plus rapidement que jamais.
Si vous avez besoin d'un thème WordPress ou d'un site brochure simple avec un style personnalisé minimal, Bootstrap reste parfaitement adapté. Utilisez le bon outil pour le travail.
Si cela vous a été utile, partagez-le avec un développeur qui utilise encore Bootstrap 4.