Pourquoi les "frameworks CSS" modernes encouragent-ils à écrire du code à vomir ?

Un petit topic ouvert par frustration, mais avec une vraie question. On vient de me refiler un site web fait avec TailwindCSS, il paraît que c’est le futur trop bien et… le code HTML est horrible, plein de noms de classes imbitables copiés-collés d’une ligne à l’autre, et c’est atroce à modifier pour ajouter du contenu.

Ce n’est pas un problème avec les personnes qui ont fait le site, puisque la documentation de ce framework CSS (TailwindCSS) propose exactement de faire ça, comme si c’était une bonne pratique: Utility First:

Using utility classes to build custom designs without writing CSS

<div class="max-w-sm mx-auto flex p-6 bg-white rounded-lg shadow-xl">
  <div class="flex-shrink-0">
    <img class="h-12 w-12" src="/img/logo.svg" alt="ChitChat Logo">
  </div>
  <div class="ml-6 pt-1">
    <h4 class="text-xl text-gray-900 leading-tight">ChitChat</h4>
    <p class="text-base text-gray-600 leading-normal">You have a new message!</p>
  </div>
</div>

Ensuite la doc utilise deux pages complètes pour dire que oui, c’est à vomir, mais en fait c’est trop bien, ça a l’air horrible mais c’est super génial. On se retrouve avec des noms de classe copiés-collés partout ? Les auteurs du framework ont la réponse: Extracting Components.

<!-- In use -->
<VacationCard
  img="/img/cancun.jpg"
  imgAlt="Beach in Cancun"
  eyebrow="Private Villa"
  title="Relaxing All-Inclusive Resort in Cancun"
  pricing="$299 USD per night"
  url="/vacations/cancun"
/>

<!-- ./components/VacationCard.vue -->
<template>
  <div>
    <img class="rounded" :src="img" :alt="imgAlt">
    <div class="mt-2">
      <div>
        <div class="text-xs text-gray-600 uppercase font-bold">{{ eyebrow }}</div>
        <div class="font-bold text-gray-700 leading-snug">
          <a :href="url" class="hover:underline">{{ title }}</a>
        </div>
        <div class="mt-2 text-sm text-gray-600">{{ pricing }}</div>
      </div>
    </div>
  </div>
</template>

Donc en fait le conseil c’est d’arrêter d’utiliser du CSS (à part comme langage pour que chacun définisse son jeu de balises de bases préférée, un peu différent du voisin), de hardcoder tout dans le style, et d’utiliser un moteur de template pour toutes les parties de son site web.

Et je ne pense pas que ce soit spécifique à TailwindCSS. J’ai utilisé Bootstrap récemment et c’est pareil, le résultat est tout aussi pourri.

On dirait qu’il y a un truc bizarre où les leçons du "HTML d’avant" (séparer le contenu et le style, etc.) ont été complètement oubliées, et qu’on essaie de se convaincre tous, collectivement, que tout mettre dans le HTML c’est trop génial.

Est-ce qu’il y a des gens ici qui y comprennent quelque chose et qui peuvent expliquer cette atmosphère de folie collective dans les frameworks CSS/HTML ?

L’idée d’un framework CSS ne serait-elle pas justement de ne pas avoir à faire de CSS ? Et de gagner énormément de temps en te préparant un jeu de style entier que tu n’auras pas à faire toi. Comme ca, ton back te génère tes pages cale les bonnes balises et le style est déjà prêt.

Finalement, quand tu crées toi des classes ".menu" ou autre "topnav" tu reviens exactement au même, sauf que la sémantique c’est toi qui l’a définies et tu y es familier

Est-ce que ça ne vient pas simplement du fait qu’il est impossible en CSS d’« hériter » de classes existantes pour en faire une nouvelle¹ ?

On a donc toutes les classes de style qui se retrouvent appliquées directement aux éléments HTML, plutôt que leur appliquer des noms de classes simples qui eux iraient piocher des propriétés dans d’autres classes existantes.

Je rejoins grandement le fond du propos : les frameworks CSS font un peu n’importe quoi. Mais il faut surtout comprendre pourquoi ils existent à la base : pour permettre à des gens qui ne maîtrisent pas le CSS de faire de mettre en place leurs pages et apps Web sans avoir à trop bricoler les styles à la main.

Bootstrap a un peu lancé la vague en proposant un outil qui permet de créer une interface complète sans avoir à toucher une seule ligne de CSS, juste en utilisant le bon HTML, c’est très fort !

Le problème c’est que l’idée de base était surtout de servir à accélérer le développement de prototypes, pas forcément d’être utilisé en prod, encore moins en l’état.

La plupart des frameworks utilisent d’ailleurs un préprocesseur (SASS, Less…) pour ça : les class mises à disposition sont faites pour être réutilisées dans nos propres class en production. Ainsi au lieu d’avoir ce HTML bizarre on aurait plutôt du SCSS qui ressemble à ça :

.btn {
  @extend .font-bold;
  @extend .rounded;
  
  &:hover {
    @extend .underline;
  }
}

Ce qui a l’avantage d’être un (pseudo-)CSS facile à lire et comprendre, au moins si les class utilisées sont explicites.

Il faut se rendre compte que dans beaucoup de gros projets Web ce sont des développeurs back qui se retrouvent à faire du front. Ils ne sont pas forcément à l’aise en CSS et toutes ces subtilités (quiconque a tenté d’intégrer un multi-colonne de hauteurs égales avec des float comprendra la douleur), mais savent lire une doc qui leur dit comment avoir un bouton, comment le rendre plus gros ou changer sa couleur de fond.

Ben je ne trouve pas que ce soit une amélioration d’avoir

<div class="max-w-sm mx-auto flex p-6 bg-white rounded-lg shadow-xl">
  <div class="flex-shrink-0">
    <img class="h-12 w-12" src="/img/logo.svg" alt="ChitChat Logo">
  </div>
  <div class="ml-6 pt-1">
    <h4 class="text-xl text-gray-900 leading-tight">ChitChat</h4>
    <p class="text-base text-gray-600 leading-normal">You have a new message!</p>
  </div>
</div>

<div class="max-w-sm mx-auto flex p-6 bg-white rounded-lg shadow-xl">
  <div class="flex-shrink-0">
    <img class="h-12 w-12" src="/img/logo.svg" alt="ChitChat Logo">
  </div>
  <div class="ml-6 pt-1">
    <h4 class="text-xl text-gray-900 leading-tight">ChitChat</h4>
    <p class="text-base text-gray-600 leading-normal">You have another new message!</p>
  </div>
</div>

au lieu de

<div class="notif">
  <div class="notif-image">
    <img src="/img/logo.svg" alt="ChitChat Logo">
  </div>
  <div class="notif-message">
    <h4>ChitChat</h4>
    <p>You have a new message!</p>
  </div>
</div>

<div class="notif">
  <div class="notif-image">
    <img src="/img/logo.svg" alt="ChitChat Logo">
  </div>
  <div class="notif-message">
    <h4>ChitChat</h4>
    <p>You have another new message!</p>
  </div>
</div>

Il est possible d’avoir ce second style au-dessus d’un framework CSS (et c’est facilité par les outils de préprocessing comme less/sass qui proposent des mixins pour définir facilement des classes par héritage), mais ça demande bien sûr d’écrire du CSS. Ce qui est surprenant (pour moi) c’est que les auteurs de ces frameworks déconseillent de faire ça !

L’idée d’un framework CSS ne serait-elle pas justement de ne pas avoir à faire de CSS ?

Ben quand j’utilise un framework Javascript, c’est toujours pour écrire du Javascript (mais mieux, avec plein de fonctionnalités de base déjà gérées pour moi, etc.).

À ma connaissance la spécification de CSS ne permet toujours pas cela facilement (c’est en discussion depuis un moment), mais en pratique tout le monde utilise des préprocesseurs qui prennent en entrée une extension du CSS, et qui compilent vers un CSS minifié, et donc tu as des mixins, de l’héritage, des noms de variables, possibilité de faire des calculs arithmétiques… la folie quoi.

Je pense que c’est parce que ça permet de gérer « simplement » des mises en formes complexes et responsives… tant que tu restes exactement dans les clous du framework, dans le sens où tu peux avoir un rendu homogène et propre sur pratiquement tous les navigateurs sans te battre avec le CSS – ce qui peut être très long et très pénible. Cela dit, TailwindCSS a l’air de pousser le concept beaucoup trop loin de mon point de vue, et les exemples d’utilisation me font penser au vieux HTML ou on avait directement les attributs comme font="" ou color="" dans les balises HTML.

Pour moi un bon framework devrait surtout proposer des classes sémantiques, pour compléter la sémantique HTML ; notamment pour gérer les histoires de grilles, de menu principal et d’éléments responsives.

Mais même avec cette explication, tous les frameworks ne se valent pas. Par exemple sur mon site de textes, je suis passé de Bootstrap 4 qui t’impose une soupe imbitable de <div> avec des tonnes de classes, à Materialize CSS qui peut très bien s’utiliser comme une série d’annotations plus ou moins sémantiques sur une structure HTML propre (même s’il propose des classes de pure mise en forme, comme des classes de couleur). Mais hélas son développement semble interrompu…

L’exemple tiré de TailwindCSS que donne @gasche me semble être l’une des pires utilisations des composants Vue que l’on puisse faire

À vomir. Un peu agressif comme approche. Disons que ça ne te plaît pas parce que tu ne connais pas.

Mais les frameworks CSS ont du sens, sinon on ne les utiliserait pas ! Tu parles des temps anciens, je comprends facilement à quoi tu fais hallusion, j’suis un vieux aussi. Cependant tu n’as pas dû essayer de faire un site responsive mobile first complet from scratch depuis un moment parce que… Bah c’est juste l’enfer sans framework CSS. L’impression de réécrire la terre entière. Et alors si tu dois en faire un second oulala, tu vas copier/coller crois moi !

Alors oui, on fait des frameworks CSS et on a du code un peu compliqué avec plein de classes. Mais ce qu’il faut voir ce n’est pas ce qu’on perds à faire ça, mais ce qu’on y gagne.

Après chacun ses goûts. J’aime pas trop tailwind par exemple parce que je trouve qu’il n’en fait pas assez malgré la nécessité d’avoir tout-comme-bootstrap au final.

Pas tout à fait correct. Bootstrap est distribué en scss et du coup une version complètement customisable qui ne t’interdit pas de faire du CSS. C’est plutôt pour t’éviter d’avoir trop à en faire. Mais on peut imaginer ne pas coder du tout de css non plus, ça fonctionne.

Et enfin, pour parler des composants, ma foi, c’est une feature de HTML qui existe pour une raison et c’est plutôt cools qu’ils proposent de l’utiliser.

Pour finir je dirais que si tu n’aimes pas, n’utilise pas, je te souhaîte bon courage pour gérer ton responsive etc, mais surtout, fait ce que tu veux et ne dit pas "c’est de la merde" stp: plein de gens trouvent ça cool. 👍

Non justement : c’est une feature de frameworks JS . Ils partent du principe que tu utilise un framework JS pour ton front, ce qui n’est pas toujours le cas (tu peux avoir un site statique comme le mien, ou tout simplement des pages générées par le serveur « à l’ancienne »).

Tailwind le déconseille mais explique pourquoi. Les raisons sont discutables quand on a l’habitude de faire du CSS soi-même, c’est certain.

Mais pour un développeur qui ne maîtrise pas assez et veut juste profiter de l’outil simplement c’est parfait pour appliquer des styles sans risquer d’effets de bord, surtout quand il s’agit d’un projet qui risque d’évoluer beaucoup, de faire rentrer plusieurs développeurs avec différents niveau de maitrise…

Les sites simples d’il y a 10 ans commencent à se faire rare, beaucoup d’entreprises maintenant passent à de grosses applis Web partout, avec un framework JavaScript (qui ne sera d’ailleurs pas forcément en JS pur, cf. React et Angular) et une couche d’abstraction technique énorme qui permet à n’importe quel développeur de faire du Web sans trop chercher à comprendre le DOM, le flow, le principe de repaint, etc.

@Nek j’ai pas trop exploré, mais Tailwind UI ne serait pas un équivalent Bootstrap ?

Je comprends bien que chaque framework définit ses propres abstractions de layout, qui sont derrière implémentées avec plein de CSS horrible et compliqué qu’on ne veut pas écrire à la main. Ok.

Mais ça n’explique pas pourquoi la façon documentée d’utiliser ces composants de base, c’est de les mettre les uns à la suite des autres dans l’attribut class de ses éléments HTML, comme si c’était le style="..." des années 2000.

On devrait pouvoir faire des sites responsives, avec des grilles de la mort et des widgets trop bien et des animations de malade, (en utilisant les supers hacks CSS développés par des experts de chez Twitter/whatever et packagés comme des mixins de base) et avec une séparation entre le contenu et la présentation, un minimum de sémantique dans le code HTML qu’on écrit au final, et pas du copié/collé partout.

(Et si on veut rajouter une couche de templates venant d’un framework HTML derrière, ça peut être une bonne idée, mais on peut tout aussi bien le faire à partir d’un code propre, au lieu d’encourager les gens à écrire du code dégueu et espérer s’en sortir avec des templates partout.)

Qu’est-ce qui prend les gens d’essayer d’expliquer sérieusement que cette approche est une bonne idée ?

(Pour moi ce n’est pas une approche d’"ingénieur backend qui ne connaît pas le CSS", comme le propose @viki53. Ça ressemble plutôt à ce que feraient des gens qui (1) ne savent pas coder proprement, (2) sont bien payés pour produire des pages webs jetables, et (3) ne se préoccupent pas trop de faire n’importe quoi.)

Disons que ça ne te plaît pas parce que tu ne connais pas. […] plein de gens trouvent ça cool.

Avec ce genre d’arguments on peut justifier n’importe quelle erreur magistrale de conception. Il suffit que plein de gens fassent la même erreur, et ça devient automatiquement une bonne idée ?

Je ne sais pas si ce genre de framework, même ceux abusifs comme Boostrap ou TailwindCSS sont « une erreur magistrale de conception ». Ils le sont dans un monde idéal où toute personne qui veut faire un programme s’attache à faire un code propre et bien conçu.

Mais ça n’est pas le but de ces frameworks. Pour moi ils sont là pour résoudre deux problématiques, l’une assez légitime, et l’autre plus douteuse dans son éthique et son impact sociétal au sens large. Ces frameworks permettent de faire :

1. des prototypes, comme dit plus haut ; et
2. des projets jetables, faits très vite par des gens dont ça n’est pas le métier de faire du front, et pour lesquels la seule métrique retenue au-delà du cout (le moins cher possible) est que ça doit s’afficher comme prévu par les designers. Les notions de maintenabilité ou de performance sont complètement ignorées dans ce genre de projet.

En ce sens, ces frameworks répondent plutôt bien au besoin, et effectivement leur adoption massive prouve qu’ils ont une utilité prouvée dans le monde réel. Leur utilisation ne me parait pas problématique tant qu’on reste dans l’un des deux cas sus-cités, ou dans le cas d’une personne qui fait son site dans son coin pour s’amuser (donc là aussi sans contrainte réelle de cout, de performances ou de maintenabilité, mais avec une forte contrainte de résultat fiable à moindre effort).

Pour moi ça devient plus problématique quand ces frameworks deviennent utilisés pour des projets où la maintenance ou les performances (en particulier côté client) deviennent importants, parce que là effectivement ils deviennent plus un handicap qu’une aide.

PS : Mais oui, ces frameworks posent exactement les mêmes problèmes que les batteries de style="…" ou même les attributs précédents des années 2000. Et en fait, ils sont tout à fait aussi (il)légitimes, selon le projet (cf les cas ci-dessus), avec l’avantage d’être plus fiables et plus simples, et l’inconvénient d’être plus lourds.

PPS :

(2) sont bien payés pour produire des pages webs jetables

Tu serais surpris de l’argent que peuvent mettre des clients dans des projets explicitement jetables. Notamment tout un tas d’opérations marketing qui sont par nature limitées dans le temps et qui rapportent gros.

J’ai l’impression que dans le monde des frameworks CSS, il y a deux approches qui coexistent.

• Celle d’avoir un framework CSS orienté composants, où l’on créé des composants abrités sous une classe CSS, et où on les utilise en HTML. C’est le cas de Bulma, par exemple, qui propose toute une série de composants et d’éléments prêts à l’emploi mais (quasiment) pas de classes comme le fait Tailwind.
• Celle d’avoir un framework CSS orienté normes, où l’on met par exemple plein de classes CSS qui imposent une palette, des longueurs discrètes à utiliser, etc. : on est plus dans le style de Tailwind, mais d’autres framework (dont Bulma) permettent aussi d’imposer une norme ; simplement, c’est fait autrement, en définissant une norme qui est derrière utilisée dans les composants.

Avoir une norme dans ses styles, c’est une bonne chose. Ça permet de garantir une certaine identité aux sites, une cohérence : le rendu n’en est que plus fini, plus propre. D’ailleurs, sur ZdS, je travaille à ce qu’on en ait une.

Le problème de Tailwind, à mon sens, c’est qu’ils ne proposent que ça, sans aucune autre structuration, et j’avoue que je n’adhère pas du tout. Mais le fond n’est pas pour autant à jeter : c’est juste une autre façon de gérer l’apparence de son site web.

Je ne comprends pas trop pourquoi tout le monde encense autant TailwindCSS, parce que je rejoins mes voisins du dessus sur le fait que c’est pas forcément une bonne chose de mettre le CSS comme attributs HTML (la question de « quelle différence avec style="…" ? » — à laquelle je réponds « c’est un style normé »). Surtout que ça implique de réapprendre toute une nomenclature à base de classes, quand on a déjà tout un langage conçu pour faire des styles (indice : le CSS).

Je préfère largement l’approche que j’utilise pour ZdS (comme par hasard), ou que Bulma utilise : normer les styles via des variables (CSS ou SASS, peut importe), et les utiliser dans le CSS. Mais, le fond fait sens.

Aussi, sur la généralisation — je trouve l’approche de Tailwind très discutable, comme précisé plus haut, mais tous les frameworks ne sont pas comme lui non plus, il ne faut pas exagérer. J’ai mentionné Bulma, mais c’est aussi il me semble, le cas de Bootstrap (sauf si je ne suis vraiment pas à jour), qui est (était ?) orienté composants et non classes utilitaires.

Bootstrap est plutôt orienté composants, mais t’oblige à générer des tas de <div> avec des classes spécifiques pour que ça fonctionne.

Pour les utilisateurs de framework JS côté client, il y a des frameworks de composants JS (exemple) qui me semblent bien plus adaptés pour faire une vraie application : OK le code généré est probablement aussi horrible, mais au moins c’est à 100 % le problème du framework, le développeur n’a pas à créer ou modifier du HTML imbitable.

Dans le même esprit mais avec Bulma (qui a une structure HTML assez simple, c’est pour moi un de ses avantages), il y a Buefy. Il y a de ce genre de choses pour pas mal de frameworks CSS j’ai l’impression.

Et au passage tant que je le revois : non, les composants c’est aussi une fonctionnalité native maintenant. D’ailleurs un tuto sur ce sujet sera prochainement dispo sur ZdS…

ca fait quelque temps deja que j’utilise bootstrap quand je dois faire un resultat rapide, et visuel, mais je pense de plus en plus pour materielize

sinon si vous voulez le minimum syndical il existe knacss ca permet d’avoir un truc simple fonctionnel par contre ya pas tout le sucre que tu pourrais trouver pour te faire un modal, ou je ne sais quoi ça permet d’avoir une base legere, et efficace

Salut

Je me suis retrouvé a gérer par hasard une codebase qui utilise Tailwind pour le front depuis plusieurs mois (je ne connaissais pas avant ça). On a pas de framework JS donc on ne peut pas utiliser les composants qui serait fournit avec un framework. On rend tout en utilisant les templates Django, donc on extraits certaines choses qui reviennent souvent dans un template à part (comme on le fait souvent en Django peu importe le framework CSS). Bein franchement après plus de 6 mois d’utilisation je ne retrouve pas grand chose à dire.

Pour moi les avantages:

• Quand tu change quelque chose a un endroit tu es sur que ça n’impacte que cet endroit (un peu comme à l’époque des style= en effet). Pour moi ne pas avoir à se demander si ça pète ailleurs est un avantage.
• Les diff sont assez simple à lire, si quelqu’un a changé un style sur un template ça se voit assez facilement
• C’est prenable en main très facilement par quelqu’un qui connaît les bases du CSS, on peut onboarder quelqu’un qui n’a jamais fait de Tailwind rapido.
• La doc est claire dans l’ensemble on trouve ce que l’on cherche
• Le fichier CSS pour tout le site (tout est compris dedans): 23 Ko (puisque des gens ont cités ZdS, le fichier main.css de Zds fait dans les 200 Ko). (Aucune idée de la valeur de la comparaison, je reprend l’exemple)
• La config est sympa pour limiter les espacements, etc ça limite les options et on se retrouve a utiliser toujours les mêmes espacements ce qui aide a rendre l’UX/UI plus agréable je pense.
• Il y a des plugins pour couvrir certains cas qui pourraient ne pas être gérés de base

Conclusion de mon utilisation, je ne suis plus obligé d’écrire du CSS (puisque "j’écris du tailwind" à la place) ce qui me va très bien. Pour mettre en forme je reste dans mon template, c’est très rapide pour créer des nouveau éléments. Toutes mes interfaces sont responsives quasiment sans aucun effort. Qu’on aime pas l’approche je peux l’entendre, par contre j’ai plus de mal avec le vocabulaire choisi dans le fil de discussion

Si vous avez des questions précises sur une utilisation au bout de plusieurs mois n’hésitez pas.

Je me permets d’apporter une nuance sur le poids du CSS : faudrait aussi comparer l’impact en terme sur le HTML généré d’avoir plusieurs class cumulées un peu partout.

Surtout sur des pages générées côté serveur ça peut vite bouffer de la bande passante (et ce sont plus rarement des fichiers mis en cache que du CSS qui peut facilement l’être)…

Je seconde : le CSS, c’est très facilement compressible (car extrêmement répétitif) et ça se met en cache très efficacement aussi (il est courant d’avoir des fichiers CSS en cache pendant un ou plusieurs mois). À l’opposé, le HTML se compresse un peu moins bien (car il y a plein de texte dedans) et ne se met généralement pas du tout en cache.

Sinon pour répondre aux avantages (de manière sincère : je ne les remets pas en question).

Quand tu change quelque chose a un endroit tu es sur que ça n’impacte que cet endroit (un peu comme à l’époque des style= en effet). Pour moi ne pas avoir à se demander si ça pète ailleurs est un avantage.

Je suis d’accord ; c’est d’ailleurs un des gros défauts du code de ZdS actuellement, le coup de toucher à quelque chose qui va casser un truc improbable à l’autre bout du site, ce qui rend le développement CSS parfois pénible. Cela dit, Tailwind n’est pas le seul moyen de remédier à ce problème, et un code CSS bien conçu et conteneurisé (orienté composants, donc, ce que sont bien des frameworks CSS) résout également ce problème.

Les diff sont assez simple à lire, si quelqu’un a changé un style sur un template ça se voit assez facilement

Sauf si quelque chose m’échappe, c’est identique avec le CSS (si ce n’est que le changement sera côté CSS et non côté HTML, mais avec un CSS correctement conteneurisé, on verra tout de même bien les changements de style dans le diff, sans ambiguïté). Sauf si quelque chose m’échappe ?

C’est prenable en main très facilement par quelqu’un qui connaît les bases du CSS, on peut onboarder quelqu’un qui n’a jamais fait de Tailwind rapido.

Ça reste toute une nouvelle syntaxe à apprendre, alors qu’avec que du CSS, ce ne serait que du repérage. Cela dit certes la doc est bien faite, et entre apprendre Tailwind et se repérer dans un CSS bordélique, y’a moyen que Tailwind l’emporte.

La doc est claire dans l’ensemble on trouve ce que l’on cherche

Rien à redire là dessus pour l’avoir parcourue quelques fois (mais je pense que de toute façon un tel projet n’aurait pas pu marcher sans une doc au poil).

Le fichier CSS pour tout le site (tout est compris dedans): 23 Ko (puisque des gens ont cités ZdS, le fichier main.css de Zds fait dans les 200 Ko). (Aucune idée de la valeur de la comparaison, je reprend l’exemple)

Ça ça m’intrigue : est-ce qu’on compare à complexité égale ? Je me disais justement, mais là encore peut-être que quelque chose m’échappe, que comme la feuille de style doit contenir plein de variantes, y compris non-utilisées (je pense à toutes ces classes avec des nombres notamment, genre ml-2 ml-4 etc.), elle serait plus lourde à application égale (mêmes besoins de styles).

À moins qu’il n’y ait un moyen d’optimiser ça en détectant ce qui est concrètement utilisé, par exemple ?

Dans tous les cas c’est pas forcément le point le plus intéressant car comme spécifié en intro, le CSS ça se compresse extrêmement bien et c’est généralement mis en cache pour de très longues périodes (sur les sites pour lesquels je gère ça, je mets généralement au moins un mois).

La config est sympa pour limiter les espacements, etc ça limite les options et on se retrouve a utiliser toujours les mêmes espacements ce qui aide a rendre l’UX/UI plus agréable je pense.

Ça, ça revient à l’un des grands avantages de ce genre de solutions que je soulignais : la normalisation du front-end, et mon travail actuel sur ZdS. Donc oui, c’est clairement un énorme avantage car ça permet de faire, même sans y penser, des interfaces plus cohérentes et propres avec une expérience limitée.

Mais on peut aussi, encore une fois, faire ça sans (par exemple pour ZdS, je fais ça, exactement, mais avec un ensemble de variables SASS).

Bref, Tailwind semble bien pour ceux qui en ont l’usage, mais je ne vois pas vraiment de cas où il serait indispensable… et si je suis séduit par les concepts qu’il défend (normalisation, etc.), je ne le suis pas vraiment pas la manière dont il l’apporte ; même si je suis conscient des avantages (y compris de ceux que je n’ai pas cité dans ce message, par exemple l'auto-responsive (aussi obtenable avec un framework CSS orienté composants) ou la rapidité vu qu’on a plus à écrire de CSS (là c’est imbattable)).

C’est beaucoup une question de goût, aussi.

Pour l’impact du poids je suis assez d’accord avec vous le cache, mes fichiers CSS sont en caches. Je voyais plus l’impact du poids du fichier au niveau du navigateur du client. Je ne suis pas un expert de la question mais j’imagine qu’un fichier de 200K mets plus de temps a être parsé / rendu par le navigateur qu’un fichier de 20Ko (a complexité égale: même genre de propriétés, etc.). Ça reste une hypothèse a vérifier.

Ça ça m’intrigue : est-ce qu’on compare à complexité égale ? Je me disais justement, mais là encore peut-être que quelque chose m’échappe, que comme la feuille de style doit contenir plein de variantes, y compris non-utilisées (je pense à toutes ces classes avec des nombres notamment, genre ml-2 ml-4 etc.), elle serait plus lourde à application égale (mêmes besoins de styles).Ça ça m’intrigue : est-ce qu’on compare à complexité égale ? Je me disais justement, mais là encore peut-être que quelque chose m’échappe, que comme la feuille de style doit contenir plein de variantes, y compris non-utilisées (je pense à toutes ces classes avec des nombres notamment, genre ml-2 ml-4 etc.), elle serait plus lourde à application égale (mêmes besoins de styles).

Complexité relativement similaire oui. Alors plein de variantes je pense que ça dépend pas mal de ta config tailwind, mais en effet ça doit être assez gros. Après Tailwind utilise PurgeCSS depuis la version 1.4 donc en réalité tu ne finit dans ton CSS qu’avec des classes que tu utilise. Si une classe n’est pas utilisé, elle ne sera pas dans le CSS final. Je crois que cet article en explique plus sur comment PurgeCSS a fait parti de l’idée depuis le début.

La part de goût est importante en effet, ce qui est intéressant pour moi, c’est que je n’ai pas eu à choisir l’outil (c’était déjà en place quand je suis arrivé), donc je vis avec

Pendant longtemps j’ai considéré les frameworks CSS comme mauvais car effectivement le rendu visuel se fait beaucoup dans le HTML, et cela donne des balises avec parfois 5 ou 6 classes, elles-mêmes contenues dans des balises avec des classes, etc. Bref, souvent un code lourd à lire et à maintenir. Je ne comprenais pas trop l’intérêt, parce qu’on peut effectivement faire son CSS soi-même et arriver à ce qu’on veut faire.

Et puis petit à petit, j’ai compris l’intérêt. Je suis développeur web backend, et je n’aime pas faire de l’intégration. Je n’en fais d’ailleurs professionnellement quasiment jamais, 3 ou 4 heures par an peut-être (et encore je pense que je suis large), donc une broutille. Mais par dessus tout, je ne suis pas graphiste ! Faire un design de site digne de ce nom m’est complètement impossible. Et c’est là que les frameworks entrent en jeu !

Besoin d’un bouton ? Pas de soucis, class="btn btn-primary" et le tour est joué (j’utilise Bootstrap) ! J’ai gagné du temps et j’ai un truc pas trop dégueu. Alors oui sur un bouton c’est discutable (encore que pas tant que ça, car la mise en forme a été faite par des graphistes, ce que je ne suis pas). Mais pour mettre en forme un site complet, en gérant une grille responsive ? Je n’ai ni le temps ni l’envie de me former à ça : au boulot on a des dev front, pour mes projets perso ça ne m’intéresse pas, ce qui m’importe ce sont les fonctionnalités, tant que le truc est utilisable graphiquement et pas trop moche, ça me va.

Et puis l’uniformisation des classes… Sur tous les projets, un bouton principal sera toujours stylisé de la même manière : class="btn btn-primary". Et ça ce n’est pas rien ! N’importe qui connaissant Bootstrap saura capable de lire et de comprendre ce que ça fait et de l’utiliser si besoin (cequi est mon cas durant les quelques heures par an où je fais un peu d’intégration). C’est d’ailleurs le but d’un framework que d’uniformiser les pratiques d’un projet sur l’autre. C’est un gain de temps considérable, temps qui peut être consacré à autre chose sur le projet.

class="btn btn-primary" me va personnellement très bien. J’ai plus de mal avec, par exemple, class="text-center sm:text-left mb-20 mt-40 text-50 sm:text-72 font-serif leading-tight", dans un projet pro.

J’ai réfléchi un peu plus à tout ça, et voici des choses en plus que je comprends:

• Les gens ont abandonné l’idée d’avoir plusieurs designs différents pour le même site. 99% des gens veulent un seul design pour leur site, qu’ils ont choisi. Du coup, avoir tout le site spécifié dans le code les dérange moins. (Je trouve que c’est un raisonnement compréhensible, mais je regrette que ça se fasse en flinguant la sémantique du HTML, avec les problèmes d’accessibilité qui se posent derrière.)

• Les designers veulent pouvoir modeler le site exactement comme dans leur outil de mockup préféré, et ils préfèrent gérer le placement de chaque bouton à la main si nécessaire, plutôt que d’essayer d’avoir un truc qui marche partout avec une approche qui repose sur une exécution parfaites de placement flex etc. Du coup, chaque morceau du design pourra se faire éditer avec du style="..." pour rentrer dans ce moule.

• Tant que chaque élément n’est utilisé qu’une fois, ce n’est finalement pas grave d’avoir jeté toute idée de sémantique dans le style, et d’avoir du style="..." directement.

• Pour les éléments réutilisables plusieurs fois dans la page, on fait du template (de toute façon on a des outils de préprocessing parce que HTML/CSS est trop peu flexible sans ça… donc on peut les utiliser pour automatiser le boilerplate moche), ou alors on paie des gens pour copier-coller plein de fois.

Cette approche peut marcher si on veut un site pas trop compliqué (mais responsive), joli et à la mode, qu’on est prêt à payer assez cher pour chaque changement (parce que beaucoup de boulot chiant d’adapter chaque partie du site à la main), qu’on a peu de parties vraiment dynamiques qui sont usinées en templates réutilisables, et qu’on s’en fout de la sémantique / accessibilité. Je vois pourquoi c’est populaire.