Sortie de Tailwind CSS v4.0

 (tailwindcss.com)
1 points par GN⁺ 2025-01-24 | 1 commentaires | Partager sur WhatsApp
  • Tailwind CSS v4.0 est une version où le framework a été réécrit de zéro, avec une forte amélioration des performances de build et un flux de configuration et de personnalisation désormais centré sur CSS
  • Sur Catalyst, un build complet passe de 378 ms avec la v3.4 à 100 ms avec la v4.0, soit 3,78× plus rapide, et un build incrémental sans nouveau CSS passe de 35 ms à 192 µs, soit 182× mieux
  • L’installation est simplifiée avec une seule ligne @import "tailwindcss" et des valeurs par défaut sans configuration ; les utilisateurs de Vite peuvent utiliser @tailwindcss/vite à la place de PostCSS
  • La v4.0 exploite des fonctionnalités CSS modernes comme les cascade layers, @property, color-mix() et les logical properties, et introduit la détection automatique du contenu ainsi que la gestion intégrée de @import
  • Les container queries, les transformations 3D, une API de gradients étendue, @starting-style, not-*, field-sizing, color-scheme, inert, etc. arrivent dans le cœur, réduisant la dépendance à des plugins séparés

Un moteur haute performance réécrit de zéro

  • Tailwind CSS v4.0 est une version qui réécrit entièrement le framework, en s’appuyant sur plusieurs années d’expérience architecturale
  • Dans les benchmarks du projet, les rebuilds complets sont plus de 3,5× plus rapides, et les builds incrémentaux plus de 8× plus rapides
  • Sur Catalyst, les temps de build médians sont les suivants
    • Build complet : v3.4 378 ms → v4.0 100 ms, amélioration de 3,78×
    • Rebuild incrémental avec nouveau CSS : 44 ms → 5 ms, amélioration de 8,8×
    • Rebuild incrémental sans nouveau CSS : 35 ms → 192 µs, amélioration de 182×
  • Les builds incrémentaux qui n’ont pas besoin de compiler de nouveau CSS sont plus de 100× plus rapides et se terminent en microsecondes
    • Plus on travaille longtemps sur un projet, plus on réutilise souvent des classes déjà employées comme flex, col-span-2 ou font-bold, ce qui rend ce type de build fréquent

Exploitation de la plateforme CSS moderne

  • La v4.0 exploite activement les fonctionnalités de la plateforme web apparues depuis Tailwind CSS v3.0
  • Les principales fonctionnalités CSS sous-jacentes sont les suivantes
    • Native cascade layers : contrôlent plus finement la manière dont différentes règles de style interagissent
    • Registered custom properties : rendent possibles les animations de gradients et améliorent fortement les performances sur les grandes pages
    • color-mix() : permet d’ajuster l’opacité de toutes les valeurs de couleur, y compris les variables CSS et currentColor
    • Logical properties : simplifient la prise en charge RTL et réduisent la taille du CSS généré
  • Ces fonctionnalités simplifient aussi l’implémentation interne de Tailwind, réduisant la surface de bugs et facilitant la maintenance

Installation et intégration au build simplifiées

  • Le flux d’installation a été rationalisé pour réduire les étapes et le boilerplate
    • npm i tailwindcss @tailwindcss/postcss
    • Ajout de @tailwindcss/postcss au plugin PostCSS
    • Utilisation de @import "tailwindcss" dans le fichier CSS
  • Avec la v4.0, Tailwind peut être importé et utilisé via une seule ligne de CSS, au lieu des directives @tailwind
  • Un flux sans configuration permet de démarrer sans aucun réglage, y compris pour les chemins des fichiers de templates
  • Les règles @import sont bundlées sans plugin externe séparé, et Lightning CSS est utilisé en interne pour le vendor prefixing et la transformation de syntaxes modernes
  • Les utilisateurs de Vite peuvent choisir @tailwindcss/vite à la place de PostCSS
    • Tailwind CSS v4.0 est déjà rapide comme plugin PostCSS, mais le plugin Vite permet d’obtenir de meilleures performances

Détection automatique du contenu et imports intégrés

  • La configuration du tableau content, nécessaire en v3, est remplacée en v4.0 par des heuristiques de détection automatique
  • Les éléments présents dans .gitignore sont automatiquement ignorés afin de ne pas scanner les dépendances ni les fichiers générés non versionnés
    • Exemples : /node_modules, /coverage, /.next, /build
  • Les extensions binaires comme les images, les vidéos ou .zip sont également ignorées automatiquement
  • Lorsqu’il faut ajouter explicitement une source exclue par défaut, la directive @source peut être utilisée dans le fichier CSS
    • @source "../node_modules/@my-company/ui-lib";
    • @source utilise les mêmes heuristiques, donc les types de fichiers binaires sont exclus sans avoir à préciser d’extensions séparées
  • Avant la v4.0, il fallait un plugin séparé comme postcss-import pour inliner d’autres fichiers CSS via @import, mais la prise en charge intégrée des imports rend désormais les autres outils inutiles
    • Le système d’import a été conçu spécifiquement pour Tailwind CSS et s’intègre étroitement au moteur, ce qui le rend plus rapide

Configuration CSS-first et theme variables

  • L’un des grands changements de la v4.0 est que la configuration du projet se fait directement en CSS, et non plus en JavaScript
  • À la place du fichier tailwind.config.js, on peut personnaliser Tailwind avec @theme dans le fichier CSS qui l’importe
    • Définition des design tokens
    • Définition d’utilitaires personnalisés
    • Définition de variants personnalisés
  • Les design tokens définis dans @theme sont exposés par défaut comme variables CSS
    • Exemples : --font-display, --breakpoint-3xl, --color-avocado-500, --ease-fluid
  • Les variables CSS ainsi générées peuvent être référencées à l’exécution comme du CSS ordinaire
    • Réutilisation dans des styles inline
    • Transmission à des bibliothèques comme Motion pour gérer les animations

Valeurs d’utilitaires et variants dynamiques

  • La v4.0 simplifie plusieurs utilitaires et variants afin qu’ils acceptent certaines valeurs arbitraires sans configuration
  • Les grilles peuvent utiliser la taille souhaitée sans configuration séparée
    • Exemple : grid grid-cols-15
  • Les attributs data booléens personnalisés peuvent aussi être ciblés sans définition préalable
    • Exemple : data-current:opacity-100
  • Les utilitaires de spacing comme px-*, mt-*, w-* et h-* sont dérivés dynamiquement d’une seule variable d’échelle de spacing
    • Exemple : --spacing: 0.25rem
    • w-17 est généré sous la forme calc(var(--spacing) * 17)
  • L’outil de mise à niveau publié avec la v4.0 simplifie automatiquement la plupart des syntaxes de valeurs arbitraires qui ne sont plus nécessaires lorsqu’il les détecte

Palette de couleurs et container queries

  • Toute la palette de couleurs par défaut passe de rgb à oklch
    • Cela exploite un gamut plus large que les limites de l’espace colorimétrique sRGB, pour des couleurs plus vives
    • Comme l’équilibre entre les couleurs de la v3 a été conservé autant que possible, la mise à niveau de projets existants ne devrait pas donner l’impression d’un breaking change
  • La prise en charge des container queries arrive dans le cœur avec la v4.0, ce qui rend le plugin @tailwindcss/container-queries inutile
  • Le nouveau variant @max-* permet d’utiliser des container queries en max-width
  • Comme avec les variants de breakpoints classiques, on peut empiler @min-* et @max-* pour définir une plage de container query

Transformations 3D et extension de l’API de gradients

  • La v4.0 ajoute une API pour les transformations 3D
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • Les fonctionnalités de gradients sont également étendues pour créer des effets plus variés sans CSS personnalisé
  • Les gradients linéaires peuvent accepter un angle comme valeur
    • Exemple : bg-linear-45
    • L’ancien bg-gradient-* est renommé en bg-linear-*
  • Le mode d’interpolation des couleurs de gradient peut être contrôlé via un modifier
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • L’interpolation par défaut en v4.0 est OKLAB, et d’autres modifiers d’espaces colorimétriques peuvent aussi être utilisés
  • Les nouveaux utilitaires bg-conic-* et bg-radial-* permettent de créer des gradients coniques et radiaux
    • Ils fonctionnent avec les from-*, via-* et to-* existants
    • Ils incluent la prise en charge des modifiers de configuration du mode d’interpolation des couleurs et des valeurs arbitraires pour un contrôle fin, comme la position du gradient

Nouveaux variants et utilitaires

  • Le nouveau variant starting prend en charge le CSS @starting-style
    • Il permet de créer une transition de propriétés lorsqu’un élément apparaît pour la première fois
    • Il permet d’animer des éléments qui apparaissent sur la page sans JavaScript
    • La prise en charge par les navigateurs n’est peut-être pas encore suffisante pour la plupart des équipes, mais elle s’en rapproche
  • Le nouveau variant not-* prend en charge la pseudo-classe CSS :not()
    • Exemple : not-hover:opacity-75
    • Il permet aussi de nier des media queries et des queries @supports
  • La v4.0 ajoute aussi les utilitaires et variants suivants
    • inset-shadow-*, inset-ring-* : permettent d’empiler jusqu’à 4 couches de box-shadow sur un seul élément
    • field-sizing : prend en charge le redimensionnement automatique des textarea sans JavaScript
    • color-scheme : permet de supprimer les scrollbars claires en dark mode
    • font-stretch : ajuste les variable fonts qui prennent en charge différentes largeurs
    • inert : style les éléments non interactifs marqués avec l’attribut inert
    • nth-* : prend en charge le styling de la famille nth
    • in-* : fonctionne de manière similaire à group-* sans classe group
    • :popover-open : cible aussi les popovers ouverts avec le variant open existant
    • descendant variant : style tous les éléments descendants

Démarrage et chemin de mise à niveau

À lire aussi

1 commentaires

 
GN⁺ 2025-01-24
Avis sur Hacker News

  • J’ai autrefois vivement critiqué les nombreux défauts de Tailwind et son incompatibilité avec une approche web moderne réellement « pure », mais les grands progrès de la v4 me réjouissent beaucoup
    Le fait de pouvoir accéder au thème Tailwind sous forme de variables CSS natives, et même de voir dans la documentation un exemple de composant bouton écrit avec des variables natives dans une feuille de style externe, est un énorme changement
    Pouvoir le configurer uniquement en CSS est également excellent, et Tailwind ressemble désormais moins à un framework JavaScript « viral » qui avale une architecture raisonnable qu’à un utilitaire que l’on peut ajouter à n’importe quel projet
    Que les critiques des dernières années aient porté leurs fruits ou qu’ils soient arrivés d’eux-mêmes à de bonnes conclusions, une grande partie des débats pour ou contre Tailwind semble désormais moins pertinente, et c’est une très bonne chose. On peut maintenant se concentrer sur la création de produits

    • Je reste critique sur son usage concret, mais il est surprenant de voir à quel point Tailwind s’adapte bien aux workflows générés par l’IA
      Comme on peut tout exprimer de manière systématique, cela fonctionne vraiment bien, et il y a là quelque chose d’extrêmement utile
    • J’ai du mal à accepter l’idée que les débats pour ou contre Tailwind ne soient plus pertinents, et en tant que designer / design engineer, j’y vois deux problèmes
      Premièrement, les ingénieurs JavaScript/Tailwind ont pris le contrôle des discussions de design. On finit par se concentrer davantage sur « utility-first », « suppression du code inutilisé » ou « CSS type-safe » que sur les systèmes de design, par exemple la question de savoir s’il faut utiliser une Perfect Fifth ou une Perfect Fourth en typographie
      Deuxièmement, Tailwind rend la participation au processus de production réel plus difficile. Les décisions de design se retrouvent enfouies dans des expressions absconses de composants React comme flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)]
      Cela peut être compréhensible pour un ingénieur JavaScript, mais cela devient un obstacle au design systématique. Au lieu d’exprimer des relations mathématiques précises en CSS, on revient en quelque sorte à des styles inline plus pratiques
    • Je voudrais seulement la palette de couleurs de Tailwind CSS

  • CSS est devenu beaucoup plus facile à utiliser qu’avant, et la plupart des navigateurs se comportent désormais de manière cohérente
    Cela vaut la peine de l’apprendre, puisqu’il n’y a pas besoin d’étape de build et que le balisage n’est pas encombré par un excès de code
    On peut aussi écrire directement un attribut style dans le HTML, ce qu’on évitait autrefois au nom de la séparation des préoccupations. Je me demande donc pourquoi vouloir réintroduire une approche similaire. Est-ce juste pour économiser quelques caractères ?
    L’attribut style paraît même plus intuitif, puisqu’il n’oblige pas à convertir le code mentalement. J’ai du mal à en voir l’attrait

    • Il y a pas mal de choses qu’on ne peut pas faire avec l’attribut style. Par exemple les pseudo-classes :hover, :focus, les pseudo-éléments ::before, ::after, les media queries, les keyframes et les animations
      L’expérience développeur n’est pas bonne non plus dans les grands projets
      En revanche, @scope, qui sera bientôt standard, est un bon ajout pour placer les styles à proximité : https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • Aujourd’hui, Tailwind est souvent utilisé avec un système d’abstraction de composants qui sert de couche d’abstraction à la place des classes CSS
      L’abstraction de composants sépare plus fortement le sens et le style. Dans les deux cas, il faut trouver l’abstraction « hero », mais dans le monde des composants, on abstrait non seulement les styles, mais aussi les noms des balises HTML
      Dans tous les cas, les « détails de style » sont séparés du « contenu », c’est-à-dire du fichier source de la page. On peut accepter une étape de build pour une meilleure séparation des préoccupations, autrement dit une meilleure séparation entre contenu et présentation
    • Son attrait tient au fait qu’il n’est pas nécessaire de nommer des classes CSS, que c’est placé à côté du HTML donc facile à lire, et que la convention de nommage est standardisée avec les mêmes règles partout
      Il y a aussi moins besoin de gérer des fichiers séparés et de supprimer les composants inutilisés
      On peut utiliser des media queries, ce qui n’était pas possible avec une balise style, et on ne risque pas de modifier une classe utilisée ailleurs. La portée globale de CSS a des avantages, mais elle est dangereuse
    • C’est le résultat du fait qu’on en est venu à considérer comme trop évidente l’intégration forte avec React
      Les styles sont perçus comme appartenant aux composants, et non au système de design. L’écosystème d’ingénierie JavaScript-first a davantage besoin d’entreprises guidées par le design qui connaissent la puissance du CSS moderne et du design systématique
    • Quand on regarde le nombre de fichiers à gérer dans un grand projet, Tailwind paraît assez séduisant
      L’approche classique avec des fichiers .css entraîne des noms bizarres, des doublons et des risques de collision. css modules est aussi une option, mais le nombre de fichiers est pratiquement doublé pour chaque composant/page
      sass ou less donnent l’impression de combiner les problèmes de css modules et du .css classique
      Je n’aime ni ne déteste fondamentalement Tailwind, et je l’ai même détesté au début, mais dans un projet de composants et de pages comportant plus de 200 fichiers, j’en vois la valeur

  • Ma première réaction à Tailwind a été : « c’est pénible ». Je connaissais déjà CSS, et j’avais l’impression de devoir réapprendre CSS
    Ça ressemble à un parent qui essaie d’aider son enfant avec ses devoirs de maths, mais la méthode enseignée à l’école a complètement changé par rapport à avant : sa solution reste correcte, mais elle n’est pas acceptée, et l’enfant s’énerve à devoir faire correspondre les deux systèmes
    Je comprends l’ambiance qui consiste à dire qu’il faut simplement l’utiliser parce que ça fonctionne bien en équipe et que ça passe bien à l’échelle, et j’en ai fait l’expérience
    Malgré tout, je préfère toujours une feuille de style ordinaire qui cible des classes ou des balises. D’autant plus maintenant que CSS prend en charge les sélecteurs imbriqués
    Il y a bien un problème de gestion des feuilles de style, et j’aime l’approche de Remix/React Router qui consiste à définir et appliquer des fichiers CSS au niveau des routes. Si ça ne suffit pas, ou si les styles dynamiques deviennent trop complexes dans des fichiers .css, style={{...}} reste toujours possible
    CSS est puissant, flexible et extensible, donc Tailwind me donne l’impression d’être une contrainte plutôt qu’une amélioration. Je ne sais pas vraiment pourquoi il reste populaire, mais je pense que dans 3 ou 4 ans tout le monde sera passé à autre chose

    • Au début, cette impression de réapprendre CSS me frustrait, et je tenais le même discours
      Mais en contribuant à un projet open source qui utilise Tailwind, je m’y suis habitué, et je le ressens différemment maintenant
      Tailwind est fondamentalement assez proche d’une abréviation de style={{…}}. Ce qui prendrait plusieurs lignes avec un fichier .css ou un objet de style se résume à environ 15 caractères avec une seule utilitaire
      Je passe beaucoup moins de temps à chercher des choses comme « visual text replacement css », à consulter des antisèches CSS ou à fouiller de vieux articles CSS-Tricks d’il y a 8 ans. À la place, je regarde toujours la documentation de Tailwind et je trouve rapidement la classe utilitaire qui fait ce que je veux
      Une quantité surprenante de choses finit dans mon cache mental, et ça me paraît bien mieux que d’essayer de mémoriser tout le CSS nécessaire au travail de mise en page
    • Je pense que c’est parce que désormais tout le composant tient dans un seul fichier
      Pas besoin de toucher à du CSS séparément, et comme le style est juste au-dessus de l’élément auquel il s’applique, il n’y a pas besoin de comparer les deux
      On peut certes faire la même chose avec l’attribut css, mais le problème est qu’on nous a tous appris que c’était la mauvaise façon de faire, et qu’une liste de chaînes contenant plusieurs utilitaires est aussi plus simple qu’un objet CSS pur
    • Les contraintes réduisent la complexité possible, et c’est pour ça que Tailwind gagne
      C’est une enveloppe modulaire, composable et standardisée posée sur un système énorme et complexe, donc c’est une grande avancée
    • J’apprends les maths avec mon enfant, et ce n’est pas différent de ce que j’ai appris ; je peux toujours résoudre les exercices rapidement
      En revanche, sur les réseaux sociaux, on voit des publications qui mélangent multiplication et division en prétendant qu’il n’y a qu’une seule bonne réponse. Tailwind n’est pas mauvais à ce point, mais de mon point de vue de vieux, il semble aller davantage dans cette direction

  • J’aime Tailwind. Je l’ai utilisé sur 3 projets ces 4 dernières années, et je l’ai trouvé intuitif, bien documenté et simple
    L’époque d’emotion et de styled-components, où il fallait nommer chaque div stylée du projet, ne me manque pas
    Avec Tailwind, un conteneur n’est qu’un div avec quelques classes. Il y a moins de débats de nommage, et moins de charge mentale et de temps de revue consacrés aux noms

    • Je vois souvent revenir ce problème qui consiste à devoir réfléchir au nom de chaque div stylée, et ça m’étonne un peu
      Je ne crois presque jamais avoir passé plus d’une seconde à nommer quelque chose. Est-ce vraiment un point de blocage pour certains ? Je me demande sincèrement si ça peut aller jusqu’à les paralyser
    • Si tu parles de « quelques classes », tu dois travailler avec un excellent responsable produit
      Les personnes que j’ai connues avaient tendance à spécifier sans fin le moindre détail possible. Elles traitaient les formulaires web comme leur rénovation HGTV personnelle
      La fois où j’ai essayé Tailwind, les classes sont devenues au moins un ordre de grandeur plus nombreuses que le balisage, et c’est vite devenu difficile à lire
    • Je l’ai utilisé sur plusieurs projets, mais je n’ai pas aimé. Sur les gros projets, ça devient vite brouillon, et ça donne l’impression d’être le nouveau Bootstrap
      Aujourd’hui, je suis satisfait de mon workflow CSS-in-JS. C’est une façon d’écrire du CSS à l’ancienne avec l’aide d’un LLM. Je montre une image au LLM et lui demande un composant, et il me le sort directement avec des noms appropriés
    • Si j’ai le choix, c’est l’une des principales raisons pour lesquelles j’évite React
      Le styling dans React n’est pas terrible, et même avec Tailwind, ce n’est que l’option la moins mauvaise
      Si l’on utilise un framework front-end et une étape de build, Svelte et Astro sont de bons choix selon l’usage. On peut styler avec du CSS ordinaire, et si l’on garde les composants petits, on a à peine besoin d’utiliser des noms de classes
      Il suffit d’utiliser des sélecteurs d’éléments et de laisser le framework scoper les styles au moment du build

  • J’ai essayé Tailwind sur mon site et je l’ai plutôt apprécié, mais peut-être pas pour les raisons généralement avancées
    La vraie valeur de Tailwind, c’est qu’on peut lire tous les styles qui affectent un élément au même endroit
    Les noms de classes peuvent devenir longs, mais lire une longue ligne est bien plus rapide que d’ouvrir sans cesse les outils de développement du navigateur ou de faire des allers-retours dans une ou plusieurs feuilles de style
    Quand on revient plus tard sur ce code, on peut le modifier avec confiance sans craindre de changer d’autres éléments par inadvertance
    La nature en cascade de CSS reste utile, mais en général je veux limiter les styles à un seul élément. Pour le reste, je reviens à CSS, mais en pratique j’écris très peu de CSS. La plupart du temps, je veux simplement ajuster les espacements

    • C’est précisément ce qui rend Tailwind agréable et pratique, à mon avis
      J’aime aussi le fait que « comment faire X ? » se règle par une recherche rapide dans la documentation, et non par une enquête de 30 minutes
    • Il existe aussi dans les IDE des outils qui montrent tous les styles appliqués à un élément. Par exemple « Show Applied Styles for Tag » dans Intellij, ou les outils de développement Chrome, qui les présentent de manière lisible
      À côté de ça, les extraits Tailwind montrés dans ce fil HN font assez peur
    • Je suis plutôt d’accord, mais le même problème subsiste
      Si on ajoute text-xl à un div et qu’il contient des div et des span imbriqués, tous héritent de text-xl, donc pour voir ce qui provoque text-xl sur les éléments imbriqués, il faut quand même remonter la hiérarchie des éléments
      Cela dit, dans l’ensemble, c’est quand même un peu plus simple

  • Les formules « temps de build réduit », « plus de directive @tailwind », « pas de configuration JavaScript », « conçu pour le Web moderne » sonnent comme ceci
    CSS peut désormais faire tout ce qu’on faisait nous-mêmes directement, mais faisons quand même semblant de rester indispensables

    • Si on doit détester quelque chose, il faut au moins essayer de comprendre ce que c’est et pourquoi les gens l’utilisent
    • L’argument de vente de Tailwind a toujours été, dès le départ : « presque du CSS inline, mais moins pénible que l’attribut style et beaucoup plus facile à optimiser »
    • Je me demande ce qu’il fallait autrefois Tailwind pour faire et qu’on ne pouvait pas faire en CSS classique
      Tailwind ne correspond-il pas quasiment à du CSS en 1:1 ?
    • Je me demande si tu l’as vraiment compris comme ça
      Je comprends qu’on n’aime pas Tailwind, mais je pense qu’il vaut mieux dire ce qu’on n’aime pas dans Tailwind plutôt que de s’attaquer à un homme de paille
      Ce n’est pas terrible non plus de rabaisser le projet open source de quelqu’un d’autre et les personnes qui le trouvent utile

  • J’aimerais poser une question aux gens qui connaissent bien CSS. Ce n’est pas mon cas
    Je suis en train de migrer un projet Phoenix personnel vers la version 1.7 et, comme Phoenix utilise désormais Tailwind par défaut, j’ai voulu essayer à la place de Bootstrap
    Jusqu’ici, la version Bootstrap avait l’air « plutôt correcte », tandis que la version Tailwind ressemble à un bazar
    Quelle est la façon la plus simple d’obtenir des valeurs par défaut qui rendent bien sans essayer de devenir designer ? Ou est-ce que je devrais simplement réinstaller Bootstrap et en rester là ?

    • Dans ce cas, je réinstallerais Bootstrap
      Tailwind te donne des outils quand tu veux contrôler le design, mais au final tu dois contrôler le design toi-même
      Si tu veux simplement quelque chose qui ait bonne allure et que le style Bootstrap te convient, Bootstrap est le bon choix
      En théorie, il existe des projets qui réimplémentent Bootstrap par-dessus Tailwind et qui peuvent te donner un point de départ façon Bootstrap avec la puissance de Tailwind, mais en pratique je n’en ai pas vu qui fonctionnent mieux que simplement utiliser Bootstrap
    • Pour cet usage, j’utilise DaisyUI. Voici un site de démo d’exemple : https://nwk-landing-kit.netlify.app
      La documentation de DaisyUI est ici : https://daisyui.com
    • Si tu cherches des composants façon Bootstrap, tu peux essayer gratuitement https://flowbite.com/
      Tailwind propose aussi des composants payants, qu’il suffit de copier-coller. Ce qui est bien, c’est qu’une fois à l’aise, tu peux modifier progressivement les composants Flowbite
    • Ça dépend de qui paie
      Si tu as une bonne sécurité de l’emploi et envie de bricoler, tu peux t’amuser avec Tailwind. Les gens sensibles aux tendances et très vocaux semblent généralement aimer Tailwind
      Mais si c’est ton propre projet, autofinancé, ou avec une deadline, mieux vaut utiliser le Bootstrap que tu connais déjà et te concentrer sur le fait de terminer le travail plutôt que de t’épuiser sur l’UI
    • Comparer Tailwind et Bootstrap, c’est un peu comparer des pommes et une tarte aux pommes
      Tailwind fournit des classes à empiler pour construire des composants
      Ce sera plus simple avec des sources de composants UI. J’ai déjà utilisé TailwindUI, mais c’était payant ; il existe probablement de bonnes alternatives gratuites

  • La discussion « Tailwind ou pas Tailwind » suit un schéma très clair. Il se répète chaque fois que Tailwind est mentionné
    Il y a les gens qui ne l’ont jamais vraiment utilisé plus de 30 minutes, qui l’ont essayé vite fait ou ont seulement parcouru la documentation. Ils n’aiment pas Tailwind et préfèrent quelque chose comme du « CSS pur »
    À l’inverse, il y a ceux qui l’ont utilisé sur de vrais projets, au sein d’équipes de plus d’une personne. Ils en comprennent la valeur, acceptent les compromis, et l’apprécient
    J’ai vu beaucoup de gens passer du premier groupe au second, mais presque personne revenir du second au premier
    C’est pour ça que Tailwind a réussi. Ce n’est peut-être pas beau aux yeux des puristes, mais pour les gens qui construisent des choses et les pragmatiques, c’est vraiment excellent

    • Je pense ne rentrer dans aucun de ces deux groupes
      Je ne suis pas opposé à Tailwind, mais si je ne l’ai pas encore utilisé, c’est parce que je ne vois pas bien en quoi c’est une meilleure approche que d’autres options comme les Web Components ou les React Styled Components
      Le plus gros problème, c’est que Tailwind encombre le HTML d’une multitude de classes utilitaires, ce qui le rend difficile à lire et à maintenir
      Je comprends que ce soit mieux qu’un énorme fichier CSS global et que le CSS classique basé sur les noms de balises, mais il existe déjà des façons d’utiliser du CSS scopé au composant sans polluer l’espace de noms global. Les Web Components et les Styled Components en sont des exemples
      Dans les deux cas, les styles sont directement rattachés au composant, ou plus généralement à un ensemble donné de balises HTML, ce qui permet de voir facilement quels styles s’appliquent où
      Pas besoin non plus de noms de classes globaux, et il y a moins de risque d’effets de bord ou de collisions indésirables. Quand on supprime un composant, les styles associés disparaissent avec lui, donc pas de CSS inutilisé qui reste. Grâce au shadow DOM, il n’y a pas non plus de risque qu’un style de composant affecte involontairement un autre composant
      J’accorde de l’importance au fait de ne pas mélanger directement les styles de présentation au balisage, afin de garder le HTML court et lisible. Avec Tailwind, comme tous les styles se retrouvent dans l’attribut class, on obtient de longues listes de classes sur une seule ligne, et si l’on doit aussi ajouter de vrais noms de classes, le HTML devient brouillon
      Il est difficile de comprendre d’un coup d’œil quels styles s’appliquent, et même de l’indenter correctement. Cela rappelle plusieurs des raisons pour lesquelles on s’est éloigné autrefois des attributs style inline en HTML
      Je ne déteste pas Tailwind, mais du point de vue de la lisibilité, de la maintenabilité et de la séparation des préoccupations, je ne vois pas d’avantage clair par rapport aux Web Components ou aux Styled Components, et mes inquiétudes restent largement sans réponse
      J’ai lu la documentation mais je ne l’ai pas utilisé, et j’ai du mal à comprendre pourquoi choisir Tailwind plutôt qu’une autre option. Le fait d’avoir énormément de classes au milieu d’un HTML ordinaire rend les deux difficiles à lire pour moi

  • Je reconnais qu’il y a des gens qui utilisent Tailwind utilement et sont productifs avec, mais maintenant que Tailwind est partout, on voit un peu partout une apparence propre mais banale

    • C’est confondre Tailwind avec TailwindUI/shadcn, etc.
      Dans l’ensemble, Tailwind n’influence pas davantage le style que du CSS classique. Il y a quelques exceptions. Des choses comme les ombres sont un peu plus standardisées, et la palette de couleurs indigo a récemment eu une certaine influence au-delà de Tailwind
    • Tailwind fournit des valeurs par défaut raisonnables, mais n’a pas une grande influence sur le design
      C’est juste que les gens ont tendance à concevoir les sites d’une certaine façon. C’est particulièrement vrai lorsqu’ils l’utilisent avec ShadCn
    • En fait, ça me semble plutôt positif. Les options de Tailwind sont bien conçues et fonctionnent bien
      Je vois ça un peu comme Inter, utilisé comme la nouvelle Helvetica pour les polices de sites web. Si beaucoup de gens l’utilisent et que le rendu est bon, je ne vois pas vraiment de raison de s’en priver
    • On disait déjà la même chose à propos de Bootstrap, mais les sites Bootstrap que j’ai créés ne se ressemblaient pas
      Bootstrap proposait déjà beaucoup de classes utilitaires bien avant Tailwind, ce qui faisait gagner énormément de temps, et n’imposait pas une apparence particulière
      Il suffisait d’importer uniquement les classes voulues. Bien sûr, c’était différent si vous ne téléchargiez pas les fichiers source Sass, mais cela aurait été un choix idiot
    • Mon avis sur ce problème, c’est que les bons frameworks d’UI, c’est-à-dire les combinaisons de Tailwind et de composants, restent encore rares
      C’est pourquoi la plupart des projets utilisent un très petit nombre de frameworks. Si 4 ou 5 projets d’UI de qualité supplémentaires voyaient le jour, surtout avec des directions stylistiques plus différentes, la diversité augmenterait
      Comme pour beaucoup de travaux créatifs, il semble qu’un nombre étonnamment réduit de personnes fixe les tendances en design
      J’aimerais que davantage de gens en aient conscience. Il doit y avoir des personnes talentueuses qui ne créent rien parce qu’elles se disent que « même si je le faisais, personne n’écouterait »
      Mais je pense que si certaines d’entre elles essayaient, elles pourraient ouvrir la voie à de nouvelles interfaces pour une grande partie du web

  • Tailwind est la preuve des avantages des styles inline — la possibilité de styler quelque chose sans lui donner de nom —, de l’universalité des chaînes de caractères, mais aussi de leurs limites
    J’attends avec impatience ce qui viendra ensuite, et d’ici là j’utiliserai Tailwind à contrecœur