Prise en charge de Vanilla JavaScript ajoutée à Tailwind Plus

• Les blocs d’interface de Tailwind Plus peuvent désormais fonctionner entièrement avec Vanilla JavaScript uniquement
• Il est maintenant possible d’utiliser des composants interactifs sans framework comme React ou Vue
• Une nouvelle bibliothèque basée sur des custom elements, @tailwindplus/elements, est désormais proposée
• L’accent est mis sur une utilisation compatible avec diverses plateformes et frameworks
• Tous les clients de Tailwind Plus peuvent utiliser cette fonctionnalité dès maintenant

---

Arrivée de la prise en charge de Vanilla JavaScript dans Tailwind Plus

De nombreux blocs d’interface de Tailwind Plus (par exemple les dialogues, menus déroulants et palettes de commandes) nécessitaient en pratique du JavaScript pour être réellement utilisables. Jusqu’à présent, si l’on n’utilisait ni React ni Vue, il fallait écrire soi-même le JavaScript nécessaire aux interactions de ces blocs UI.

Désormais, tous les blocs UI disposent de fonctionnalités complètes, d’accessibilité et d’éléments interactifs et fonctionnent immédiatement, même dans les exemples en HTML pur. En d’autres termes, il est possible d’utiliser dans n’importe quel projet, sans dépendre d’un framework JavaScript, des blocs d’interface variés comme les menus déroulants, les palettes de commandes, les dialogues ou les panneaux coulissants.

@tailwindplus/elements : la bibliothèque centrale

Cette évolution est rendue possible par la bibliothèque @tailwindplus/elements. Il s’agit d’un package réservé aux clients de Tailwind Plus, qui propose une collection de custom elements headless.

• Ces custom elements peuvent être utilisés partout en ajoutant simplement une balise <script> dans le HTML
• Les interactions complexes, la gestion du focus, l’accessibilité clavier et l’attribution des propriétés ARIA sont prises en charge automatiquement
• Le style peut être personnalisé librement avec les classes utilitaires de Tailwind CSS ou avec du CSS écrit à la main

Principaux exemples d’utilisation

• Menu déroulant : composé de custom elements comme <el-dropdown> et <el-menu>, il fonctionne sans JavaScript supplémentaire
• Sélecteur : des éléments comme <el-select>, <el-options> et <el-option> permettent de créer des composants de sélection avancés
• Palette de commandes : des structures comme <el-command-palette> et <el-command-list> fournissent une implémentation complète

Ces custom elements gèrent automatiquement les propriétés ARIA, le déplacement du focus et la navigation au clavier, avec une forte prise en charge de l’accessibilité web.

Intégration aux frameworks et dépendance minimale à la plateforme

• L’intégration est possible aussi bien dans des environnements en HTML seul que dans Svelte, Rails (Ruby on Rails), React et d’autres contextes
• Exemple Svelte : un exemple est fourni avec ajout de liaison bidirectionnelle à <el-autocomplete>
• Exemple Rails : lors de l’envoi d’un formulaire, la valeur de <el-select> est transmise au serveur comme un contrôle de formulaire natif
• Exemple React : contrairement à Headless UI ou React Aria, l’utilisation est possible sans dépendance à un framework

Standards web récents et compatibilité navigateurs

• Elements exploite activement les fonctionnalités récentes de la plateforme web (Web Components, Custom Elements, etc.) afin d’offrir une configuration légère et une expérience native
• Si nécessaire, les polyfills sont aussi intégrés automatiquement au bundle afin d’assurer la même plage de compatibilité navigateur que Tailwind CSS v4
• À mesure que les standards web se diffusent plus largement, la taille d’Elements devrait naturellement diminuer

Une vraie universalité : « HTML comme plus petit dénominateur commun »

HTML constitue le « plus petit dénominateur commun » de tous les frameworks web, et avec Elements, les blocs UI HTML de Tailwind Plus fonctionnent de manière cohérente dans n’importe quel environnement.

• Des exemples concrets d’utilisation et du code sont fournis pour Svelte, Rails, React, etc.

Lancement et accès

• Les abonnés Tailwind Plus peuvent utiliser immédiatement tous les blocs UI mis à jour ainsi qu’Elements
• Des démonstrations classées par catégories d’interface, comme les menus déroulants et les palettes de commandes, ainsi que la documentation officielle d’Elements, sont disponibles
• Il est possible de personnaliser l’ensemble selon les besoins du projet

En conclusion

Les utilisateurs de Tailwind Plus peuvent désormais créer facilement des interfaces puissantes et accessibles dans l’environnement de leur choix, sans avoir à écrire de JavaScript complexe.

[GN⁺]

Réactions sur Hacker News

• En voyant des noms de classes Tailwind longs et hiérarchiques comme ``, on a l’impression qu’il faut désormais apprendre, en plus du CSS, un autre système de hiérarchisation

  • Chaque fois que j’ouvre un gros projet Tailwind, je reste toujours impressionné par ces listes énormes de classes sur une seule ligne

    
    ...
    
    

  • Avant Tailwind, tous les webdesigners que je croisais construisaient déjà ce genre de système à leur manière En théorie, le CSS est assez puissant et on peut très bien s’en sortir sans Tailwind Mais en pratique, le grand défaut du CSS, c’est qu’il faut concevoir séparément un modèle sémantique pour en tirer toute la puissance, alors que les designers se concentrent souvent davantage sur l’ambiance et l’émotion produites que sur la structure documentaire ou l’architecture de l’information Il est très difficile, voire impossible, de baliser ces concepts émotionnels avec des règles logiques Tailwind ne fait au fond que formaliser ce que tout le monde faisait déjà : au lieu de modéliser abstraitement le « sens », on applique directement des règles comme bold ou red

  • Je me demande quel genre de personne peut regarder ce code et dire : « Waouh, quel code propre ! » Je ne comprends pas comment Tailwind a pu devenir aussi populaire, et je pense sincèrement qu’apprendre le CSS pur est une très bonne chose Le CSS d’aujourd’hui est vraiment bien meilleur qu’avant

  • Dans les vrais projets, on finit par regrouper les classes pour les rendre plus lisibles Par exemple :

    Je code comme ça Pour l’instant je classe tout manuellement, mais j’aimerais bien qu’un outil automatise ce formatage

  • Tailwind semble au départ venir du style des frameworks CSS à classes utilitaires, une sorte de « Bourbon sous stéroïdes » Mais les gens ont adopté les exemples de code bien plus volontiers que prévu, et ont simplement continué à empiler les classes telles quelles En 2018, j’ai essayé Tailwind sur un nouveau gros projet ; à l’époque, empiler des classes comme .button ou .button-primary à partir des utilitaires Tailwind rendait la maintenance facile et gardait un HTML propre Mais quand l’équipe s’y est vraiment mise, empiler directement les classes utilitaires fournies de base s’est révélé bien plus rapide et plus simple Si on ne se préoccupe pas de l’élégance du code, le design reste cohérent et on peut reproduire très fidèlement ce qu’on voit dans Photoshop Référence Bourbon

• Il s’agit d’une approche basée sur les Web Components conformes aux standards du web Comme c’est pris en charge nativement par les navigateurs, cela fonctionne sans framework JS Je suis content de voir les développeurs utiliser davantage les Web Components Qu’est-ce que les Web Components ? (MDN)

  • C’est un changement que j’attendais depuis longtemps Avant, je m’amusais avec les Web Components dans des projets perso quand je pouvais ignorer les questions de compatibilité, donc je suis vraiment heureux de les voir arriver maintenant dans des bibliothèques grand public

  • Cela fait 12 ans que je défends l’utilité des Web Components, mais du côté des frameworks comme React, Angular ou Svelte, l’accueil a toujours été tiède Des Web Components avec du JS/TS à portée limitée et un bundler (vite ou rollup, par exemple), c’est largement suffisant, sans avoir besoin de surcoûts inutiles comme le Shadow DOM ou le rerendering complet

  • Quand je jouais avec Polymer vers 2014, le terme « transclusion » m’avait marqué À l’époque ça me semblait fascinant, mais aujourd’hui je ne me souviens même plus vraiment de ce que ça voulait dire

  • J’ai essayé d’utiliser les Web Components dans des hooks pour du code publicitaire en entreprise, et personnellement j’ai été un peu déçu Déclencher l’exécution du code est facile, mais l’API elle-même n’est pas très bonne

• Quand on regarde l’univers des composants UI populaires, on se demande pourquoi la base n’a pas toujours été « headless » Les Web Components existent depuis longtemps, donc il est étonnant que cette approche n’ait pas été plus courante Les bibliothèques par framework (SHADCN, etc.) doivent chacune maintenir leur propre documentation selon les compatibilités de version, restent enfermées dans un environnement précis et, en pratique, sont souvent moins abouties Il semblerait plus judicieux de construire une base sur Headless UI, puis d’ajouter au besoin des wrappers spécifiques à chaque framework Bien sûr, je sais que la réalité est plus compliquée, mais c’est le genre d’écosystème dont je rêve

  • Dans les frameworks populaires comme React, Vue ou Svelte, les Web Components ne sont au fond qu’un surcoût en taille de bundle ou à l’exécution Avec React en particulier, le décalage entre les modèles fait qu’il faut soit accepter des pertes en fonctionnalités ou en ergonomie, soit développer des bindings sophistiqués, ce qui enlève tout intérêt à utiliser des Web Components dès le départ Il y a aussi souvent des problèmes avec des fonctionnalités avancées comme le SSR Dans un monde dominé par React, je n’ai pas spécialement envie d’utiliser des Web Components Et l’approche headless s’accompagne souvent d’implémentations complexes ou d’un surcoût notable

• J’imagine que si quelqu’un finançait suffisamment l’équipe Tailwind, le monde se porterait bien mieux, car on pourrait profiter de tout l’écosystème Tailwind gratuitement, sans qu’ils aient à se soucier de l’argent Je trouve dommage que tant d’opportunités d’intégration profonde avec des produits comme Tailwind Plus aient été perdues Ça me rappelle l’époque où 37signals avait reçu l’investissement de Jeff Bezos et n’avait plus à s’inquiéter des VC

  • L’équipe Tailwind a déjà réussi bien au-delà de ce qu’on pouvait imaginer Si elle veut encore construire plus de choses et s’étendre, ce n’est pas par besoin d’argent, mais par ambition naturelle J’ai l’impression que Tailwind l’open source ne représente qu’une partie de l’activité, et qu’ils veulent aussi créer d’autres projets générateurs de revenus On peut comparer ça à Laravel

  • Honnêtement, aujourd’hui avec l’IA il est facile de générer des composants Tailwind, donc j’ai moins envie d’acheter des composants payants comme Tailwind Plus À l’époque de Tailwind UI, j’avais réellement payé, mais aujourd’hui je préfère demander directement à une IA comme Claude de me créer une UI, ce qui m’évite aussi les questions de licence Je me demande quel modèle économique pourra fonctionner à l’avenir

  • À propos de 37signals, personnellement je me dis parfois que les fondateurs auraient peut-être mieux fait de devoir rendre des comptes à quelqu’un

  • En réalité, « toute l’expérience Tailwind » est déjà disponible gratuitement Je me demande ce qu’on entend exactement par intégrations profondes manquantes Tailwind Plus, le produit commercial, n’est qu’un ensemble de templates prêts à l’emploi et de composants préconstruits C’est pratique pour les développeurs qui veulent démarrer vite, mais au final tout peut être construit directement avec Tailwind

  • Je me demande de quelles intégrations il s’agit concrètement

• Mieux vaut ne pas trop s’emballer pour l’instant Avant ils prenaient aussi en charge Vue, mais cela semble désormais pratiquement abandonné

  • C’est justement ça, le support de Vue Il existe tellement de frameworks qu’il est presque impossible de créer des wrappers personnalisés pour chacun Avec les Web Components, on développe une fois et ça fonctionne partout ; au bout du compte, il suffit que les frameworks prennent bien en charge les Web Components, donc à terme le HTML lui-même

  • Le support des Web Components dans Vue est très bon, et React 19 commence enfin lui aussi à bien les prendre en charge L’écosystème des Web Components est certes désordonné, mais fournir ainsi des composants réutilisables dans tous les frameworks, c’est précisément leur véritable killer app Je suis surpris qu’ils ne présentent pas cela non pas comme « pour JavaScript vanilla », mais comme « désormais compatible avec tous les frameworks »

  • Ils géraient aussi une bibliothèque de design Figma, mais elle a disparu aujourd’hui C’est vraiment regrettable quand on veut collaborer avec des designers

  • Fidèle à son nom, cela vise tailwindcss

• Je trouvais intéressant de voir cet usage des custom elements, mais je trouve un peu absurde que chez Tailwind ce soit une fonctionnalité payante Intuitivement, je m’attendrais plutôt à ce que les custom elements soient gratuits et que seules les intégrations avec les frameworks soient payantes Tarification de Tailwind Plus

  • Si cette bibliothèque est payante, c’est parce qu’elle a coûté environ 250 000 $ à développer Il aurait été impossible de la proposer gratuitement et d’en assurer la maintenance, et des ingénieurs compétents doivent être rémunérés correctement

  • Tailwind Plus est une collection payante de composants UI et de templates TailwindCSS lui-même n’est qu’un outil de styling, comme Bootstrap

  • Un autre exemple célèbre de fonctionnalité payante, c’est SSO On ne comprend pas intuitivement pourquoi c’est payant, mais c’est une stratégie délibérée pour repousser le moment de la décision d’adoption

  • Vendre ce genre de chose paraît un peu étrange Dans un monde du développement web où la gratuité est la norme, devoir payer un abonnement à vie pour utiliser un framework peut sembler bizarre Ce serait un peu comme si Postgres demandait un tarif mensuel Mais en regardant la politique tarifaire, il s’agit bien d’un achat unique à vie Je me demande dans quelle mesure ce modèle peut fonctionner

• On dirait qu’Alpine.js a disparu des custom block elements de tailwindcss plus J’ai été déçu de voir qu’AlpineJS n’apparaît plus dans les exemples de code Désormais, c’est remplacé par :

  En tant qu’utilisateur d’Alpine, je regrette de ne plus pouvoir utiliser les exemples par simple copier-coller

• J’aimerais vraiment que cette fonctionnalité soit aussi ouverte aux utilisateurs gratuits de Tailwind C’est très intéressant et j’aimerais l’essayer, mais c’est dommage de ne même pas pouvoir la tester gratuitement Cela dit, je sais bien qu’il est toujours difficile de financer l’open source, donc je remercie Tailwind J’aimerais un jour devenir quelqu’un qui fait des dons à l’open source et y contribue

• On dit qu’on peut créer dans Elements quelque chose comme une palette de commandes avancée avec ``, mais en réalité cela n’est possible que parce qu’ils ont directement ajouté cette fonctionnalité dans ce composant

• En utilisant davantage Tailwind récemment, j’ai fini par reconnaître ses atouts en matière de praticité et d’abstraction de la complexité liée à la conception d’un design system Mais sur le long terme, investir directement dans son propre design system et sa propre bibliothèque de composants reste une solution bien plus solide du point de vue de la DX, de la flexibilité, du langage esthétique et des dépendances