Les composants Web ont-ils un avenir si personne ne les développe ?

Par Nolan Lawson

À la suite de mon précédent article sur « l’utilisation de la plateforme », j’ai été surpris de constater que les commentaires sur Hacker News et Lobsters avaient tendance à s’orienter vers les composants Web. Cela m’a surpris car je n’avais absolument pas mentionné les composants Web dans cet article.

J’ai été moins surpris lorsque j’ai fait quelques recherches et découvert que le mantra « utiliser la plateforme » avait été popularisé pour la première fois par Polymer, qui était l’une des premières tentatives de Google pour créer un framework JavaScript basé sur les composants Web. En 2018, ils l’ont même qualifié de « notre devise » ! Cela explique donc pourquoi beaucoup de gens semblent avoir ancré dans leur esprit que « utiliser la plateforme » signifie « utiliser les composants Web ».

Or, l’une des raisons pour lesquelles je n’ai pas mentionné les composants Web dans cet article est que, selon moi, ils ne constituent en réalité pas un très bon exemple de « use the platform » (quelle que soit l’origine de cette devise). Je me suis plutôt appuyé sur des exemples de fonctionnalités HTML et CSS qui ont tendance à être plus performantes, plus accessibles et qui nécessitent bien moins de lignes de code que leurs équivalents en JavaScript. Cela tient en grande partie aux progrès réalisés ces dernières années par les éditeurs de navigateurs et les organismes de normalisation (par exemple, le groupe de travail CSS et le projet Open UI).

Modern Web Guidance (Guide du Web moderne)

Les composants Web m’ont toutefois de nouveau traversé l’esprit après qu’un commentaire sur Mastodon m’a orienté vers les « Modern Web Guidance » de Google. Je ne connaissais pas cet outil avant de rédiger cet article, mais il s’agit essentiellement d’un ensemble de compétences que l’on peut transmettre à un développeur pour l’inciter à utiliser davantage les fonctionnalités modernes des navigateurs. En substance, c’est le principe « utilisez la plateforme » pour les développeurs (ou du moins la vision qu’en a l’équipe Chrome).

En regardant la démo, j’ai toutefois été frappé par la difficulté à cerner la place exacte des composants Web dans ce tableau. Dans la présentation, Phil Walton montre comment utiliser les « Modern Web Guidance » pour créer une application Web qui ressemble davantage à une application native en termes de fluidité de suivi du doigt lorsque l’on touche l’écran, grâce à des fonctionnalités telles que les points d’ancrage de défilement CSS et les animations pilotées par le défilement.

Mais à aucun moment de la démo on ne voit réellement le code – il s’agit là de « vibe-coding » à l’état pur. Et tandis que je regardais, j’ai eu du mal à imaginer un seul endroit où, si je devais créer moi-même « Modern Web Guidance », j’aurais inséré des instructions pour dire à l’agent : « Hé, tu devrais utiliser des éléments personnalisés, le Shadow DOM ou d’autres primitives de composants Web ici, car cela améliorera l’expérience de l’utilisateur final. » Et cela s’explique par le fait que les composants Web ne peuvent en réalité rien faire pour améliorer l’expérience de l’utilisateur final. (On pourrait certes affirmer que le Shadow DOM améliore les performances CSS, mais j’ai effectué des tests de performance à outrance, et on peut obtenir pratiquement le même gain de performance avec la délimitation de portée CSS à la compilation, ce que de nombreux frameworks et outils comme Svelte, Vue et Tailwind font déjà.)

J’ai donc examiné le code source de « Modern Web Guidance », et mon intuition s’est confirmée : les composants Web semblent avoir été ajoutés après coup. Au cours des six premiers mois d’existence du projet, les composants Web n’étaient pratiquement jamais mentionnés. Cela n’a changé qu’il y a trois semaines, lorsqu’un seul commit a été intégré, fournissant principalement des recommandations à l’intention de ceux qui utilisent déjà des composants Web, sur des sujets tels que l’accessibilité, le pré-rendu, la mise en forme, etc. Mais nulle part dans le « Modern Web Guidance » il n’est fortement recommandé à l’agent d’utiliser les composants Web — en fait, il y a toute une section intitulée « Déterminez si vous avez réellement besoin d’un élément personnalisé », qui semble parfois carrément décourageante. Tel qu’il est rédigé, si l’on présente le « Modern Web Guidance » à un agent développant un tout nouveau produit, il me semble peu probable qu’il choisisse d’utiliser les composants Web.

Pour être honnête, il existe une exception : une ligne destinée aux auteurs d’extensions Chrome recommande d’utiliser le Shadow DOM pour les interfaces utilisateur complexes injectées dans une page. Cela me semble tout à fait raisonnable, même s’il s’agit d’un cas d’utilisation assez restreint. Une autre ligne suggère d’utiliser les composants Web pour les « systèmes de conception, les widgets intégrables et les interfaces utilisateur autonomes », mais cela reste également assez restreint, et me semble n’être qu’un léger clin d’œil dans le contexte plus large de « déterminez si vous avez réellement besoin d’un élément personnalisé ».

Les composants Web à la croisée des chemins

Alors, quelle place occupent les composants Web dans ce nouveau monde du codage basé sur l’IA ? Je ne vais pas ressasser tous mes arguments concernant les forces et les faiblesses des composants Web ; je l’ai déjà fait de manière assez détaillée. Je souhaite plutôt aborder ce qui change lorsque les développeurs n’écrivent plus le code (ou, de plus en plus souvent, ne le lisent même plus).

Cette section m’a été pénible à rédiger, car j’ai passé des années à travailler sur un framework basé sur les composants Web (LWC), à participer au Web Components Community Group et au groupe Accessibility Object Model, et à défendre les composants Web sur mon blog, dans des podcasts, etc. Et pourtant, je dois reconnaître que leur proposition de valeur fondamentale a été sérieusement affaiblie par le codage « agentique ».

En résumé, les composants Web ont été conçus pour un monde où l’on tapait le code HTML à la main, où le code était rare et où la réutilisation était donc une nécessité économique. Rien de tout cela n’est plus vrai aujourd’hui, ou du moins ces réalités sont de moins en moins d’actualité et s’estompent de jour en jour. Ainsi, l’argument de vente selon lequel « en développant selon une norme commune, vos composants seront plus faciles à adopter et à réutiliser » perd de son attrait, car de plus en plus de développeurs créent des interfaces utilisateur à partir de zéro, sur une base technique largement invisible.

Cela ne fait pas que ruiner la proposition de valeur des composants Web : cela affecte également les frameworks JavaScript qui les ont inspirés. Je lis de plus en plus souvent que des équipes réécrivent l’intégralité de leur front-end pour passer d’un framework à un autre, en se basant principalement sur l’idée que « c’est probablement mieux pour les agents ». Indépendamment des mérites de ces réécritures (qui, selon moi, devraient reposer davantage sur des preuves tangibles, du type « cela utilise moins de tokens » ou « l’expérience utilisateur final est plus rapide »), nous en verrons probablement davantage à l’avenir. Et si les gens commencent à considérer la couche du framework comme jetable, il me semble peu probable qu’ils accordent beaucoup de valeur à la couche située juste en dessous.

Comme je l’ai expliqué dans un article de 2023, les bibliothèques de composants étaient déjà en train de passer d’un modèle « tout compris » à une approche plus « DIY ». L’apothéose de cette tendance est shadcdn, qui peut sembler être une machine à cracher des tonnes de code standard, mais dans un certain sens, c’est justement le but. Plutôt que de faire de votre interaction avec un système de composants une API rigide qui résiste à vos tentatives de personnalisation ou d’ajustement, vous importez les éléments individuels, puis vous les réorganisez à votre guise. Cette évolution était déjà en marche avant l’avènement du codage par IA, et aujourd’hui, avec les grands modèles de langage (LLM), ces « quantités astronomiques de code standard » constituent un avantage plutôt qu’un inconvénient. Et rien de tout cela ne met en valeur les atouts du shadow DOM, des attributs reflétés ou d’autres piliers des composants Web.

Sauver les composants Web

Il y a deux arguments (un peu faibles) que je peux avancer en faveur des composants Web dans ce nouveau monde du codage par IA.

Le premier concerne ce qu’on appelle les micro-frontends, c’est-à-dire l’idée de diviser une interface utilisateur volumineuse en plusieurs sections pouvant être développées par différentes équipes sans se marcher sur les pieds. Les composants Web ont été explicitement conçus pour ce scénario : éviter les « tirs amis » (pour reprendre l’expression mémorable de Brian Kardell). Dans un monde d’agents, ce type de « sandboxing » est en réalité une technique bien connue, car on cherche généralement à isoler les agents dans des limites strictes pour éviter qu’ils ne se bousculent les uns les autres. En d’autres termes, les composants Web pourraient théoriquement vous permettre d’avoir plusieurs essaims d’agents travaillant sur des parties distinctes de l’interface utilisateur sans que leurs CSS, leurs événements ou leurs variables globales n’entrent en conflit les uns avec les autres.

L’argument contraire évident est que le Web dispose déjà d’une excellente primitive de sandboxing : les iframes. Les iframes offrent des limites encore plus strictes que les composants Web : non seulement les composants sont isolés les uns des autres, mais ils évoluent également dans des environnements JavaScript distincts, avec postMessage comme seul canal de communication. Il existe plusieurs compromis sur lesquels je ne souhaite pas m’étendre ici (communication synchrone vs asynchrone, utilisation de la mémoire, perméabilité du shadow DOM fermé vs ouvert), mais je pense sincèrement que les composants Web ont leur place dans ce débat. (On pourrait d’ailleurs faire valoir que les « systèmes de conception et interfaces utilisateur autonomes » mentionnés dans les Modern Web Guidance constituent également des exemples de scénarios de type micro-frontend où les composants Web peuvent s’illustrer.)

Le deuxième argument est que la réutilisation reste importante, même lorsque la réécriture n’est qu’à un simple ordre de commande. Par exemple, je continue de croire que mon élément <emoji-picker> est un excellent exemple de composant web efficace : il n’y a aucune raison de le recréer dans React, Vue, Svelte et une douzaine d’autres frameworks, même si l’on pourrait le faire très facilement avec un LLM de nos jours. Il s’agit d’un composant autonome, exclusivement côté client, dont la majeure partie de la complexité réside dans la gestion des données d’émojis, d’IndexedDB, etc., et qui ne nécessite que très peu d’interactions avec un framework pour gérer son rendu ou son cycle de vie. Le regrouper sous forme de composant web et permettre aux développeurs de l’intégrer dans la couche de framework de leur choix (ou de n’en utiliser aucune) reste donc un modèle de distribution judicieux.

S’opposer à l’utilisation des composants Web en tant que « lingua franca » de la réutilisation revient (à mes yeux) à affirmer que tout partage de code, voire l’open source en général, est une perte de temps à l’ère des agents. Mon collègue André Staltz a démontré que c’est clairement faux : au contraire, le codage par IA augmente la quantité de code partagé, il ne la réduit pas. Même si l’on peut recréer quelque chose à l’aide d’agents, cela ne signifie pas pour autant qu’il vaille la peine de dépenser des jetons pour le faire. (Même si je m’interroge encore sur les projets de plus petite envergure.)

L’argument contraire le plus convaincant est que les développeurs disposent déjà d’une excellente couche de réutilisation des composants : React. Je n’y crois pas pour autant, car je ne pense pas que React soit le dernier framework JavaScript dont le monde aura jamais besoin. Des tests de performances tels que le « js-framework-benchmark » et le « isomorphic SSR benchmark » continuent obstinément de plaider contre l’adoption de React : il s’avère que le DOM virtuel reste une pure surcharge. React pourrait certes se réinventer pour l’ère des agents, mais j’imagine que cela pourrait entraîner des problèmes de compatibilité qui plaideraient encore plus fortement en faveur de l’adoption des composants Web, ne serait-ce que pour sortir du cercle vicieux des mises à jour.

Je pense néanmoins que l’argument le plus convaincant de tous est que ni les composants Web, ni React, ni aucun autre framework n’ont vraiment d’importance, sauf peut-être en tant que note de bas de page dans le fichier AGENTS.md de quelqu’un ou en tant que...