Les Web Components sont une spécification du W3C dont le but est de permettre aux développeurs web de réaliser et composer facilement des widgets avec un haut degré de richesse visuelle et d'interactivité. En attendant que les Web Components soient supportés correctement dans les navigateurs, les développeurs peuvent utiliser la librairie Brick qui offre de nouvelles balises HTML (tags) personnalisées pour abstraire les patterns courants d'interface utilisateur.
Brick est basé sur la librairie polyfill X-Tag, aussi, pour pouvoir exécuter du code s'appuyant sur des balises de Brick, vous aurez besoin d'attendre que l'évènement DOMComponentsLoaded soit déclenché au lieu de simplement utiliser window.unload :
document.addEventListener('DOMComponentsLoaded', function(){
// run code here...
});
Au moment de la rédaction de cet article, Brick consiste en 13 balises différentes (ou "bricks"), la plupart indépendantes les unes des autres, et pouvant même être téléchargées séparément plutôt qu'en un seul paquet :
- Appbar
- Calendar
- Datepicker
- Deck
- Flipbox
- Iconbutton
- Layout
- Slidebox
- Slider
- Tabbar
- Toggle
- Togglegroup
- Tooltip
Voici à quoi resemble la brique calendrier (calendar brick) :
<x-calendar></x-calendar>
Google, qui a une très grande confiance en l'avenir des Web Components, travaille également sur une librairie polyfill de Web Components appelée Polymer qui, tout en utilisant les navigateurs existants, essaye de pousser des technologies futures comme Shadow DOM, les Custom Elements (éléments personnalisés) et le "Model Driven Views" (spécifications déclaratives des interfaces par-dessus un modèle de données).
Il est important de noter que bien que les Web Components semblent avoir pris de la vitesse durant l'année passée, la spécification évolue vite et il y a encore des zones d'incertitude. Il ya quelques semaines Dimitri Glazkov de Google a proposé dans une liste de diffusion du W3C d'enlever l'élément <element> de la spécification. Le consensus sur ce sujet est que la syntaxe proposée pour <element> n'était pas assez bonne et que ce devrait être aux librairies d'explorer ce domaine avant que la normalisation soit définitive, comme Brian Kardell du groupe Apollo le mentionne :
Laissez un peu de champ libre à des projets comme x-tags et polymer, et même à des projets comme Ember et Angular, pour aider à se poser les bonnes questions et trouver des réponses potentiellement compétitives -- Il n'y a pas d'urgence à normaliser un niveau aussi élevé pour le moment, à mon avis (IMO).