Tailwind CSS : limites des systèmes de design pour les développeurs

Pourquoi Tailwind CSS limite les systèmes de design évolutifs : analyse des approches

Tailwind CSS accélère le prototypage, mais son approche utility-first crée des maux de tête à l'échelle. Dans les systèmes de design, les composants comme les boutons nécessitent des combinaisons de variantes, tailles et états. Ajouter une nouvelle variation comme btn-focus doit s'intégrer parfaitement avec btn-sm, btn-lg, btn-outline. Les états comme le survol (15 % plus foncé) ou l'état actif (10 % plus clair) doivent s'appliquer de manière cohérente partout. Les frameworks traditionnels gèrent cela avec des mixins, comme :

.button-variant-other(@color; @background; @border);

Tailwind manque d'outils intégrés pour ce type d'intégration fluide sans compromis.

CVA : Rapide mais limité

Shadcn utilise CVA pour les boutons avec des variantes et tailles fixes :

variant "default" | "outline" | "ghost" | "destructive" | "secondary" | "link"
size "default" | "xs" | "sm" | "lg" | "icon" | "icon-xs" | "icon-sm" | "icon-lg"

Avantages :

• Développement rapide sans naviguer entre fichiers.
• API claire pour les cas d'usage basiques.

Les inconvénients apparaissent dans les projets à long terme :

• Impossible de créer primary outlined small sans bidouilles.
• Les combinaisons fixes accumulent une dette technique après 6+ mois.

Parfait pour les apps simples, mais en développement d'entreprise, cela fait grimper les coûts.

Variables CSS : La solution flexible

Les variables CSS séparent la logique d'état des variantes :

.btn {
  @apply inline-flex items-center justify-center rounded px-4 py-2 font-body;
  background-color: var(--btn-color);
  color: var(--btn-text, white);
}

.btn:hover {
  background-color: color-mix(in srgb, var(--btn-color), black 15%);
}

.btn:active {
  filter: brightness(1.1);
}

.btn-primary {
  --btn-color: theme('colors.blue.600');
}
.btn-whatever {
  --btn-color: …;
}

Avantages clés :

• États automatiques pour n'importe quelle couleur.
• Ajout facile de variantes via variables.
• Compatible avec n'importe quelle bibliothèque UI.

Inconvénient pour les fans de Tailwind : perte de vitesse car les styles migrent vers des fichiers séparés.

Directive @utility : Un hack utilitaire

La directive génère dynamiquement des classes :

@utility btn-* {
  font-size: --value(--text-ui-*, [length]);
  background-color: --value(--color-ui-*, [color]);
  color: --value(--color-ui-*-text, [color]);
}

Cela s'associe aux modificateurs Tailwind pour le survol ou le responsive. Mais :

• btn-focus ne s'adapte pas à sm ou lg — les classes fonctionnelles sont limitées.
• Construire primary small outline nécessite des ajustements fragiles du composant.
• S'effondre avec des combinaisons complexes.

Comparaison des approches

| Approche | Vitesse | Évolutivité | Intégration États | Dépendance Tailwind |

|--------------|---------|-------------|-------------------|---------------------|

| CVA | Élevée | Faible | Limitée | Totale |

| Variables CSS| Moyenne | Élevée | Complète | Faible |

| @utility | Moyenne | Moyenne | Partielle | Élevée |

CVA brille pour les MVP, les variables CSS pour la production, @utility comme compromis.

Points clés

• Tailwind n'impose pas de structure : L'approche utility-first exige un système maison.
• Composants comme classes : Verrouille les systèmes de design complexes dans des options rigides.
• Alerte dette technique : Simplicité initiale signifie refactorisation dans six mois.
• Alternatives performantes : Les variables CSS offrent flexibilité sans abandonner Tailwind.

Tailwind excelle pour les démarrages rapides, mais les systèmes de design matures nécessitent des configurations hybrides ou un assouplissement des utilities.

— Editorial Team