Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les Web Components : pour le meilleur et surtout pour le pire

Un développeur Web nous livre son expérience

Le 29 septembre 2014 à 22:56, par SylvainPV

24 commentaires

204PARTAGES

Voter pour

8

Voter contre

0

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 lu gratuitement 4 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

24 commentaires

Commenter Signaler un problème

Membre émérite

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 />

Voter pour

1

Voter contre

0

Rédacteur/Modérateur

Le 04/10/2017 à 14:03

Non, le CSS scopé et les modules CSS sont deux concepts légèrement différents. Vue-loader gère les deux :
https://vue-loader.vuejs.org/en/feat...coped-css.html
https://vue-loader.vuejs.org/en/feat...s-modules.html

Voter pour

1

Voter contre

0

Rédacteur/Modérateur

Le 20/06/2019 à 15:48

Cinq ans après la publication de cet article, les Web Components ne semblent toujours pas avoir convaincu l'industrie:
https://dev.to/richharris/why-i-don-...omponents-2cia
https://adamsilver.io/articles/the-p...eb-components/

Le support navigateur est toujours imparfait, les polyfills existent mais sont coûteux, et les libs basées sur les Web Components comme Stencil ou Polymer ont dû mal à concurrencer les frameworks les plus populaires. Sur le podium, React Angular et Vue proposent tous des exports au format WC, mais aucun n'a fait le choix d'utiliser ce format par défaut. Aujourd'hui, la tendance est aux compilateurs ahead of time pour précompiler les composants et réduire fortement la taille du code exporté, voire arriver à un objectif zero runtime comme Svelte par exemple. Il devient donc de plus en plus difficile de défendre l'intérêt des Web Components, qui semblent apporter plus de problèmes qu'ils n'en résolvent.

Voter pour

1

Voter contre

0

Membre confirmé

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 ?

Voter pour

0

Voter contre

0

Rédacteur/Modérateur

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.

Voter pour

0

Voter contre

0

Membre confirmé

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.

Voter pour

0

Voter contre

0

Membre éclairé

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.

Voter pour

0

Voter contre

0

Rédacteur/Modérateur

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

Voter pour

0

Voter contre

0

Membre éclairé

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.

Voter pour

0

Voter contre

0

Rédacteur/Modérateur

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.

Voter pour

0

Voter contre

0

Commenter Signaler un problème