Les web components, c’est acceptable

Les web components, c’est acceptable

• La communauté du développement web débat souvent des web components
• Ryan Carniato a publié un article intitulé "Web Components Are Not the Future", auquel Cory LaViska a répondu avec "Web Components Are Not the Future — They’re the Present"
• L’auteur cherche à apaiser ce débat de manière pacifique

Performances

• Les web components reposent sur les Custom Elements, donc toute l’interface est gérée via le DOM
• Réduire au minimum le nombre de nœuds DOM est un levier clé d’optimisation des performances
• Mais les performances ne font pas tout : il faut aussi prendre en compte la maintenabilité, la sécurité, l’utilisabilité et l’accessibilité
• Par exemple, ne pas rendre les attributs aria-* peut améliorer les performances, mais ils restent indispensables pour l’accessibilité
• L’optimisation des performances est importante, mais dans la pratique, des problèmes plus simples comme le layout thrashing, les network waterfalls ou les rerenders inutiles ont souvent un impact bien plus important

Le coût des standards

• Prendre en charge des standards exige d’écrire et d’exécuter du code supplémentaire
• Mais prendre en charge les web components n’est pas une charge particulièrement lourde
• Il est naturel de prendre en compte les nouvelles fonctionnalités de la plateforme web, et cela vaut aussi pour Symbols, Proxys, Promises, etc.
• Une partie de la communauté du développement web peut ne pas vouloir prendre en charge les web components, et c’est très bien ainsi
• Le web est une grande tente qui autorise des approches variées

Conclusion

• Les web components ne sont pas un problème en soi, mais la promesse qu’ils puissent tout remplacer est risquée
• Les web components ont des faiblesses sur le rendu côté serveur, l’accessibilité, l’interopérabilité et d’autres aspects
• D’autres frameworks comme React, Solid et Svelte continuent d’exceller dans certains domaines
• Le web est utilisé à des fins très diverses, ce qui offre des occasions d’exprimer sa créativité
• Les web components peuvent ne pas vous convenir, et c’est très bien ainsi

# Résumé GN⁺

• Cet article présente différents points de vue sur les web components et insiste sur l’équilibre entre les performances et d’autres facteurs
• Les web components ne peuvent pas tout remplacer, mais ils sont adaptés à certains usages
• La communauté du développement web autorise des approches variées, ce qui favorise la créativité
• Si les web components ne vous conviennent pas, vous pouvez utiliser d’autres frameworks
• Les nombreuses possibilités du web ouvrent la voie à de nouvelles formes d’expression créative

[GN⁺]

Avis Hacker News

• L’article « Web Components Are Not the Future » a semblé manquer d’arguments convaincants

  • L’état actuel des frameworks front-end est confus
  • Pas envie d’apprendre des frameworks complexes
  • Pas envie de fonctionnalités magiques impossibles à comprendre sans documentation
  • Les Web Components sont intuitifs et offrent une isolation via le Shadow DOM
  • À l’ère de React, il faudrait selon certains ne conserver que le JSX

• Les avis divergent parce que chacun recherche des optimisations différentes

  • Dans les startups financées par du VC, un framework peut être adapté
  • Dans un labo de recherche universitaire, des Web Components avec moins de coûts de maintenance sont préférables
  • Le passage de Vue aux Web Components a été une très bonne expérience
  • Moins de dépendances, donc une gestion plus simple

• Svelte prend en charge la création de Web Components via la Custom Elements API

  • Svelte compile en JS/HTML/CSS, ce qui facilite la création de composants réutilisables

• Les Web Components n’améliorent pas forcément la vie des développeurs full-stack

  • La plupart des exemples se limitent à templatiser des données dans du HTML
  • C’est déjà faisable avec Handlebars

• Les Web Components et le Shadow DOM peuvent gêner le fonctionnement des extensions de navigateur

  • Les éditeurs de navigateurs ne se pressent pas pour résoudre ce problème

• L’interopérabilité a un coût en performance

  • Plusieurs frameworks embarquent chacun leur propre runtime, ce qui peut entraîner une baisse de performance
  • Les Web Components sont techniquement en retard et ajoutent de la complexité

• Les Web Components peuvent résoudre les problèmes actuels du front-end

  • Les performances sont excellentes et permettent un défilement fluide des tableaux de données
  • Une bibliothèque de Web Components est en préparation

• Après avoir hérité d’une base de code JS de 250 000 lignes, refactorisation en cours vers des Web Components

  • 50 000 lignes de code ont été supprimées
  • Cela aide à mieux comprendre le fonctionnement du code existant

• Les Web Components peuvent fonctionner même sans JS

  • Utilisés à quelques reprises pour de l’amélioration progressive
  • Fonctionnent bien avec le rendu côté serveur

• Les frameworks et les Web Components sont des outils qui répondent à des problèmes différents

  • Les frameworks gèrent le rendu de vues en fonction de l’état
  • Les Web Components ne résolvent pas le problème de la gestion d’état
  • Les deux peuvent coexister, selon certains