Developpez.com

Plus de 2 000 forums
et jusqu'à 5 000 nouveaux messages par jour

Les Web Components : pour le meilleur et surtout pour le pire
Un développeur Web nous livre son expérience

Le , par SylvainPV, Rédacteur/Modérateur


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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Kaamo Kaamo - Membre expert http://www.developpez.com
le 02/10/2014 à 12:04
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
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 />
Avatar de madfu madfu - Membre averti http://www.developpez.com
le 02/10/2014 à 12:38
Citation Envoyé par Kaamo  Voir le message
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 ?
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur http://www.developpez.com
le 02/10/2014 à 13:44
Citation Envoyé par madfu  Voir le message
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.
Avatar de madfu madfu - Membre averti http://www.developpez.com
le 02/10/2014 à 13:54
Citation Envoyé par SylvainPV  Voir le message
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.
Avatar de Sodium Sodium - Membre éclairé http://www.developpez.com
le 02/10/2014 à 14:53
Citation Envoyé par madfu  Voir le message
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.
Avatar de Tarh_ Tarh_ - Membre confirmé http://www.developpez.com
le 02/10/2014 à 18:12
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.
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur http://www.developpez.com
le 02/10/2014 à 18:53
A propos de style scoped, voilà un extrait des échanges des équipes Blink:

<style scoped> has been burden for us to maintain.I've felt several times that <style scoped> is the cause of code complexity when I work on Shadow DOM styling.

I'm not saying that blink shouldn't support <style scoped>.
I am saying that we can get benefits from the view of hack-ability of style system if we can forget <style scoped>.
We can reimplement <style scoped> later once we feel it's needed.

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
Avatar de Tarh_ Tarh_ - Membre confirmé http://www.developpez.com
le 02/10/2014 à 19:47
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.
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur http://www.developpez.com
le 02/10/2014 à 21:09
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.
Avatar de Zefling Zefling - Membre émérite http://www.developpez.com
le 03/10/2014 à 0:13
Citation Envoyé par SylvainPV  Voir le message
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.
Offres d'emploi IT
Développeur java & javascript h/f
SPACECODE - Ile de France - Verrières-le-Buisson (91370)
Développeur Javascript H/F
Conserto - Bretagne - Rennes (35000)
Développeur javascript (H/F)
CTS Consulting - Pays de la Loire - Nantes (44000)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique JavaScript : Xavier Lecomte -