Quand on apprend le CSS, on commence généralement par écrire des règles dans un fichier séparé, organisées par composant ou par page. Puis on découvre BEM, puis les préprocesseurs comme Sass, puis les frameworks. Et quelque part dans ce parcours, on se retrouve face à deux philosophies radicalement différentes.
L'Atomic CSS, popularisé par Tailwind, repose sur une idée simple : chaque classe CSS ne fait qu'une seule chose. flex, text-center, p-4, rounded-lg, autant de classes atomiques qu'on combine directement dans le HTML. Le CSS global reste minimal et stable ; c'est l'HTML qui porte l'information de style.
L'approche composants, elle, regroupe les styles par entité visuelle. Un bouton a ses propres règles, une card a les siennes. C'est la logique de BEM, de CSS Modules, et de la plupart des bibliothèques UI comme MUI ou ShadCN. Le HTML reste propre, le CSS est organisé sémantiquement.
En pratique, j'ai expérimenté les deux. Tailwind m'offre une vélocité importante une fois les classes mémorisées, et il évite la prolifération de noms de classes inventés à la va-vite. Mais sur des projets plus complexes, je commence à percevoir la limite : le HTML devient très verbeux, et retrouver la logique d'un composant au milieu de vingt classes utilitaires demande de la rigueur.
L'approche composants, à l'inverse, produit un HTML plus lisible et une architecture plus claire sur le long terme. Mais elle demande plus de décisions dès le départ, et peut vite devenir rigide si le design évolue.
Ma conclusion provisoire, parce qu'en fin de 2ème année, je ne prétends pas avoir tout tranché, c'est que le choix dépend du contexte. Un projet solo ou un prototype rapide : Tailwind. Une application métier maintenue en équipe sur du long terme : une approche composants mieux structurée. Et souvent, les deux coexistent dans le même projet.