Les Web Components, ça va

 (nolanlawson.com)
2 points par GN⁺ 2024-10-01 | 1 commentaires | Partager sur WhatsApp
  • Le débat sur les Web Components ne consiste pas à choisir entre performances maximales et standard de plateforme ; l’idée de départ selon laquelle ils devraient remplacer tous les frameworks JavaScript est déjà excessive
  • Comme les Custom Elements utilisent le DOM comme interface, ils entraînent un surcoût, mais dans un vrai produit il faut évaluer non seulement les performances, mais aussi la maintenabilité, la sécurité, l’utilisabilité et l’accessibilité
  • Le coût de prise en charge des Web Components par les frameworks peut être absorbé par quelques vérifications simples, et le fait qu’une fonctionnalité soit standard ne signifie pas que tous les frameworks doivent forcément l’adopter
  • Les Web Components ont des faiblesses en matière de rendu côté serveur (SSR), d’accessibilité et de certaines formes d’interopérabilité, si bien qu’il reste des situations où React, Solid ou Svelte sont plus adaptés
  • Dans des environnements comme Salesforce, où les apps rendues côté client, une marketplace de composants et une compatibilité descendante de long terme sont importantes, les Web Components peuvent être une option réaliste

Point de départ du débat et position de l’auteur

  • Le débat récent s’inscrit dans le prolongement de « Web Components Are Not the Future » de Ryan Carniato et de « Web Components Are Not the Future — They’re the Present » de Cory LaViska
  • L’enjeu n’est pas d’attaquer le camp d’en face, mais plutôt de savoir si des développeurs soumis à des contraintes différentes peuvent trouver un terrain commun
  • Ryan Carniato est très estimé pour son travail sur les performances et la conception de frameworks, notamment avec Solid et js-framework-benchmark
  • Les Web Components ont eux aussi des usages concrets liés à l’implémentation de frameworks, à la création de composants, au Web Components Community Group, au groupe Accessibility Object Model, ainsi qu’aux travaux sur le shadow DOM, les custom elements et l’accessibilité

Performances : le coût du DOM est réel, mais ce n’est pas tout

  • La faiblesse de base des Web Components tient au fait qu’ils reposent sur les Custom Elements
    • Toutes les interfaces doivent passer par le DOM, ce qui crée un surcoût de performance
    • Si l’objectif est d’obtenir le framework le plus rapide dans l’absolu, il faut réduire autant que possible le nombre de nœuds DOM ; selon ce critère, les Web Components sont désavantagés
  • Mais les performances ne sont pas le seul critère du développement logiciel
    • La maintenabilité, la sécurité, l’utilisabilité et l’accessibilité doivent aussi être prises en compte
    • Ne pas rendre les attributs aria-* peut rendre le rendu DOM un peu plus rapide, mais ils peuvent être nécessaires pour une interface accessible
    • Les micro-optimisations du type une boucle for plus rapide que .forEach(), ou var plus rapide que const/let, valent généralement peu le compromis
  • La minimisation des nœuds DOM est l’idée centrale de la virtualisation
    • Même si ce n’est pas le choix le plus rapide, une approche plus simple peut parfois suffire
    • Les components as elements ne sont pas optimaux non plus, mais l’optimum n’a pas toujours besoin d’être l’objectif
  • Utiliser ensemble des custom elements créés avec différents frameworks a aussi du sens en pratique
    • Il peut être nécessaire de migrer progressivement du framework A vers le framework B
    • Il peut aussi falloir combiner plusieurs micro-frontends
    • Ce n’est pas l’interface la plus rapide, mais cela peut être un compromis nécessaire
  • Dans les performances web réelles, on trouve plus souvent des améliorations peu coûteuses comme le layout thrashing, les waterfalls réseau ou les rerendus inutiles
    • Les compétitions comme js-framework-benchmark sont intéressantes pour les auteurs de frameworks, mais ne sont pas toujours décisives dans les situations produit ordinaires
    • Dans un environnement aux ressources limitées où chaque milliseconde compte, choisir d’abandonner les Web Components peut aussi être légitime

Coût de prise en charge par les frameworks et liberté de choix

  • L’auteur n’est pas d’accord avec l’idée que la prise en charge des Web Components représenterait un coût excessif pour les auteurs de frameworks
    • La détection des props et des attributes peut être gérée avec une vérification prop in element
    • Produire des Web Components peut être pénible, mais ce n’est pas une tâche que tous les frameworks doivent forcément assumer
    • Vue 2 utilisait une bibliothèque wrapper pour web components distincte, et Remount existe sans intervention de l’équipe React
  • Un framework peut être excellent tout en ignorant les fonctionnalités ajoutées à la plateforme web depuis 2011
    • jQuery v1 fonctionne encore sur de nombreux sites web
    • Les équipes performance des navigateurs optimisant les anciens schémas des développeurs web, du vieux code peut aussi devenir plus rapide dans les navigateurs récents
  • Adopter les fonctionnalités récentes de la plateforme web s’accompagne de nouvelles considérations
    • Des fonctionnalités comme Symbol, Proxy et les Promises relèvent de la même catégorie
    • Grâce à la compatibilité descendante du web, le code écrit aujourd’hui peut continuer à fonctionner dans 10 ans
  • Il est tout à fait possible d’avoir un framework qui ne s’intéresse pas aux Web Components ou ne souhaite pas les prendre en charge
    • On peut créer toute une UI en Web Components
    • On peut aussi n’y mêler que quelques HTML web components
    • On peut également choisir de ne pas les utiliser du tout
    • Un framework « no web components » peut aussi trouver son public

Les standards sont des points de référence, pas des obligations

  • Lorsqu’une fonctionnalité devient un standard, les développeurs en font naturellement un point de comparaison par défaut
    • Un auteur de composants doit décider si son <slot> doit se comporter comme le <slot> natif
    • Il faut aussi choisir entre utiliser IntersectionObserver ou <img loading="lazy">, et créer sa propre abstraction
  • Les standards fournissent un point de référence commun et un vocabulaire partagé
    • Ils donnent des critères pour comparer et opposer différentes approches
    • Mais ce n’est pas parce que quelque chose est standard qu’il faut forcément l’utiliser
  • Le web conserve à la fois des fonctionnalités dont on peut se passer et d’anciennes API
    • Des API dépréciées comme document.domain, with ou <frame> restent prises en charge
    • Les fonctionnalités de la plateforme web peuvent être choisies ou écartées selon les besoins

Là où les Web Components conviennent, et là où ils ne conviennent pas

  • Les Web Components font très bien beaucoup de choses, mais ne sont pas un outil destiné à remplacer tous les frameworks JavaScript
  • Leurs faiblesses incluent le rendu côté serveur (SSR), l’accessibilité et certaines formes d’interopérabilité
  • Il reste de nombreuses situations où des frameworks comme React, Solid ou Svelte brillent davantage
  • Dire que « les Web Components ne sont pas l’avenir » peut être vrai pour certains développeurs ou certains projets
  • Au fond, le débat vient du fait que des personnes différentes construisent des choses différentes sous des contraintes différentes

Le cas Salesforce et le jugement pratique

  • Salesforce illustre un environnement où les Web Components peuvent bien convenir
  • Hors de ces conditions, il peut ne pas être nécessaire de construire toute l’UI en Web Components, avec shadow DOM et tout l’écosystème associé
  • Sur la plateforme web coexistent des jeux, des projets artistiques et des apps SaaS d’entreprise créés avec des fonctionnalités variées comme WebGL, Wasm ou les Service Workers
  • Lorsqu’une nouvelle fonctionnalité est ajoutée à la plateforme, elle limite moins la créativité qu’elle n’ouvre davantage de possibilités d’expression d’une manière auparavant inimaginable
  • Parmi les lectures complémentaires figurent aussi l’article de Lea Verou et l’article de Baldur Bjarnason

À lire aussi

1 commentaires

 
GN⁺ 2024-10-01
Avis de Hacker News

  • J’ai essayé de comprendre l’article cité, « Web Components Are Not the Future », mais il n’y avait pas beaucoup d’arguments convaincants
    L’état actuel des frameworks front-end est chaotique, et je n’ai pas envie d’apprendre de la magie incompréhensible (useState, createSignal, etc.) avant d’avoir lu un framework complexe ou sa documentation
    En partant des Web Components, cela paraît intuitif, et on obtient aussi des capacités qu’on ne trouve pas ailleurs, comme l’isolation du Shadow DOM
    À mes yeux, la seule chose à conserver de l’ère React est JSX, et j’ai créé une bibliothèque qui utilise les Web Components avec JSX : https://webjsx.org

    • La phrase « je ne veux pas apprendre un framework complexe » mélange plusieurs idées, ce qui la rend difficile à interpréter
      On ne sait pas très bien s’il s’agit de ne pas vouloir apprendre le framework lui-même, de vouloir quelque chose qui semble magique au point de ne pas nécessiter d’apprentissage, ou de vouloir lire la documentation ou non
      J’ai surtout utilisé Vue, et même si l’écosystème SPA est complexe, je ne vois pas très bien quel autre système pourrait gérer des applications client à l’état complexe
    • Il y a aussi une différence dans la manière de penser l’UI
      Le modèle de base de jQuery est centré sur les effets de bord, en sélectionnant des éléments pour les modifier, tandis que React ou Vue.js permettent de créer des composants dont l’état de l’UI est déterminé par les données
      Quand les données changent, l’UI est mise à jour avec un minimum de modifications du DOM, et cette approche rend les widgets d’UI, selon leur emplacement, beaucoup plus lisibles et maintenables
      Les sites web et applications desktop basées sur le web d’aujourd’hui sont bien plus complexes qu’il y a 20 ans ; donc, si l’on ne se contente pas de créer des UI simples, l’innovation côté gestion d’état est importante
    • Pour écrire une application React, il n’est pas nécessaire de savoir comment useState fonctionne en interne, et sa manière de s’appliquer est assez intuitive
      À l’inverse, la bibliothèque proposée semble exiger dès le départ un modèle mental plus complexe
      Comprendre en profondeur les détails d’un framework est certes idéal, mais React a réussi en permettant de créer des applications assez sophistiquées tout en connaissant très peu son modèle interne
    • Angular n’était pas si difficile, et en une semaine environ on pouvait apprendre assez pour construire un site complexe ou soumettre une PR correcte
      Cela tient peut-être au fait que je développe depuis les bêtas de C# et les débuts de HTML/JS/CSS, mais je l’ai compris rapidement
      Nous avons choisi Angular pour remplacer un vieux portail de gestion d’infrastructure critique complexe ; il était stable, rapide, agréable visuellement, et tout le monde était satisfait
      La « courbe d’apprentissage abrupte » semble surtout venir de développeurs arrivés dans le secteur en ne connaissant que JavaScript et un peu de React ; avec davantage d’expérience, on le prend en main tout de suite
    • Si un développeur se demande comment fonctionne useState en interne, il peut arriver en quelques secondes à une réponse logique et correcte
      Ce n’est ni complexe ni magique, et une implémentation minimale façon hooks React tient en quelques centaines de lignes
      Une implémentation basique de useState et runFunctionComponent est plus simple que la plupart des devoirs de troisième semestre en informatique à l’université
      Si c’est cela le seuil de la magie, alors on est entourés de Warlocks niveau 20 capables d’inventer une nouvelle Eldritch Invocation pendant leur petit-déjeuner

  • À mon avis, l’une des raisons pour lesquelles ce débat part dans des directions opposées est que les gens n’optimisent pas pour la même chose
    Si l’on construit le produit cœur d’une startup financée par du capital-risque, qui doit avancer vite et être maintenu en continu, un framework peut être bien adapté
    Mais dans un laboratoire de recherche universitaire, on n’a pas beaucoup d’argent pour maintenir des applications déjà créées, et elles doivent continuer à fonctionner même après que les subventions sont passées à de nouveaux projets
    J’ai presque terminé de réécrire une application Vue en Web Components, car ses dépendances avaient pourri au point de rendre les mises à jour impossibles
    Avant, je passais du temps à réparer l’enfer des dépendances, et cela aurait continué ; après avoir essayé les Web Components, j’ai trouvé ça immédiatement mieux et j’ai basculé
    Les dépendances sont passées d’environ 15 à environ 1 (d3js), et je ne le regrette pas
    Ancienne application https://bam.iobio.io/, nouvelle application https://bam2.iobio.io/

    • J’ai parfois du mal à comprendre cette logique
      Personne ne force à mettre un framework à jour vers la toute dernière version ; il aurait donc été possible de rester sur la version de Vue déjà utilisée
      Sauf raison particulière, il aurait peut-être été acceptable de conserver cette même version jusqu’au bout
      Cela ne veut pas dire que Vue était nécessaire pour ce cas d’usage à l’origine, ni que supprimer les dépendances était un mauvais choix, mais si Vue vous convenait, il ne semble pas y avoir d’obligation de rester sur la dernière version
    • S’il était possible de supprimer les dépendances en ne gardant que d3js, n’aurait-il pas aussi été possible de faire la même chose tout en conservant la dépendance à Vue
      Je me demande si la raison pour laquelle Vue nécessite des dépendances supplémentaires vient du système de build
    • Une fois qu’on y est habitué, je ne pense pas que le développement avec Web Components soit plus lent qu’avec n’importe quel framework
      Je ne comprends donc pas très bien pourquoi l’écosystème VC ne pourrait pas se passer de frameworks
    • J’ai du mal à croire que tous les Web Components soient écrits à la main, et il est difficile d’imaginer qu’il n’y ait absolument aucune dépendance externe

  • J’apprécie le fait que Svelte permette de générer des Web Components via la Custom Elements API
    Comme Svelte se compile en JS/HTML/CSS standard, il est naturel d’en faire des composants réutilisables qui fonctionnent avec n’importe quel framework ou en JS vanilla : https://svelte.dev/docs/custom-elements-api

    • Rich reconnaît lui aussi que ce n’est pas l’objectif prioritaire de Svelte ; il n’est donc pas surprenant que la réalité soit en deçà de la promesse
    • Vue propose aussi cette fonctionnalité : https://vuejs.org/guide/extras/web-components

  • Cela fait des années que je suis les discussions sur les Web Components, mais en tant que développeur full-stack, je ne vois toujours pas bien ce qu’ils peuvent faire pour rendre la vie meilleure
    La plupart des exemples ici se limitaient à injecter des données dans du HTML via des templates, ce qu’on peut déjà faire avec handlebars
    Est-ce que je passe à côté de quelque chose ?

    • Dans le « web », il y a le modèle qui voit le HTML comme un document, et celui qui voit le HTML comme le graphe de scène d’une application plus complexe
      Si l’on utilise le HTML comme document, les Web Components permettent d’y ajouter des interactions temps réel plus sophistiquées
      Un émulateur de terminal connecté à un WebSocket, un sélecteur de date, des éléments de formulaire personnalisés, une carte, un tableau de données, un widget d’onglets, ou les composants personnalisés que fournissait autrefois jquery-ui en sont des exemples
      C’est possible sans Web Components, mais en les transformant en composants personnalisés, le HTML reste beaucoup plus propre et plus proche d’un document
      Ce serait bien d’avoir une bibliothèque cohérente de Web Components, et avec HTMX et les événements envoyés par le serveur, un chat temps réel assez correct semble aussi possible
    • Une isolation native complète est possible
      Le navigateur isole l’ensemble du HTML, du CSS et du JS sans astuces particulières
      J’aime l’idée de pouvoir créer un Web Component, définir clairement ses API JS, HTML et CSS en termes de variables, puis l’insérer dans n’importe quel environnement sans qu’il casse, ou sans devoir créer un labyrinthe de namespaces CSS complexes et de dépendances à des frameworks
    • C’est excellent pour l’amélioration progressive
      Par exemple, un Web Component qui enveloppe un tableau peut ajouter des fonctions comme le filtrage ou le tri par glisser-déposer, et si JS est désactivé ou ne se charge pas, l’utilisateur reçoit quand même le tableau et le contenu de base
      Autrefois, c’était bien mieux que l’écran blanc des frameworks front-end, mais maintenant que le rendu côté serveur est largement disponible, l’avantage est moindre
      L’encapsulation des styles est également appréciable, mais aujourd’hui les bibliothèques d’UI headless et les styles scoped des frameworks sont courants, donc cela paraît moins indispensable qu’il y a dix ans
      En revanche, pour utiliser des slots il faut choisir le Shadow DOM, et le fait de ne pas pouvoir styler ses propres composants réutilisables en ajoutant simplement une feuille de style à la page est agaçant
    • Si les exemples évitent les API dynamiques, c’est probablement parce que cette partie est très laide et comporte beaucoup d’état
      Quand une démo montre 200 lignes de manipulation manuelle du DOM, il est difficile de présenter les Web Components comme l’avenir
    • Les Web Components permettent d’utiliser, dans son propre framework, des composants d’UI créés avec un autre framework
      C’est tout, et pour la plupart des autres usages, ils sont assez mauvais
      Ils permettent aussi de distribuer un composant d’UI qui fonctionne avec tous les frameworks, au lieu d’en maintenir 7 versions

  • Le pire aspect des Web Components et du Shadow DOM, c’est qu’ils peuvent empêcher les extensions de navigateur de fonctionner correctement, voire de fonctionner tout court
    Les éditeurs de navigateurs ne se pressent pas non plus pour corriger la situation

    • La configurabilité de l’agent utilisateur est la killer feature du web

  • À mon avis, l’une des plus grandes « erreurs » des Web Components a été de les associer, dans l’esprit des gens, au Shadow DOM
    Dans le développement d’applications, si l’on s’en tient au DOM vivant, les Web Components deviennent une option très légère et facile
    On peut continuer à utiliser les outils CSS que l’on veut, comme bootstrap ou tailwind, tout en obtenant une excellente encapsulation fonctionnelle pour un coût presque nul, surtout avec quelque chose comme lit-html comme moteur de rendu
    Les équipes ont généralement trouvé le travail avec les Web Components natifs rafraîchissant, et les développeurs venus du monde des frameworks, après environ une semaine d’adaptation, ne voulaient plus revenir en arrière
    Avec de simples propriétés de classe et des appels manuels à la fonction de rendu dans set(), on obtient les avantages de la réactivité sans la lourdeur d’un framework
    Le problème, c’est qu’il existe peu de ressources qui montrent comment commencer en « mode facile »
    La plupart des ressources d’introduction poussent directement vers des techniques pénibles comme le Shadow DOM et les CSS parts, davantage destinées aux auteurs de bibliothèques qu’aux développeurs d’applications
    Il faudrait sans doute écrire un guide du type « The Good Parts » pour montrer comment se simplifier la vie avec les Web Components

    • J’utilise le Shadow DOM tous les jours, mais c’est généralement aussi la partie qui déroute le plus les gens dans les Web Components. Probablement parce qu’ils n’en ont pas besoin
      Comme alternative, il existe les « HTML web components », qui n’utilisent que le DOM vivant, privilégient le rendu côté serveur et conviennent bien comme remplacement du « saupoudrage jQuery » : https://adactio.com/journal/20618
      Il y a aussi « Shadow gristle », qui utilise le Shadow DOM aussi peu que possible et laisse dans le DOM vivant ce qui nécessite du style ou de la composition : https://glazkov.com/2023/03/02/shadow-gristle/
    • Si vous écrivez là-dessus, j’aimerais le lire. L’entendre m’irait aussi
      Cette technologie semble être à la fois une bénédiction et une malédiction selon la manière dont on l’utilise, donc je rassemble des ressources et des commentaires à ce sujet
    • Dans mon précédent poste, nous utilisions la même stack, c’est-à-dire des WC sans Shadow DOM et seulement lit-html, et c’était vraiment très bien
      Le meilleur, c’est qu’on ne tombe pas en enfer des dépendances toutes les deux semaines
    • C’est exactement ça. Ce qui manque aujourd’hui, ce sont des slots pour le light DOM

  • L’interopérabilité est le plus grand avantage du point de vue de l’utilisateur, mais j’ai l’impression qu’on sous-estime le coût en performances que cela implique : chaque composant utilisé peut embarquer un runtime inutile
    Avec les Web Components, la méthode recommandée consiste à utiliser un framework comme Lit ; avec le temps, de nouveaux frameworks apparaissent, des composants restent liés à d’anciennes versions, et ce coût s’accumule
    Je ne recommanderais à personne d’aller vers une page contenant plusieurs bibliothèques en double, et si cela fait partie des bonnes pratiques, ce n’est pas bon à long terme
    Après avoir lu pendant des années des articles, des publications sur les réseaux sociaux et vu des vidéos de partisans des Web Components — alors que je devrais précisément faire partie du public visé — j’y vois, en plus de la taxe d’interopérabilité, une accumulation d’inconvénients que les frameworks dominants n’ont pas
    Au sein de chaque écosystème de framework, l’interopérabilité fonctionne bien, et les mêmes dynamiques qui poussent les développeurs à la rechercher les amènent à se regrouper autour d’un petit nombre de frameworks dominants
    À mon sens, les Web Components ne rattrapent pas leur retard sur le plan technique et ajoutent beaucoup de complexité à la plateforme web pour une conception datant du début des années 2010 : https://x.com/Rich_Harris/status/1840116730716119356

    • Je l’ai abordé dans un autre article, mais à grands traits, toutes les applications web ne sont pas sensibles aux performances à chaque kB ajouté. L’e-commerce l’est, mais les outils de productivité ne le sont généralement pas
      Il existe aussi beaucoup de frameworks à petit runtime, comme Svelte, et même si l’idée n’est pas d’en mettre 100 sur une même page, 5 ou 6 me semblent acceptables
      Ce n’est pas l’idéal, mais cela peut aider pour des migrations progressives ou des micro-frontends
      À noter que React 17 a lui aussi introduit la possibilité d’avoir plusieurs versions de React sur une même page : https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/, https://bundlephobia.com/package/svelte@4.2.19, https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
    • C’est vrai, mais quand on regarde la plupart des applications web créées aujourd’hui, le problème des bibliothèques multiples ressemble presque à une erreur d’arrondi
      React et react-dom dépassent ensemble 100 Ko, tandis que Svelte et Lit se comptent en quelques Ko
      Il faudrait empiler pas mal de frameworks pour approcher le niveau de lourdeur que les gens utilisent tous les jours sans y penser
    • Plus largement, les Web Components doivent convaincre les auteurs de frameworks
      Les signaux que j’ai vus de façon constante jusqu’ici ne sont pas bons ; cette communauté est sur X, et les Web Components ne résolvent pas leurs problèmes et ne sont pas bien utilisés même dans le meilleur des cas
      J’espère qu’ils réussiront à les convaincre, mais dans l’ensemble, ces personnes ont plutôt tendance à dire que les Web Components ont échoué et ont été globalement mauvais pour le web
    • Honnêtement, je ne comprends pas vraiment cet argument
      La plupart des runtimes sont assez petits, et le fait que deux runtimes tournent en même temps n’implique pas forcément un gros surcoût en performances
      Tous les frameworks web modernes sont réactifs : s’il n’y a rien à traiter, ils ne font rien
      Si une partie d’une page est faite en React, une autre en Lit et une autre encore en Svelte, je vois mal pourquoi l’expérience utilisateur ou la consommation de batterie seraient sensiblement pires que sur une page avec un seul framework
      Le tweet cité porte sur la question de savoir si les Web Components sont des « primitives utiles pour créer des frameworks », et même les fans qui les ont vraiment utilisés ne diraient probablement pas, pour la plupart, que c’est le cas
      Les Web Components sont un mécanisme de distribution, et si l’unique alternative consiste à créer 7 fois la même bibliothèque pour React, Preact, Svelte, Solid, Vue et du JS vanilla, c’est épouvantable

  • J’aime les Web Components, et je suis optimiste quant à leur capacité à nous sortir de l’enfer frontend actuel que nous avons nous-mêmes créé
    J’ai récemment fait une courte présentation sur l’avenir du frontend, et d’autres personnes semblaient elles aussi espérer une voie de sortie
    J’ai créé une table de données pour une interface graphique de base de données, et même avec des centaines de milliers de lignes chargées, le défilement reste très fluide
    Je compte aussi publier bientôt une bibliothèque de Web Components ; c’est encore jeune et brut, mais j’aimerais que davantage de personnes y jettent un œil : www.astra-ui.com

    • À mon avis, la seule façon de sortir de l’enfer frontend actuel est l’arrivée des imports côté client : https://github.com/whatwg/html/issues/2791
    • J’ai regardé la documentation, et le rendu est très étrange dans Safari 18.0 sur iPhone 15 Pro Max
      Il vaudrait mieux repenser la barre latérale pour le responsive design sur petits écrans, et utiliser max-width plutôt que width sur le body
      Le bouton « explore components » en bas de la page d’accueil ne semble mener nulle part
      Vous dites qu’il faut « apprendre d’implémentations de composants bien structurées et accessibles », mais je n’ai pas trouvé de lien vers l’implémentation dans la documentation
      Vous dites aussi qu’il n’y a « aucune dépendance à gérer ou à mettre à jour », mais astra-ui elle-même me semble être une dépendance, et il y a aussi un journal des changements : https://www.astra-ui.com/changes/
      Vous dites également offrir un « contrôle total du code et du styling », mais je ne comprends pas comment un contrôle total est possible tout en dépendant d’une implémentation fournie par la bibliothèque
      Je suis curieux de savoir pourquoi vous avez décidé de publier cette bibliothèque. Mettre en open source un logiciel interne peut être utile quand une entreprise a un objectif précis, mais le plus souvent, cela devient vite une dépense de temps sans contrepartie
      Une bibliothèque de composants doit se battre pour être adoptée par l’écosystème ; sinon, elle n’a pas vraiment de public et il y a peu de raisons de la publier
    • Pourquoi utiliser ceci plutôt que quelque chose comme des composants Vue ?
    • Pourquoi les Web Components ne se sont-ils pas encore imposés, ou ne sont-ils pas plus largement utilisés ?
      Cela ressemble à une excellente solution
    • J’ai réécrit le code publicitaire frontend de l’entreprise en Web Components

  • Il y a quelques mois, dans mon nouveau poste, j’ai hérité d’une codebase JS d’environ 250 000 lignes
    Une énorme classe et quelques sous-classes faisaient tout, et certains fichiers faisaient même 30 000 lignes
    Sans framework ni réactivité, cliquer sur un bouton obligeait à tout mettre à jour manuellement à l’écran via des event listeners
    C’était le genre de code qu’on aurait dit écrit par quelqu’un enfermé pendant des années dans une cellule de monastère avec seulement un livre de JavaScript de base
    Comme il fallait y aller progressivement, j’ai commencé à refactorer avec des Web Components, et cela a beaucoup aidé ; jusqu’ici, on a supprimé 50 000 lignes
    Mais le véritable objectif était d’apprendre tout ce que faisait le code existant avant de le réécrire

    • La clé pour comprendre une codebase ancienne et obscure, c’est de refactorer petit morceau par petit morceau
      La réécrire en Web Components est une façon d’atteindre cet objectif, et le fait de ne pas avoir tout jeté pour repartir de zéro est une bonne chose
      Cela dit, si l’on avance jusqu’à un certain point puis qu’on passe à un autre projet, il y a un risque que la personne suivante arrive et commence à refactorer à sa manière, créant ainsi une codebase obscure en trois styles différents
      Mais cela reste mieux que de réécrire 250 000 lignes d’un coup

  • Un point que j’ai apprécié avec les Web Components, c’est qu’au moins en théorie, ils peuvent fonctionner même avec JavaScript désactivé
    Je l’ai fait quelques fois pour de l’amélioration progressive
    Dans l’ensemble, je suis d’accord avec Nolan. Les Web Components ont suffisamment d’aspérités pour qu’il soit difficile de les voir conquérir le monde dans leur état actuel, mais ils sont très bien pour certains cas d’usage
    En revanche, je ne comprends pas trop l’idée selon laquelle ils ne s’accordent pas bien avec le rendu côté serveur ; je l’ai fait sans problème

    • Je suis curieux de savoir pourquoi vous dites cela
      D’après ce que j’ai vu, il semble qu’il faille JavaScript pour enregistrer un template sur une balise donnée : https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
    • Je ne vois pas comment cela est censé fonctionner
      Avec ReactJS, on peut rendre des composants ou des templates côté serveur, et je trouve que JSX est un assez bon langage de templates
      D’après ce que je comprends, les Web Components n’ont pas de bon langage de templates intégré, donc il faut en apporter un soi-même
      Je ne connais pas de mécanisme standard permettant de prendre un fragment de composant JS associé à une balise et de rendre le HTML nécessaire sans exécuter JS
    • Je suis l’auteur de l’article. Je l’ai abordé dans un autre billet, mais fondamentalement, les avantages d’interopérabilité que l’on obtient côté client ne sont pas encore présents côté serveur
      Si, à l’avenir, on peut rendre côté serveur trois frameworks de Web Components différents, les composer entre eux et les hydrater proprement, alors on pourra considérer le problème comme résolu : https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/