- Pour traiter les démos interactives d’un tutoriel sur les CRDT comme du contenu durable, les Web Components, que l’on peut insérer directement dans du HTML, conviennent mieux qu’un framework particulier
- Les composants MDX d’Astro apportent des facilités comme le build, le scope CSS ou TypeScript, mais si on les sort d’Astro, ils peuvent entraîner un coût de réécriture
- Les Web Components permettent d’insérer dans Markdown des balises personnalisées comme
<pixelart-demo></pixelart-demo> et, en chargeant simplement un script, de les réutiliser par balise n’importe où dans une page
- Les frameworks et TypeScript sont aussi des dépendances : les changements de versions, d’API et de compatibilité s’accumulent, et plus un code resté longtemps sans maintenance a de dépendances, plus il est difficile à remettre en état
- La plateforme web est suffisamment stable pour que de vieux sites fonctionnent encore dans les navigateurs modernes ; pour des travaux qui doivent rester accessibles dans 5, 10 ou 20 ans, une approche fondée sur les standards est préférable
Préserver les démos interactives comme du contenu
- La série de billets sur les CRDT avait besoin de démos interactives pour illustrer les concepts, avec comme exemple un éditeur collaboratif de pixel art
- Le critère de choix technique était que, même si la démo était construite en HTML, CSS et JS, elle se rapprochait davantage du contenu intégré dans un article de blog
- Plutôt comme un élément inséré dans un article, à la manière d’une image ou d’une vidéo
- Elle devait pouvoir être déplacée partout où du HTML peut être rendu
- En 2023, le site était construit avec Astro, mais auparavant il était passé par un générateur de site statique maison, Hugo, un CMS PHP personnalisé, Tumblr, Movable Type, WordPress, etc.
- Même si Astro est aujourd’hui apprécié, il est difficile de supposer que le site web fonctionnera éternellement sur Astro
Comment Markdown réduit le coût des migrations
- Si les migrations récentes ont été faciles, c’est parce que le contenu était conservé sous forme de fichiers texte Markdown
- Cela réduit les tâches souvent nécessaires lors d’un changement de système
- Exporter depuis un système et importer dans un autre
- Corriger les problèmes de compatibilité
- Supprimer les éléments pour lesquels aucune méthode de migration n’a été trouvée
- Quand on place des fichiers Markdown dans un nouveau site web, la plupart fonctionnent tels quels
- Markdown permet d’écrire directement du HTML ; si des diagrammes interactifs complexes peuvent être représentés avec des balises HTML ordinaires, ils deviennent portables comme le reste du contenu
Les facilités d’Astro MDX et leurs limites de portabilité
- L’intégration MDX d’Astro permet de rendre des composants Astro à l’intérieur de Markdown
- Les composants Astro profitent de nombreuses facilités du système de build
- Écrire du HTML, du CSS et du JS dans un seul fichier
- Gérer le scope des sélecteurs CSS
- Compiler TypeScript
- Rendre du markup conditionnel
- Effectuer d’autres optimisations
- Le problème est que toutes ces facilités ne fonctionnent de manière fiable qu’à l’intérieur d’Astro
- En migrant vers un autre générateur de site, il peut être nécessaire de réécrire les composants
- Il peut falloir séparer le HTML, le CSS et le JS
- Une nouvelle configuration de build peut être nécessaire
- Il peut falloir trouver une nouvelle méthode de scoping des styles
- Ainsi, même si les fonctionnalités propres à Astro sont pratiques, elles ne constituent pas un bon choix pour des démos qui doivent être conservées sur le long terme
Ce que les Web Components résolvent
- Les Web Components sont un ensemble de technologies web standard permettant de créer des éléments HTML réutilisables
- Leur utilisation consiste à écrire une classe d’élément personnalisé, à enregistrer un nom de balise, puis à utiliser cette balise dans le markup
- La démo de pixel art est intégrée dans Markdown avec seulement le HTML suivant
<pixelart-demo></pixelart-demo>
- Aucun réglage spécial n’est nécessaire, ni aucune procédure consistant à placer d’abord un élément particulier puis à appeler une fonction
- Le fichier JS doit être conservé et relié avec une balise
<script>, mais cela revient au même besoin que pour les autres médias : référencer un média depuis un contenu textuel
- Une fois le script chargé, le nom de balise est enregistré ; même si le markup existe déjà avant l’exécution du JavaScript, il fonctionne partout dans la page
Fichier unique et Shadow DOM
- Les Web Components peuvent encapsuler HTML, CSS et JS dans un seul fichier, sans nécessiter de système de build séparé
- Quand le code du composant est regroupé au même endroit, la charge mentale diminue ; les composants à fichier unique ont aussi des avantages en termes d’expérience de développement
- Le composant d’exemple
<pixelart-demo> hérite de HTMLElement, attache un Shadow DOM avec attachShadow({ mode: "closed" }), puis rend son markup et ses styles internes
- L’instruction
import PixelEditor from "./PixelEditor.js"; en haut du fichier est un import de module ES, elle ne dépend donc d’aucun système de build séparé
- Si les fichiers associés sont conservés ensemble, le navigateur gère les modules
- Le Shadow DOM isole le composant de la page environnante
- Cela peut sembler maladroit lorsqu’il faut partager les styles avec l’ensemble de l’application
- C’est adapté lorsqu’une isolation complète est nécessaire
- Comme une image ou une vidéo, le composant peut conserver la même apparence et le même comportement quel que soit l’endroit où il est utilisé
Recevoir une configuration externe par attributs
- Les Web Components peuvent exposer des attributs (attributes) configurables depuis l’extérieur
- Les attributs s’utilisent comme des attributs natifs
- Les variables CSS font partie des rares valeurs qui peuvent entrer dans le Shadow DOM ; l’exemple de range slider définit donc la couleur d’accent comme suit
<range-slider style="--accent: #0085F2"></range-slider>
- La démo de pixel art modifie la résolution à 20 par attribut et affiche les informations de debug de chaque pixel
<pixelart-demo debug resolution="20"></pixelart-demo>
- Les appels
getAttribute et hasAttribute de la classe du composant servent à lire ces valeurs d’attribut
- C’était utile pour réutiliser le même composant à plusieurs étapes du tutoriel, en activant certaines fonctionnalités selon l’étape en cours
Les frameworks et TypeScript sont aussi des dépendances
- Il existe des outils comme Lit, Stencil ou Svelte qui compilent vers des Web Components, mais un framework reste au final une dépendance
- Le compromis le plus préoccupant ici était le coût de maintenance à long terme
- TypeScript ne fait pas non plus partie des fondations natives du web : c’est donc une dépendance
- Les 15 dernières versions de TypeScript ont comporté des breaking changes ; beaucoup de ces changements apportaient de nouvelles fonctionnalités utiles, mais ils exigeaient des modifications du code
- Utiliser des dépendances implique de suivre les nouvelles versions, les changements d’API et les coûts de vérification de compatibilité
- Comme ce code n’est pas destiné à être retouché régulièrement, il serait indésirable de devoir absorber plusieurs années de mises à jour d’un seul coup lorsqu’une modification deviendra vraiment nécessaire
Expérience de restauration d’anciens sites et stabilité de la plateforme web
- En construisant un musée en ligne, du vieux code stocké sur un ordinateur portable qui n’avait pas été allumé depuis 10 ans a été récupéré, et plus un site web avait de dépendances, plus il était difficile à ressusciter
- En environ 20 ans de création web, l’auteur a vu la naissance, l’essor et le déclin de jQuery, ainsi que la création de Node.js puis le fork io.js et sa fusion
- Backbone a rapidement été remplacé par AngularJS, AngularJS par React, et React lui-même a connu plusieurs façons d’écrire des composants sur une période environ deux fois plus courte
- Pendant que l’écosystème changeait, la plateforme web elle-même a évolué prudemment pour ne pas casser les sites existants et est restée assez stable
- De vieux sites fonctionnent encore dans les navigateurs modernes
- Si l’on veut un travail encore accessible dans 5, 10 ou 20 ans, mieux vaut réduire les dépendances que l’on ne contrôle pas et s’en tenir aux standards du web, qui ont plus de chances de ne pas casser
- Malgré ses défauts, le web devient une plateforme de calcul résiliente, portable et tournée vers l’avenir lorsqu’on crée en tenant compte de ses caractéristiques, sans couche intermédiaire
1 commentaires
Avis sur Hacker News
htmx n’est pas un framework mais une bibliothèque, et puisque l’article le mentionne, je voudrais répondre à quelques points
D’abord, l’article ne traite pas du problème de la synchronisation entre le serveur et l’état, alors que htmx se concentre précisément sur ce problème via l’échange d’hypermédia. De ce point de vue, htmx et les Web Components sont donc orthogonaux
Les dépendances impliquent de nouvelles versions, des changements d’API et un coût de maintien de compatibilité, donc htmx n’a aucune dépendance et accorde une très grande importance à la rétrocompatibilité. Par exemple, il est compatible avec IE11, et intercooler.js, qui correspond en quelque sorte à htmx 1.0, est sorti en 2013 avec une seule dépendance à jQuery, mais il est toujours pris en charge
Beaucoup de bibliothèques JavaScript ont une culture des réécritures d’API et des mises à niveau difficiles, mais htmx n’est explicitement pas dans ce cas et ne devrait pas être mis dans le même sac. Le seul changement cassant de htmx 2.0 sera probablement l’abandon du support d’IE
Les Web Components dureront probablement plus longtemps que htmx puisqu’ils font partie du navigateur, mais autant que possible, htmx restera à l’avenir très stable et évoluera peu. L’API va fondamentalement dans la bonne direction, et je ne pense pas qu’il faille tout réécrire pour des raisons de pureté ou de style
Surtout, htmx répond à une autre question que les Web Components, à savoir comment synchroniser le serveur et l’état
Avec un WebComponent, on peut s’accrocher au cycle de vie d’éléments DOM modifiés de l’extérieur, comme avec morphdom de Htmx. Si les attributs changent, il faut en informer le composant React, et si un nœud est retiré du DOM, il faut signaler à React d’exécuter sa procédure de nettoyage. Sans les WebComponents, je pense qu’il aurait été difficile de faire cela proprement et efficacement
Au final, nous avons pu rester sur l’approche Htmx, qui consiste à garder tout l’état de la logique métier sur le serveur et seulement une petite partie conservatrice côté client, comme l’élément actuellement focalisé ou le texte en cours de saisie. Plus on va dans cette direction, plus il y a moins de bugs et de conditions de concurrence, et l’expérience utilisateur s’améliore nettement, donc cela vaut l’effort
https://x.com/jlazaroff/status/1717176726248108469
https://htmx.org/essays/hypermedia-friendly-scripting/
Le fait que seuls les formulaires puissent faire des POST, et que la seule manière de traiter une réponse soit de réécrire la page entière, semble être une limitation arbitrairement restrictive. Si htmx devenait une sorte de HTML6, il survivrait à tous les frameworks JavaScript
Je suis un ingénieur surtout orienté back-end, donc la plupart des bibliothèques JS que j’utilise ensuite entraînent une lourde charge de maintenance et des changements majeurs d’API fréquents. Je pense essayer htmx sur un projet personnel
Les templates côté serveur qui génèrent des fragments HTML devraient aussi devenir moins complexes
htmx en lui-même est vraiment un concept très convaincant, mais j’aimerais qu’il y ait une communauté plus large. C’est un problème de l’œuf et de la poule, mais par rapport aux autres frameworks web, il y a peu de ressources comme des billets de blog ou des vidéos. Par exemple, il est difficile de trouver même les bases pour intégrer l’authentification Auth0 dans une application htmx
non.io a été entièrement écrit en Web Components purs, et c’est une SPA complète. En allant au-delà de simples composants de blog imbriqués, quelques enseignements en sont ressortis
La gestion d’état reste toujours sans vraie réponse. Sans framework wrapper, il faut faire soi-même une grande partie du travail. L’un des points forts de React, c’est que la gestion d’état est globalement résolue, avec des patterns et des attentes déjà établis. Avec les Web Components, c’est un peu le Far West, et comme on ne peut pas passer d’objets complexes via les attributs comme avec JSX, on se retrouve à mélanger attributs, événements et appels directs à des fonctions de classe
Les performances non plus n’ont pas apporté un gain aussi important qu’espéré. Pour de petits éléments atomiques, comme des icônes par exemple, quand il y en a des centaines sur une page, le coût de création des instances finit par dépasser la valeur apportée, donc cela a été abandonné dans Web Components. Il a été assez décevant de constater que les éléments statiques ne valent pas vraiment la peine d’être écrits en Web Components, même si cela améliore la lisibilité du code
Il y a quand même des aspects vraiment appréciables. Comme l’auteur le dit, il est très facile d’ajouter des composants à une nouvelle page, quel que soit le framework utilisé. Si c’est construit en Web Components, cela peut vraiment être utilisé n’importe où. Lors de la création de sites annexes comme la documentation API de nonio, il a été agréable de pouvoir piocher les composants voulus, même avec une stack différente. S’il faut embarquer un composant, il suffit de charger le JS et d’ajouter le HTML
L’encapsulation des styles via le shadow root est également très appréciable. C’est rassurant de ne pas avoir à se demander si l’on va casser le style d’un composant en travaillant sur une page. Cela réduit les allers-retours à deviner puis vérifier si l’on va écraser les styles d’autres éléments, et diminue aussi le besoin d’un framework de tests de différences visuelles destiné à garantir cela
La petite taille du bundle est aussi un bon point. Il n’y a ni bibliothèque ni chargement supplémentaire, tout est intégré. Et comme on peut facilement sélectionner uniquement les composants nécessaires, il est très simple de garder un bundle léger
Les composants source de nonio sont ici : https://github.com/jjcm/nonio-frontend/tree/master/component...
Et côté gestion d’état, rien n’empêche du tout de brancher la solution de gestion d’état de son choix. Si l’objectif est de minimiser les dépendances, j’ai aussi vu pas mal de solutions qui utilisent le modèle d’événements intégré du navigateur
Enfin, écrire une application entière en Web Components purs me paraît personnellement être une idée assez extrême. Avec 5 KB, Lit offre une bien meilleure expérience développeur : https://lit.dev
Ces frameworks ont tendance à gagner en performances en regroupant les manipulations du DOM à l’échelle de toute la page, ce qu’il n’est pas possible de faire avec les Web Components
Rien que pour cette raison, les Web Components me semblent presque être une impasse. Ils peuvent toutefois être utiles lorsqu’on n’a besoin que de petits îlots de fonctionnalités plutôt qu’une page entièrement rendue côté client
J’ai moi aussi observé des limites de performances similaires, mais j’ai toujours pensé que c’était parce que le shadow DOM était lourd. Maintenant, je me demande si ce n’est pas plutôt la création d’instances elle-même qui est coûteuse
J’ai ressenti le même problème avec la gestion d’état, et j’envisage d’essayer une approche inspirée du développement desktop : mettre en place un bus de messages au niveau de la fenêtre, auquel tous les composants s’abonnent et qu’ils filtrent, tout en publiant chaque changement d’état sur ce bus
Pour un exemple de passage d’objets complexes via des attributs, voir zx-listeditor ici :
https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
Le Web Component lui-même est ici :
https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
La petite bibliothèque de 500 lignes qui rend cela possible est ici :
https://github.com/wisercoder/uibuilder/#jsx-for-web-compone...
Le pattern de base de LiveState est : « dispatcher des événements, puis s’abonner à l’état ». Les événements et les mises à jour d’état sont transmis via une connexion WebSocket, et les bibliothèques frontend et backend sont une fine couche au-dessus de Phoenix Channels
Pour l’instant, les fonctions de gestion d’événements sont écrites en Elixir, mais un travail est en cours pour permettre de les écrire dans n’importe quel langage compilable en WebAssembly
Je ne m’attends pas à ce que mon framework JS préféré reste toujours le même. Je sais qu’ils ont une durée de vie courte, et c’est justement ce qui me plaît.
Avancer, progresser et s’améliorer, c’est la raison pour laquelle on utilise React, Vue, Svelte, etc. Je ne veux pas de quelque chose de figé aujourd’hui. Parce qu’aucun des frameworks actuellement utilisables, y compris les Web Components, ne résout ce problème de manière particulièrement élégante.
Si l’affirmation est qu’un site construit avec des Web Components durera plus longtemps qu’un site construit avec un framework JS, j’aimerais bien prendre ce pari. Honnêtement, je pense qu’il est plus probable que, dans les 20 prochaines années, une partie de la stack technologique des Web Components soit retirée de Chrome, Safari ou Firefox et casse l’application, qu’une application React 16 écrite il y a 2 ans casse à cause de changements dans JavaScript.
Si vous figez complètement toutes les versions des dépendances d’une application React 16, elle ne cassera peut-être pas, mais cela ressemble davantage à l’exécution d’un vieux programme dans une VM ou un émulateur qu’au fait de « continuer à travailler et bricoler sur une application React 16 ».
Un pari plus pertinent serait : « Peut-on continuer à développer sur une application React ZZZ, ou sur une application construite avec des Web Components ? »
Si je voulais formuler les conditions de manière plus significative tout en avantageant mon point de vue, ce serait : « Le coût de mise à jour d’une application React pour rattraper N années de mises à jour de dépendances est-il supérieur ou inférieur à celui d’une application Web Components ? » Si l’application Web Components n’est pas encombrée d’une foule de dépendances bizarres, je pense qu’il est très probable que le coût de mise à jour soit plus élevé côté React.
En gros, c’est parier que les éditeurs de navigateurs casseront moins la rétrocompatibilité que les auteurs de React.
HTML Imports a été abandonné au profit de solutions purement JS, et Firefox l’avait déjà implémenté.
Custom Elements v0 a lui aussi été abandonné ; Chrome l’avait implémenté, et YouTube avait été réécrit en urgence avec ça. La transition a pris tellement de temps à YouTube qu’il a fallu attendre environ 4 ans avant de pouvoir supprimer l’implémentation.
Pour garder le code sûr, il faut mettre à jour les bibliothèques. Mais les anciennes versions ne sont plus maintenues, et des vulnérabilités connues impossibles à corriger commencent à s’accumuler. Il est fort probable que les attaquants disposent de programmes qui scannent les sites web présentant des vulnérabilités connues afin de lancer des attaques automatisées.
À l’inverse, si l’on utilise une bibliothèque ou une plateforme qui accorde de l’importance à la rétrocompatibilité, comme les Web Components, on peut préserver la sécurité tout en gardant le support d’un ancien code plus longtemps.
Cela m’amène à me concentrer sur les personnes plutôt que sur la technologie.
Si je démarre un nouveau projet, je regarde d’abord ce que connaissent les personnes qui vont travailler dessus. S’il existe un plus petit dénominateur commun ou des bonnes pratiques, comme c’est le cas de React aujourd’hui côté front-end, j’utilise simplement cela.
Je ne me torture pas l’esprit avec ce genre de décision technique. La composition de l’équipe, le marché de l’emploi et le classement des technologies sur StackOverflow répondent assez facilement à ce genre de question.
Mais si tout le monde raisonne ainsi, alors même s’il existe une meilleure façon de faire du logiciel, nous utiliserons React pour toujours. Décider d’utiliser ce qui est populaire, c’est faire dépendre l’amélioration de sa stack technique d’autres personnes qui trouveront une bonne solution technique et la rendront populaire.
Autrement dit, cette stratégie se situe clairement du côté des adopteurs de milieu/fin de courbe d’adoption. Une grande partie de ce type d’articles et de discussions s’adresse à des adopteurs plus précoces.
Comme on peut utiliser du HTML dans le Markdown, l’idée que des diagrammes interactifs sophistiqués puissent aussi être exprimés avec des balises HTML ordinaires et donc être portables comme le reste du Markdown, MDX peut faire exactement la même chose
La technologie des Web Components en elle-même n’aide pas ici. Ce qui préoccupe l’auteur, c’est l’interface entre le balisage et le fragment de code qui applique les fonctionnalités d’exécution. Les Web Components ne sont ici qu’un détail d’implémentation. Qu’on référence un composant React, un élément d’Astro ou un Web Component entre chevrons n’a pas d’importance. L’essentiel, c’est qu’autre chose soit invoqué
Le défaut des Web Components ici, c’est qu’ils ne s’exécutent en pratique que côté client. Comme il n’y a pas de moyen de transmettre au client le contenu du shadow DOM rendu côté serveur, il faut du JS client pour rendre un Web Component, même s’il est totalement non interactif. Ce n’est pas le cas des autres frameworks
Cela ne veut pas dire que le point de l’auteur est faux. Comme façon de systématiser l’interface entre fragments de code, les Web Components sont peut-être la meilleure approche et celle qui durera le plus. Mais côté serveur, les Web Components n’aident en rien. Ils ne rendent rien, leur interface est fastidieuse, et le code est probablement déjà écrit d’une manière qui peut être traitée globalement. Si vous utilisez Astro sur le serveur, continuez à utiliser Astro. Même chose pour React, Vue ou n’importe quoi d’autre
Les Web Components brillent côté client. Quand on utilise des composants tiers qui n’ont peut-être pas été écrits dans le framework choisi, on n’a pas besoin de savoir avec quel framework le composant placé sur la page a été construit. Il suffit d’utiliser une balise HTML et cela fonctionne. Le mécanisme d’interface remonte au niveau du navigateur, donc deux frameworks n’ont pas besoin de connaître les détails d’implémentation l’un de l’autre
En ce sens, vous avez raison : il faut un outil. Mais cet outil peut être n’importe quel moteur de template côté serveur capable d’initialiser le HTML de départ
En revanche, on peut transmettre au client un shadow DOM rendu côté serveur. Cela s’appelle le shadow DOM déclaratif, et cela fonctionne dans tous les principaux navigateurs sauf Firefox. Firefox y travaille en ce moment, et il existe aussi un polyfill
https://developer.chrome.com/articles/declarative-shadow-dom...
À noter que ce polyfill est assez simple, donc il peut être utilisable même si votre navigateur ne le prend pas encore en charge
Si des Web Components pouvant être rendus côté serveur voient le jour, cela ouvrirait beaucoup de possibilités pour améliorer l’expérience utilisateur des applications multipages
Le monde JS reste trop obsédé par le client lourd qui garde tout le contrôle, et passe à côté de choses intéressantes qui se produisent côté serveur
Des solutions comme Rails Hotwire, Phoenix LiveView et Laravel Livewire peuvent couvrir 80 % du frontend avec un minimum de JS et presque aucune complexité d’expérience développeur
J’ai aussi construit des applications frontend riches en fonctionnalités, capables de lire et d’écrire dans une base de données et un stockage d’objets sans serveur. C’est très portable, et l’installation se résume à téléverser quelques fichiers. Cela peut être exécuté directement depuis un simple CDN, et c’est très rapide
La plupart des développeurs frontend que je connais connaissent aussi l’univers Hotwire, mais pour eux ce type de stack ajoute de la complexité à l’expérience développeur. Parfois, quand les gens disent « complexité », ils veulent en réalité dire « manque de familiarité ». Le frontend comme le backend peuvent devenir excessivement complexes, mais ce n’est pas une fatalité
Quand les choses tournent mal, je préfère avoir davantage de contrôle. C’est d’autant plus vrai dans des environnements rapides où le client veut tout, immédiatement
Personnellement, je préfère écrire tout en JavaScript/TypeScript plutôt que de saupoudrer du sucre syntaxique sur le HTML
Le fait de déplacer cela côté serveur, comme avec Livewire, ne supprime pas pour autant des inconvénients majeurs comme la latence
Le titre est probablement juste, mais je ne sais pas si c’est important. La plupart des applications ne vivent pas si longtemps
J’ai récemment essayé les Web Components, et dans n’importe quel framework, mettre en place des fonctionnalités pourtant très simples était vraiment confus et complexe. Si le composant est simple, ce n’est peut-être pas grave, mais si l’on construit une application en JS, les slots sont une fonctionnalité essentielle car ils permettent de créer des composants composables
Déboguer le shadow DOM dans les outils de développement était aussi vraiment déroutant
Les render props de React ou les scoped slots de Vue sont très couramment utilisés pour injecter des données du composant parent vers le composant enfant. Mais reproduire ce comportement dans un Web Component est en pratique impossible sans bricolages à base de MutationObserver. L’hypothèse des Web Components selon laquelle le composant enfant et le composant parent n’ont pas besoin de connaître leurs informations respectives ne correspond pas au monde réel
L’hypothèse selon laquelle un composant enfant est toujours chargé et initialisé indépendamment de son parent est également fausse dans la plupart des frameworks. Dans la plupart des frameworks, c’est le composant parent qui décide s’il faut réellement charger ou initialiser le composant enfant
Les Web Components sont peut-être meilleurs pour écrire des composants isolés et réutilisables, mais la DOM API utilisée pour assembler tout ça afin de faire fonctionner une application est tout simplement médiocre
On voit qu’elle a été conçue pour éditer des documents XML
Il y a aussi une autre raison pour laquelle je ne crée pas de Web Components, même pour des composants isolés et réutilisables : aucun éditeur ne gère correctement l’autocomplétion des attributs ou des noms d’événements, ni la détection des fautes de frappe
Pour les rendre utiles, il faut chaîner plusieurs dépendances, et ces dépendances seront probablement moins bien maintenues que React
J’ai déjà travaillé dans une entreprise qui suivait cette philosophie. Tous les composants UI étaient des Web Components, chacun avec son propre package npm à installer. Ça fonctionnait bien, mais il n’y avait absolument aucun avantage. Six ans plus tard, il n’y en a toujours aucun. En gros, on optimise pour un avenir qui n’arrivera probablement jamais
Les sites HTML/CSS survivront plus longtemps que tout le reste
Parce que le texte, les images et la mise en page sont réellement contenus dans quelque chose de statique, qui peut survivre éternellement sans qu’on y touche, sans exécution de code complexe ni maintenance de quasi-standards obscurs qui changent vite
Si vous voulez créer des sites durables et disposer de technologies durables, il suffit d’apprendre à créer des sites HTML améliorés progressivement. Les approches comme les Web Components, où l’on crée des éléments HTML non définis avec des tirets puis on lance beaucoup de JavaScript avant de les définir, ou les frameworks JavaScript qui ne font même pas semblant d’utiliser HTML, ne tiendront que quelques années
Au moins jusqu’à ce que les navigateurs retirent la prise en charge de HTTP/1.1