Il y a deux ans, j'aurais défendu Bootstrap jusqu'au bout. Je connaissais toutes les classes par cœur — col-md-6, d-flex align-items-center, btn btn-primary. C'était confortable. Et puis j'ai essayé Tailwind CSS sur un side project, "juste pour voir". Deux semaines plus tard, je supprimais Bootstrap de tous mes projets en cours.
Voici ce qui m'a convaincu — et les quelques raisons de ne pas choisir Tailwind.
Le problème fondamental avec Bootstrap
Bootstrap est un framework de composants. Il vous donne des boutons, des navbars, des cards — avec un style précis, difficile à personnaliser sans surcharger le CSS. Vous commencez avec leur design et vous essayez de le plier vers le vôtre.
Résultat : deux problèmes classiques.
- Les sites Bootstrap se ressemblent tous. Les utilisateurs reconnaissent instantanément un site Bootstrap. Ce n'est pas nécessairement mauvais, mais c'est une contrainte pour les projets avec une forte identité visuelle.
- La spécificité CSS devient un cauchemar. Vous finissez par écrire
!importantpartout pour écraser les styles Bootstrap.
L'approche utility-first de Tailwind : un changement de paradigme
Tailwind ne vous donne pas de composants — il vous donne des utilitaires. Des classes qui font une chose précise. Et vous composez votre design directement dans l'HTML.
<!-- ❌ Bootstrap : dépendant du style imposé -->
<button class="btn btn-primary btn-lg">
Créer un compte
</button>
<!-- ✅ Tailwind : vous contrôlez tout -->
<button class="bg-blue-600 hover:bg-blue-700 text-white font-semibold
px-6 py-3 rounded-lg transition-colors duration-200
focus:outline-none focus:ring-2 focus:ring-blue-500">
Créer un compte
</button>
Oui, le code HTML est plus verbeux. Mais vous n'avez pas à quitter le fichier HTML pour modifier le style. Et deux designs différents restent deux codes différents — pas deux ensembles de surcharges CSS.
La taille du bundle : le mythe de Tailwind qui "est lourd"
On entend souvent que Tailwind génère des fichiers CSS énormes. C'était vrai avant la version 3. Aujourd'hui, Tailwind utilise un JIT compiler (Just-In-Time) qui ne génère que les classes que vous utilisez réellement.
// tailwind.config.js — configuration du purge (v3)
module.exports = {
content: [
'./resources/**/*.blade.php',
'./resources/**/*.js',
'./resources/**/*.vue',
],
// ...
}
Résultat : un CSS final de 5 à 15 Ko (gzippé) sur la plupart des projets. Bootstrap, lui, fait entre 20 et 30 Ko minifié et gzippé — et vous embarquez des centaines de composants que vous n'utilisez pas.
La productivité : ce que je n'attendais pas
Ce qui m'a vraiment surpris, c'est la vitesse. Avec Bootstrap, je passais du temps à chercher si la classe existait, à vérifier si elle fonctionnait dans ce contexte, à écrire du CSS custom quand elle ne suffisait pas. Avec Tailwind, tout est dans l'HTML. Le responsive est trivial :
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
<!-- 1 colonne mobile, 2 tablette, 3 desktop -->
</div>
Les états (hover, focus, active, dark mode) sont tous gérés avec des préfixes intuitifs :
<button class="bg-slate-800 hover:bg-slate-700 dark:bg-white dark:hover:bg-slate-100
dark:text-slate-900 text-white ...">
</button>
Quand NE PAS choisir Tailwind
Je ne vais pas prétendre que Tailwind est parfait pour tous les contextes :
- Prototypage ultra-rapide → Bootstrap ou DaisyUI (qui se base sur Tailwind mais ajoute des composants) sont plus rapides pour les MVPs.
- Équipes sans designer → Le design system de Bootstrap vous guide. Tailwind, sans design, produit des interfaces incohérentes.
- Contenu généré dynamiquement → Les classes Tailwind dans du contenu généré en base de données ne seront pas incluses dans le bundle (si vous utilisez le JIT).
Mes ressources pour démarrer avec Tailwind
- tailwindui.com — des composants premium excellents (payants)
- daisyui.com — des composants gratuits construits sur Tailwind
- Flowbite — composants open-source
- La doc officielle — la meilleure documentation CSS que j'aie jamais vue
Conclusion
Tailwind CSS n'est pas meilleur que Bootstrap dans l'absolu. Il est meilleur pour moi, dans mon workflow, sur mes projets — parce qu'il correspond à ma façon de travailler : penser design => implémenter directement, sans couche d'abstraction.
Si vous ne l'avez jamais essayé, lancez-vous sur votre prochain side project. Pas sur un projet client, pas en production directe — sur quelque chose de suffisamment petit pour explorer sans pression. Vous verrez.