Les composants web ne sont (encore) pas très connus de la communauté, pourtant ils représentent une avancée majeure dans la standardisation des interfaces web. À l’origine, HTML est un langage conçu pour créer des pages web, donc un réceptacle à textes, images et tableaux. Le W3C y a rapidement ajouté les formulaires en ligne pour offrir aux pages web un minimum d’interactivité. Après deux décennies de pratiques, HTML se révèle être une technologie robuste et mature pour la plupart des sites web (sites rédactionnels, portails, boutiques en ligne…), en revanche, les choses se compliquent dès qu’il est question d’applications en ligne. Si les dernières balises introduites dans HTML5 permettent de mieux structurer les contenus (je pense notamment aux balises Nav, Article, Footer ou Aside), rien n’a été prévu pour les applications. Il en résulte une utilisation anarchique de CSS et javascript pour pouvoir reproduire ce que nous connaissons dans les interfaces des logiciels.
Pour couronner le tout, nous assistons à un authentique raz-de-marée des terminaux alternatifs (smartphones, tablettes, montres connectées…) qui complique encore plus les développements nécessaires pour assurer une bonne comptabilité d’une application en ligne. La promesse des web components est d’aider les développeurs à créer, distribuer et exploiter des composants réutilisables. Le terme exact est “encapsuler”, car l’idée est de fournir des composants prêts à l’emploi, un peu comme les players de YouTube ou Slideshare. Prenons l’analogie du secteur automobile : les constructeurs ne produisent pas 100% des voitures, elles s’appuient sur des équipementiers qui leur fournissent des composants standards pour les phares, les essuie-glaces… bref, des composants génériques qui accélèrent la mise sur le marché.
La révolution induite par les web components est de pouvoir grandement accélérer le développement d’applications en ligne multi-plateforme (desktop, laptop, tablette, smartphone…) en s’appuyant sur des composants génériques que l’on intègre avec une simple ligne de code. Certes, il existe de nombreuses librairies d’éléments d’interface comme jQuery UI, Sencha Ext JS ou Dojo (cf. Sencha lance une nouvelle version de GXT pour accélérer le développement d’applications web), mais elles sont lourdes à charger et pas nécessairement modulaires. La possibilité de n’encapsuler que les composants web de votre choix est un plus indéniable pour éviter d’avoir à charger plusieurs fichiers javascript volumineux.
Google est aujourd’hui le plus gros sponsor des web components, notamment à travers Polymer, le framework exploité sur la future nouvelle version d’Android (cf. Avec Polymer, Google veut faire d’Android une interface universelle). Chrome est ainsi le premier navigateur à être officiellement compatible avec les web components (depuis la version 26). Pour vous donner une idée de ce à quoi peut ressembler une application en ligne construite à partir de composants web, je vous incite à visiter les démos suivantes : Foodtrack, Caclulator ou Topeka.
Ceci étant dit, Google n’est pas le seul promoteur des composants web, puisque le W3C a commencé ses travaux de normalisation des Web Components en juillet dernier. Il existe aussi d’autres initiatives comme Bosonic ou celles lancées par Mozilla : X-Tag et surtout Brick qui vient d’annoncer sa V2 (Build better HTML5 UIs with Mozilla’s latest Brick library).
Il existe de nombreux articles décrivant les bases des composants web (An Introduction to Web Components and Polymer) et même un portail officieux (WebComponents.org) où l’on trouve tout une série d’articles et des présentations. Les composants web étant librement distribuables sur le web, vous imaginez que leur recensement peut poser problème. Heureusement il existe déjà des collections en ligne comme BuiltWithPolymer, CustomElements ou Component Kitchen (où l’on trouve de très belles choses comme l’interface Akyral).
Je sais bien que ce n’est pas la première fois que vous entendez parler d’une technologie révolutionnaire qui va transformer la façon de faire ci ou ça, mais je peux vous garantir que ces web components présentent le potentiel pour modifier de façon irrémédiable la façon dont sont codées les interfaces des applications en ligne. Nous aurons l’occasion d’en reparler…
j’invite les lecteurs à aussi consulter ce lien http://sylvainpv.developpez.com/publications/web-components-debat/
pour se faire un idée plus exacte de cette révolution.
J’allais justement faire un commentaire sur l’utilisation et son implémentation actuelle qui ne correspondais pas point de vu générale du HTML. Mais je vois que le liens d’ami44 contiens déja pas mal de choses.
Le HTML n’est qu’un language à balisage dédié à:
“structurer sémantiquement et de mettre en forme le contenu” — Wikipedia FR
Il n’est dont pas là pour décrire une système Lego décrivant une d’interface graphique. De se coté, si l’on veux un language spécifique, il existe par exemple le XUL + XBL.
A mon avis, dans l’état cela ne fonctionnera pas. D’une part c’est pas dans l’essence même du HTML (de décrire des interfaces) et d’une autre part cela nécessite forcément JS. Du coup à quoi cela sert-il ? D’ailleurs il n’y a que Blink qui l’implémente.
Du coté du W3C c’est chez seulement Google qui rédige les draft de la spec.
Microsoft n’a pour sa part mis seulement qu’en “Under consideration” https://status.modern.ie/customelements.
De leur coté Mozilla promeut x-tags principalement pour Firefox OS https://developer.mozilla.org/en-US/Apps/Tools_and_frameworks/Custom_elements https://bugzilla.mozilla.org/show_bug.cgi?id=811542
Ce n’est pas non plus implémenté du coté WebKit (vu que c’était Google qui travaillais dessus avant de forker avec Blink)
@ Mem’s > Nous sommes bien d’accord : HTML est un langage conçu pour structurer des contenus, pas pour créer des interfaces d’applications en ligne. Ceci étant dit, c’est la chose chose que nous ayons à notre disposition, il faut donc bien faire avec… Ceci étant dit, les support (ou non) des Web Components nous replongent dans les heures sombres du web et vers des “Application en ligne optimisée pour Chrome”.
@ Ami44 > Nous sommes d’accord également : les web components permettent de nettoyer le code source d’une page, mais ne résolvent pas pour autant le recours à CSS ou JS. En gros : on ne fait que déplacer le problème (la soupe de balises). Par contre, les composants web sont la première tentative à peut près viable de standardisation et de simplification de la distribution de composants d’interface réutilisables.
Je pense également que les composants web ambitionnent de révolutionner les applications en ligne et en particulier pour les Chrome Apps avec des Chromebooks, mais dans la vision développeur je suis interrogatif à propos du Débat si dessous:
Débat: Les Web Components : pour le meilleur et surtout pour le pire
Un développeur Web nous livre son expérience
http://sylvainpv.developpez.com/publications/web-components-debat/
Et je suis d’accord avec la conclusion du Débat:
VI. Conclusion
En résumé, les Web Components sont un progrès car ils normalisent la définition et l’intégration de composants d’interface, sans toutefois révolutionner leur nature elle-même. Cependant, chaque progrès doit être utilisé intelligemment et modérément…
Bonjour,
je voulais notifier que le lien sur Brick est erroné c’est celui-ci : http://brick.readme.io et non sur celui de Polymer