Les Web Components, pour le meilleur et pour le pire [Débat]

**SylvainPV** · 29/09/2014, 22h56

Avez-vous déjà utilisé les Web Components ? Cette nouvelle façon de concevoir les pages Web est pressentie comme une prochaine révolution en matière de développement web. Elle permet de manipuler des composants d'interface encapsulés sous la forme de balises HTML personnalisées, grâce à l'association de plusieurs nouvelles spécifications : les Custom Elements, les HTML imports et le Shadow DOM.

Si vous n'avez jamais entendu parler des Web Components, je vous invite à découvrir cette excellente introduction par Didier Mouronval : Les éléments personnalisés - Créez de nouvelles balises HTML

Les Web Components ont fait beaucoup parler d’eux depuis l’avancée des dernières spécifications et le développement de polyfills permettant de les utiliser dès maintenant. Mais cet engouement est-il justifié ? Pour aller à contre-courant de la multitude d’articles en vantant les mérites, j'ai souhaité mettre en avant l’intérêt discutable, les limitations, les inconvénients et les mauvais cas d’utilisation des Web Components :

Débat: Les Web Components, pour le meilleur et pour le pire ?

Je vous invite à poursuivre le débat ici.

Allez-vous utiliser les Web Components dans vos futurs projets ?

Pensez-vous que les Web Components vont révolutionner le développement web ?

Quels autres avantages et inconvénients voyez-vous dans l'état actuel des spécifications ?

**Kaamo** · 02/10/2014, 12h04

Quel pessimisme...ça fait du bien ! Enfin un article qui met le doigt sur la corde sensible des Composants Web.

Je suis aussi mitigé que toi. Ce qui me fait peur c'est la qualité et surtout la pérennité des Composants trouvés au hasard du net. Quid du versionning du Composant ... y'a t-il un mécanisme de mise à jour ?
Un composant vanilla, ok ... Mais si le Composant repose sur une librairie. Dois-je vraiment charger cette lib pour faire tourner le Composant ? Et si je préfère un composant chez une lib concurrente ? J'espère que l’interopérabilité sera au RDV.

J'ai aussi peur qu'à l'avenir les développeurs utilisent à tout-va les Composants Web comme ils ont utilisé à tout-va jQuery. La facilité au détriment de la qualité.
Si tout le monde pouvait se poser les questions "check" que tu décris à la fin de ton article.

A choisir, pour le moment, je préfère :

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<div id="une-bonne-soupe-à-l-ancienne>
  <div id="mon-bol-prefere">
    <span>avec des bons légumes dedans</span>
  </div>
  <div id="ma-cuillere-fetiche">
    <span>rouge et jaune à p'tits pois.</span>
  </div>
</div>

plutôt que :
<une-soupe-dont-je-ne-vois-pas-les-ingrédients />

**madfu** · 02/10/2014, 12h38

Envoyé par Kaamo

J'ai aussi peur qu'à l'avenir les développeurs utilisent à tout-va les Composants Web comme ils ont utilisé à tout-va jQuery.

Je n'ai jamais utilisé les WebComponents (j'ai regardé rapidement le lien et je dois reconnaître que je trouve ça un peu lourd) mais je trouve que c'est un premier pas intéressant de vouloir standardiser cette manière de développer.

Après tout du réutilisable c'est ce qu'on fait avec les languages de template type Handlebar. Et puis le fait que jQuery soit utilisé à tort et à travers n'en rend pas la lib moins performante non ?

**SylvainPV** · 02/10/2014, 13h44

Envoyé par madfu

Et puis le fait que jQuery soit utilisé à tort et à travers n'en rend pas la lib moins performante non ?

Justement si, certains ont pointé du doigt qu'utiliser systématiquement jQuery n'était pas justifié et pouvait se ressentir sur les performances. Mais dans le cas des Web Components, la performance est loin d'être ma principale préoccupation.

**madfu** · 02/10/2014, 13h54

Envoyé par SylvainPV

Justement si, certains ont pointé du doigt qu'utiliser systématiquement jQuery n'était pas justifié et pouvait se ressentir sur les performances.

C'est sûr. Mais entre nous je préfère vivre dans un monde avec jQuery même si certains l'utilisent à tort et à travers. Quand aux WebComponents puisque c'est ça le débat j'attendrais de voir mais je pousse clairement dans ce sens.

**Sodium** · 02/10/2014, 14h53

Envoyé par madfu

C'est sûr. Mais entre nous je préfère vivre dans un monde avec jQuery même si certains l'utilisent à tort et à travers. Quand aux WebComponents puisque c'est ça le débat j'attendrais de voir mais je pousse clairement dans ce sens.

Personnellement, je préfèrerais vivre dans un monde sans jQuery mais avec un Javascript unifié et pourvu nativement en méthodes d'animation de propriétés.

**Paleo** · 02/10/2014, 18h12

Merci à l'auteur pour ce débat.

Je partage certaines interrogations comme l'utilité des HTML imports, lesquels impliquent une utilisation agressive des requêtes HTTP. S'agit-il d'un standard réservé aux applications non déployées dont les composants ne sont pas encore minifiés et fusionnés ? Ou bien est-ce un pari sur l'avenir du protocole HTTP 2 ? Sur le sujet : la FAQ de Polymer.

Actuellement, la spécification présente plus de contraintes que d'avantages comparée aux solutions existantes à base de <script>. Elle a le mérite d'enfin apporter un standard pour un mécanisme utilisé et éprouvé depuis des années. Mais tout comme les imports HTML, elle semble arriver trop tard et les éléments <template> seuls ne servent à rien sans JavaScript pour les activer.

Personnellement j'ai toujours trouvé que le détournement de la balise <script> était une bidouille infame. La balise <template> est la bienvenue. Il n'est jamais trop tard pour bien faire.

HTML, un descendant de SGML […] HTML a pris un autre chemin. […] Depuis HTML5, les éléments n'ont d'ailleurs plus à respecter les contraintes d'une DTD […] Malgré le fait que le HTML5 se soit émancipé des DTD, on pourrait tout de même en parler ne serait-ce qu'à titre de comparaison.

Tout à fait. Il y a dix ans le XHTML était l'avenir du HTML et HTML 4 était vu comme un dialect SGML approximatif dont les parseurs toléraient les écarts. Depuis HTML 5, HTML trace son propre chemin. Par exemple, les balises non fermées, lorsqu'elles ne sont pas ambigües, sont devenues des fonctionnalités que Google recommande d'utiliser.

D'autres diront qu'il présente un intérêt pour l'isolation des règles CSS. Je leur répondrai qu'il existe d'autres moyens pour y parvenir sans avoir à fragmenter le document: <style scoped> @import "composant.css"; </style>

J'ai lu récemment que cette fonctionnalité était en train d'être abandonnée

Sur les Shadow DOM je n'ai pas encore d'expérience mis à part quelques tests. Toutefois je ne pense pas qu'il faille les voir comme autre chose que des espaces de nommage. Et dans des applications JavaScript, un mécanisme d'encapsulation est une fonctionnalité bienvenue.

Au fond le mensonge dans les "Web components" vient de l'apparente simplicité d'utilisation. Un web component sans framework est soit compliqué à utiliser parce qu'il faut le fusionner et faisant gaffe aux dépendances, soit un défaut de performance parce que son chargement nécessite plusieurs requêtes HTTP. Je pense qu'un bon Web component facile à utiliser dépendra en fait d'un framework et non pas des seuls standards.

**SylvainPV** · 02/10/2014, 18h53

A propos de style scoped, voilà un extrait des échanges des équipes Blink:

Il ne s'agirait donc pas d'un abandon, mais d'un retrait temporaire d'une fonctionnalité qui était toujours resté au stade expérimental. Ce retrait a été amené à cause de la complexité de l'implémentation du Shadow DOM... ben voyons

**Paleo** · 02/10/2014, 19h47

Ah, et je vois que Firefox implémente "style scoped". C'est intéressant. Peut-être effectivement une meilleure manière de concevoir une application avec des styles imbriqués : meilleur pour l'homogénéité. D'un autre côté, je me demande si l'inclusion de styles dans le code HTML est ou non une manière élégante de travailler.

Contrairement à un "style scoped", dans le cas du shadow DOM, les styles globaux ne s'appliquent pas sur les shadow DOM. C'est un inconvénient : comme pour les iframe, le résultat final est une page vraiment pas homogène. Mais c'est aussi un avantage : pas d'effet de bord lors d'un changement des CSS du DOM global.

Un reset CSS classique (ou un normalize.css) ne s'applique donc pas sur les balises situées à l'intérieur du shadow DOM. Il faudra réécrire les styles transversaux avec le sélecteur /deep/, mais il reste à voir les effets sur la performance et puis on manque un peu de recul pour savoir si l'on peut travailler proprement ainsi.

**SylvainPV** · 02/10/2014, 21h09

Exact, l'isolation totale a plus d'inconvénients que d'avantages selon moi. Certaines règles, comme celles de normalisation ou celles relatives à la charte graphique du site, ont tout intérêt à s'appliquer partout. D'autres ne devraient s'appliquer qu'au composant ciblé, et les styles scoped ont été pensés pour ça.

Mais on a pas absolument besoin de ces nouvelles fonctionnalités: les développeurs ont déjà résolu ce problème en ajustant intelligemment la spécificité des sélecteurs, comme tu l'as bien montré Tarh avec ton article sur la méthodologie BEM par exemple.

Concernant la place du CSS dans le HTML, je suis d'accord que multiplier les balises <style> au milieu du document n'est pas non plus la panacée. Idéalement j'aurais voulu que CSS gère les nested rules (règles imbriquées), comme le font déjà tous les préprocesseurs CSS.

**Zefling** · 03/10/2014, 00h13

Envoyé par SylvainPV

Concernant la place du CSS dans le HTML, je suis d'accord que multiplier les balises <style> au milieu du document n'est pas non plus la panacée. Idéalement j'aurais voulu que CSS gère les nested rules (règles imbriquées), comme le font déjà tous les préprocesseurs CSS.

Genre ça : http://tabatkins.github.io/specs/css-nesting/
Dommage que ça ne soit qu'une proposition.

**Paleo** · 03/10/2014, 09h08

Envoyé par Zefling

Genre ça : http://tabatkins.github.io/specs/css-nesting/
Dommage que ça ne soit qu'une proposition.

D'après ce que je lis c'est juste une manière de refaire ce que font les préprocesseurs, en moins souple, moins lisible, moins complet. Si le but est d'apporter les namespaces aux CSS, les actuels sélecteurs de descendants feraient l'affaire (".namespace .nested-selector") à part qu'il est impossible de les optimiser (ils sont intrinsèquement lents). Si l'on pouvait indiquer au navigateur où sont les composants dans le document, il pourrait en faire des contextes partiellement autonomes. Cela permettrait des optimisations, comme la génération de tables de hachage pour les descendants au niveau de chaque composant. Les blocs englobants des préprocesseurs CSS se rapprochent effectivement de ce besoin, mais une spécification qui irait dans ce sens ne permettrait pas un sélecteur "section > &".

**SylvainPV** · 03/10/2014, 09h46

@Tahr: le besoin que je verrais serait plus quelque-chose de ce genre :

Code css :

Sélectionner tout - Visualiser dans une fenêtre à part

#header { @import "header.css"; }

Que ferait ton sélecteur "section > &" ? Si ça reviendrait à ajuster le sélecteur selon le parent, c'est intrinsèquement impossible avec CSS qui ne peut pas naviguer dans le DOM de bas en haut.

Les sélecteurs par descendant amènent de nombreux copier-coller, ils ne sont pas optimisés ni pour le temps de traitement, ni pour la taille de fichier. Les nesting rules pourraient faire d'une pierre deux coups.

**Paleo** · 03/10/2014, 10h25

Envoyé par SylvainPV

Que ferait ton sélecteur "section > &" ?

Il est dans la proposition de spec, le lien donné par Zefling.

**romaintaz** · 15/04/2015, 11h31

Hello,

J'arrive un peu après la bataille, mais je vais lire ce débat avec intérêt, pour une fois qu'on voit un peu de critiques construites sur les web components, il ne faut pas s'en priver

!
Je voudrais juste revenir sur le shadowDOM considéré comme un cache misère.

Je ne peux pas être en désaccord avec cela, mais je ne comprends pas trop pourquoi cela est reproché aux web-components.
Je m'explique : c'est un peu comme un plugin jQuery, une directive Angular, ou que sais-je encore, on l'utilise "tel quel", mais rien n'empêche d'aller jeter un oeil dans le code (c'est d'ailleurs plutôt sain en général).
Si cela ne nous plait pas, il y a plusieurs solutions : on en choisit un autre, on le réécrit, on le forke, on push-requeste, etc.

Bref, si cela peut être considéré comme un problème, ce n'est absolument pas lié aux web-components. Quand j'utilise une librairie Java, rien ne me dit si le code est correct, sécurisé, performant, sauf à y jeter un oeil (quand il n'est pas obfusqué du moins).

Alors bien entendu, on finira toujours pas se poser la question "j'ai besoin d'utiliser un composant X, lequel prendre ?", et hélas la réponse n'est pas toujours simple. Mais cette question, on se la pose déjà tous les jours, et ce n'est pas près de changer !

Au final, je préfère avoir 1 à 2 lignes d'un composant que j'aurais choisi et approuvé plutôt que d'écrire moi-même 30 lignes de "plomberie".
Quand on voir le code d'un carousel de Bootstrap (http://getbootstrap.com/javascript/#carousel), je me dis qu'il y a quand même beaucoup de code "pour rien" (ou plutôt juste là pour faire marcher le composant).
Avoir un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
<tb-carousel>
	<tb-slide>...</tb-slide>
	<tb-slide>...</tb-slide>
	...
</tb-carousel>

c'est quand même plus clair et plus lisible, non ? Il ne faut pas oublier qu'on passe en général 80% à lire du code et 20% à en écrire. Plus celui-ci est concis / clair, mieux c'est !

**SylvainPV** · 15/04/2015, 13h55

Oui, le problème du junk HTML n'est pas à imputer aux Web Components ; il existe depuis des années, que ce soit de la mise en page par tableaux ou de la soupe de <div>. Mais ce que je crains est que l'on fasse passer les Web Components pour une solution à ce problème, alors qu'il n'en est rien. Pire, cela pourrait être considéré comme une acceptation tacite et quelque peu fataliste au fait qu'un markup de présentation est nécessaire. Auquel cas le problème devrait logiquement empirer davantage, puisqu'il y a maintenant un standard qui lui est dédié. La citation de webcomponents.org que j'ai mis dans l'article est vraiment révélatrice à ce sujet. C'est ce que j'ai voulu exprimer par mon illustration de la boîte en carton sur la tête, car selon moi la pire façon de faire face à un problème est de mettre un drap dessus.

**Paleo** · 09/10/2015, 09h24

AMP, le nouveau projet de Google destiné à accélerer l'affichage des pages Web sur les mobiles, fait massivement appel aux Web components:

With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.

JavaScript is the core building block for advanced web apps, but for static content it may not always be required: for a headline, some text and an image you do not need JS. Looking further into the content being created on the web nowadays, there are, however, things like lightboxes, various embeds, polls, quizzes and other interactive features that cannot easily be implemented without JavaScript. But the web platform has a great solution: custom elements and web components. AMP components may have JavaScript under the hood, but it is coordinated with other AMP components, so its composition into the page doesn’t cause performance degradation. If AMP HTML provided the right custom elements, we might be able to get rid of arbitrary JavaScript for these documents altogether. [Source]

À lire aussi : la présentation officielle, une critique. Et l'article de developpez.com !

**SylvainPV** · 09/10/2015, 11h02

Le tech lead du projet AMP a dit :

With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.

Donc interdiction d'utiliser des scripts persos ou extérieurs, uniquement les Web Components Google-approved. Vous les voyez venir là, les Web Components boîte noire ? Ne donnez pas les clés de votre site à n'importe qui !

http://sylvainpv.developpez.com/publ...ts-debat/#LV-C

**Paleo** · 29/09/2017, 12h44

:scope est obsolète.
Sait-on pourquoi ?

La page de Mozilla précise :

In JavaScript, when used with Element.querySelector, Element.querySelectorAll, or Element.closest, :scope refers to the element on which these methods are invoked. For example, document.body.querySelector(":scope") returns the body element. While support for :scope has been removed for CSS, this use of :scope continues to be supported.

Il continue à être supporté par "querySelectorAll" mais cet usage est-il menacé ?