En tant que développeur nous devons à un moment ou un autre créer des interfaces graphiques. Il y a 15 ans créer une application en Java imposait de créer une interface en Swing. Ce framework était très intéressant à l'époque car il donnait la possibilité de créer une architecture à base de composants, de factoriser du code, de gérer les événements… Par contre son utilisation était (et est encore pour ceux qui doivent maintenir l'existant) très lourde.
Si on voulait créer une application web à l'époque, nous étions très limité. Le HTML ne permettait que de décrire des blocs de texte et de faire des liens entre les documents. La notion de composant était illusoire et la seule notion de réutilisation que nous avions passait par le copier coller.
Comme Swing était lourd et que le HTML/JS au fur et à mesure de son évolution devenait intéressant, nous avons commencé à palier les manques en générant ce HTML côté serveur. C'était toujours une usine à gaz mais la complexité pouvait être cachée dans les frameworks.
GWT est peut être le langage qui a permis de changer la donne. Le métier de Google est lié au web. Ils ont donc demandé à leurs équipes Java de créer un ensemble d'outils qui permettraient de générer un site web à partir d'une application Java, qui permettraient de créer des composants réutilisables, mettraient à disposition un bus d’événements, géreraient les problèmes de compatibilité des navigateurs…
Même si le rendu est tout à fait acceptable, GWT nous demandait encore d'écrire du code Java pour au final générer un site web. Pourquoi ne pas utiliser directement les technologies Web ? Aujourd’hui avec l'évolution de HTML, des navigateurs c'était la suite logique.
Plusieurs frameworks Javascript sont apparus ces dernières années, permettant de créer des applications single page entièrement en HTML/CSS et Javascript. On peut citer par exemple le framework Angular. Ce dernier permet par exemple d'enrichir le HTML en créant ses propres composants (noition de directive). Angular est la solution apportée par Google mais elle n'est pas unique. D'autres frameworks comme EmberJS permettent également de le faire mais un composant écrit en Angular ne sera pas réutilisable dans une application Ember. De plus nous ne savons pas la durée de vie de ces différents frameworks.
Il faut donc trouver une norme qui permettrait de développer ses propres composants (widgets), de les partager et de les utiliser quelque soit la technologie Javascript utilisée, une norme qui apporterait une réponse pour gérer les templates, l'encapsulation, des éléments personnalisés, du databinding...
En fait cette norme des Web Components est en cours de rédaction auprès du W3C depuis 2009. Ce processus est long car différents acteurs participent (Google, Mozila,...) à ce comité de rédaction et il est dur d'obtenir un consensus. La norme HTML5 a mis 9 ans avant d'émerger.
Quand on parle de Web Components nous avons en fait plusieurs parties
Quand on parle de Web Components nous avons en fait plusieurs parties
- les templates
- le shadow dom
- les customs elements
- les imports
Je ferai un focus sur chacun de ces aspects dans de futurs articles et je montrerai des exemples d'utilisation des web components et comment faire pour anticiper l'adoption de ces composants à l'aide de polyfills tels que polymer.
En attendant si vous voulez suivre les actualités liées à ce sujet vous pouvez consulter http://webcomponents.org/
Aucun commentaire:
Enregistrer un commentaire
Remarque : Seul un membre de ce blog est autorisé à enregistrer un commentaire.