Présentation

Sujet : The Polymer Project
Auteur : Quentin DUNAND
Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

Résumé

Le projet Polymer a pour but d'aider les développeurs à fournir une bonne expérience utilisateur en libérant tout le potentiel de la plate-forme Web. Ce projet est composé de deux éléments principaux :

Polymer Library : c'est une bibliothèque JavaScript open-source qui permet de créer des applications Web en utilisant des web-components. La bibliothèque est développée par les développeurs Google et les contributeurs volontaires sur GitHub. La Polymer Library est utilisée par un certain nombre de services et de sites Web Google, y compris YouTube Gaming et les sites Web de la Google I/O.
Polymer App Toolbox : Polymer App Toolbox est une collection de composants, d'outils et de templates rassemblés dans une boite à outil pour permettre aux développeurs de faire des Progressive Web Apps facilement avec Polymer.

Contexte

Traditionnellement, la plate-forme Web n'a jamais été une grande plate-forme de développement pour créer des expériences d’applications web immersives. Le plus bas niveau de primitive visuelle qui existe en tant que développeur web est la balise HTML. Et ces balises HTML qui sont fournies par le navigateur pour des choses comme les titres, les paragraphes et les listes par exemple, fonctionnent très bien pour la représentation de documents. Mais elles ne sont pas si efficaces pour construire des applications web immersives. Et au cours de ces dernières années, le HTML lui-même n'a pas vraiment beaucoup évolué, contrairement aux attentes des utilisateurs. Ce qui a évolué et qui est devenu beaucoup plus puissant, c'est le JavaScript. Et pour créer ces expériences app-like sur le Web mobile, le JavaScript a été utilisé comme une échappatoire.

Les développeurs ont alors construit des méta plates-formes complètement séparées de la plate-forme web. Ils ont construit des runtimes JavaScript, des méga frameworks tout en JavaScript pour permettre d'être en mesure d'offrir des expériences comparables à des applications natives. Et cela fonctionne plutôt bien sur desktop où nous avons de bonnes machines connectées en filaire ou en Wi-Fi. Mais il y a eu un changement majeur dans le web : l'avènement du web mobile.

Le web mobile est incroyablement puissant. Vous n'êtes pas obligés de demander la permission à quiconque de publier votre application sur le Web, et presque chaque appareil connecté va avoir un navigateur pour y accéder. Le web mobile a donc une incroyable portée. Mais cette portée implique que les applications web concernées seront utilisées dans des milieux où la connexion ou le matériel ne sont pas optimaux, en général les deux à la fois pour les pays émergents par exemple. Par conséquent, l'utilisation de ces méta plates-formes imposantes, tout en JavaScript pour offrir une expérience app-like, ne fonctionne pas sur le web mobile. Alors que faut-il faire ? Eh bien, la réponse a été jusqu'ici plus de JavaScript. Nous continuons à empiler de plus en plus de JavaScript pour que cela fonctionne. Et cela est frustrant pour les utilisateurs et pour les développeurs encore plus.

C'est pour cela qu'une réflexion sur le problème est née et une meilleure solution a fait son apparition : utiliser moins JavaScript et utiliser la plate-forme web. Pour créer des applications modernes du Web mobile, utiliser ce qui existe déjà sur l’appareil : le navigateur de votre utilisateur. Il est de plus possible, en tant que développeur, de construire ces expériences immersives app-like en utilisant ce qui est inclut dans le navigateur.

Le but du Polymer Project est donc de tirer parti de ces nouvelles fonctionnalités puissantes, afin de produire des applications web de qualité supérieure.

Web Components

Parmi ces nouvelles fonctionnalités de la plate-forme web, on retrouve les web components. Il faut les voir comme des composants d'interface graphique réutilisables qui ont été créés en utilisant des technologies web libres. Ils font partie du navigateur, et ils ne nécessitent donc pas de bibliothèques externes comme jQuery ou Dojo. Cela permet donc de réduire considérablement les temps de chargement d'une application utilisant ce genre de composant, le framework ou la bibliothèque n'étant pas chargés au lancement de l'application.

Un composant Web existant peut être utilisé sans l'écriture de code, en ajoutant simplement une déclaration d'importation à une page HTML. On peut donc vraiment étendre le HTML grâce aux web components tout en gardant une structure très similaire, les web components se voulant être des éléments standardisés et encapsulés.

Polymer Project

Le but du Polymer Project est de mettre à disposition des développeurs des outils et des bibliothèques qui s'appuient sur les dernières fonctionnalités de la plate-forme web afin de leur permettre de développer les applications web de demain. Pour arriver à cela, la team Polymer a dans un premier temps développé la Polymer Library.

Polymer Library

La Polymer Library est une bibliothèque très légère qui a pour but de faciliter le développement des web components. En effet, à travers un ensemble de fonctionnalités, cette bibliothèque va permettre de créer des web components qui fonctionnent de la même façon que des balises HTML classiques, c'est-à-dire pour que leur utilisation par les développeurs soit transparente et que leur rendu par le navigateur soit fait exactement de la même façon que pour n'importe quelle balise.

Créée il y a maintenant deux ans, la Polymer Library a été annoncée lors de la Google I/O 2014. La bibliothèque fut, dans un premier temps, très bien accueillie par la communauté mais de nombreuses critiques par rapport à des problèmes de performance ont été faites par les développeurs. Google a alors repensé complètement la Polymer Library pour la rendre plus performante. En 2015, Google a annoncé la version 1.0 de la Polymer Library. En plus de nouvelles fonctionnalités et d’un meilleur support des fonctionnalités natives de la plate-forme web, cette version était 4 à 7 fois plus performante que la version précédente. La bibliothèque a alors rapidement été utilisée dans de nombreux projets, principalement chez Google mais pas uniquement. En effet, plus de 500 projets chez Google utilisent la Polymer Library dont Chrome, Google Translate, YouTube ou encore Google Play Music avec plus de 5000 web components créés. En Mai 2016, plus de 4 millions de pages web dans le monde utilisaient la Polymer Library.

Intégration de Polymer dans les Web-app

Durant la naissance de Polymer, de nombreuses questions sont restées sans réponses. En effet, même si Polymer offrait une bibliothèque simplifiant grandement la création de web components, les développeurs ne savait pas comment créer des applications à partir de ces web components. Une application n'étant en fait qu'un gros web component, lui-même composé de plusieurs web components, eux-mêmes composés de plusieurs web components etc…, il était alors impératif de trouver un pattern pour la réalisation de ces applications.

La team Polymer s’est alors penchée sur la question. Néanmoins, l'idée de la team Polymer n'était pas uniquement de pouvoir créer des applications web classiques mais bien les applications web de demain : des Progressive Web App.

Progressive Web App

Une Progressive Web App est définie par la team Polymer comme une application web ayant pris les bonnes vitamines. Avec cette définition, la team Polymer veut faire comprendre qu'une Progressive Web App est une simple web app mais qui s'appuie sur les dernières nouveautés de la plate-forme web afin d'offrir tout un tas de fonctionnalités qu'une application web classique n'as pas telles que :

Un chargement instantané : grâce au Service Worker, l'application se charge très rapidement lors du premier lancement et l'accès au réseau devient optionnel une fois que l'application est déjà chargée une fois
La rapidité : comme une application native, l'application doit afficher 60 FPS (Frame Per Second) grâce aux possibilités offertes pour gérer les animations, la navigation et les défilements
Des notifications Push : la Notification API et la Push API permettent de proposer des notifications contextuelles et adéquates et ce même si le navigateur est fermé (grâce au Service Worker)
Responsive : l'utilisateur accède à votre application par différents périphériques, votre application doit faire de même et suivre l'utilisateur sur son téléphone, sa tablette ou son ordinateur (voire sa montre)
Sécurisée : les données de l'utilisateur sont précieuses et il faut s'en occuper comme il se doit. L'utilisation de HTTPS est indispensable pour le Service Worker, et donc pour les Progressive Web Apps
Disponible sur l'écran d'accueil : votre application doit être proche de l'utilisateur, il doit pouvoir y accéder depuis l'écran d'accueil de son téléphone, comme une application native.

Une Progressive Web App n'est au final qu'une Web App qui va associer le meilleur du web avec le meilleur des applications natives.

Polymer App Toolbox

Pour simplifier la création de Progressive Web Apps à partir de web components tout en permettant aux développeurs d'avoir un pattern à suivre, la team Polymer a développé conjointement à la Polymer Library un outil : la Polymer App Toolbox. Cette boite à outil comporte une collection de composants, d'outils et de templates qui tirent parti des puissantes fonctionnalités de la plate-forme web. La Polymer App Toolbox propose de créer des Progressive Web App ayant les fonctionnalités suivantes :

Une architecture component-based qui utilise Polymer et les web components.
Une application responsive design en utilisant les app-layout components (des web components créé par la team Polymer tels qu'un menu latéral comme sur les applications natives, chose qui n'existe pas en HTML de base).
Un routage modulaire basé sur les web components en utilisant les <app-route> components.
Un service de traduction (localization) avec le composant <app-localize-behavior>.
Le support du stockage local avec les app-storage components.
La gestion du cache hors-ligne en utilisant les Service Workers.
Un outil de build qui permet de servir l'application de plusieurs façons : une version unbundled pour servir l'appli avec du HTTP/2 + Server Push et une version bundled pour servir avec du HTTP/1.

Rendre disponible Progressive Web App de la bonne manière

Maintenant que notre Progressive Web App a été créée à l'aide des technologies offertes par le Polymer Project, il faut encore la publier pour la rendre accessible à ses futurs utilisateurs. Et pour se faire, il est essentiel de se rappeler des problématiques du mobile web énoncés plus tôt : Les connexions et les appareils lents sont la norme. Il est donc nécessaire d'utiliser le moins possible de JavaScript afin d'avoir une efficacité maximale. L'utilisateur doit pouvoir être capable d'interagir très rapidement avec notre application, cette première interaction ne devant pas être une attente sur un splash-screen (un écran de chargement) mais bien une vraie interaction avec l'application.

Pour réussir à obtenir ce résultat, nous n'allons pas utiliser la méthode classique qui consiste à simplement utiliser le serveur pour pré-calculer le rendu de notre application afin qu'un premier rendu soit affiché le temps que tout le framework soit téléchargé. Nous allons une fois de plus utiliser la puissance des dernières fonctionnalités de la plate-forme web afin d'obtenir un maximum de performance avec un temps de chargement minimal. Parmi ces fonctionnalités, on en retrouve 3 principales :

Les web components, qui permettent de construire des applications composées de dépendances granulaires.
Le protocole HTTP/2 et le Server Push, qui permettent de servir ces dépendances granulaires de la bonne manière afin de mieux utiliser la bande passante.
Le Service Worker qui permet de mettre en cache ces composants granulaires sur l'appareil de l'utilisateur.

Donc, nous allons jeter un coup d'œil à la façon dont ces trois primitives fonctionnent ensemble. Disons que nous construisons une application de type e-commerce. Nous avons trois routes : /, /items et /cart. Chacune de ses routes a une vue et chaque vue partage certains composants d'interface avec les autres vues. Si on voulait faire cette application de façon classique, pour chacune de ses routes, peu importe la vue à laquelle l'utilisateur voudrait accéder, nous aurions ce gros bloc contenant une page index.html, un fichier app.js contenant toute la logique de l'application, un fichier framework.js contenant tout le framework et un fichier CSS. Le serveur enverrait tout ce gros bloc d'un coup au client et une fois ce bloc reçu, le framework démarrerait alors pour commencer à rendre l'application. Ce serait ensuite au tour de l’application qui mettrait en place le mécanisme de routage afin de dessiner la bonne vue pour que l'utilisateur puisse enfin interagir avec l'application. Cette façon de faire est, vous l'aurez compris, extrêmement lente et inefficace.

Pour mieux comprendre la nouvelle façon de penser l'application, il faut revenir un peu en arrière pour prendre de la hauteur. Nous avons donc trois vues. Certains éléments graphiques sont partagés entre les différentes vues, d'autres non. Nous allons utiliser la puissance de la plateforme web pour servir cette application aussi efficacement que possible. On va donc décomposer chaque vue selon les web components dont elle est composée. On s'aperçoit alors que certains web components sont partagés entre les vues et d'autres non, de la même façon que les éléments graphiques décrits juste avant. Imaginons que l'utilisateur veuille accéder à l'accueil de l'application et demande donc la route /. Grâce au protocole HTTP/2 et au Server Push, le serveur va être capable de connaître exactement quels web components sont nécessaires pour rendre cette vue, et la rendre directement utilisable par l'utilisateur. Le strict minimum sera alors envoyé par le serveur afin de permettre à l'utilisateur d'interagir quasi instantanément avec l'application.

Maintenant que nous avons une première vue sur laquelle l'utilisateur peut interagir, nous pouvons mettre en cache tous les composants qu'on vient de télécharger grâce au Service Worker. On peut même par la suite commencer à récupérer en arrière-plan les composants restants qui seront utilisés dans les autres vues afin de les mettre en cache avant d’accéder à celles-ci. De cette façon, si l'utilisateur essaie d'accéder à la prochaine vue, par exemple /items, il y a de grandes chances que tous les composants nécessaires pour afficher cette vue et la rendre interactive soient déjà dans le cache du Service Worker. Si c'est le cas, le chargement de la vue sera instantané et l'utilisateur n'aura même pas besoin d'un accès réseau pour l’afficher. Bien évidemment, ce n'est pas toujours utile de mettre en cache chaque web component de l'ensemble de l'application. C'est pour cela qu'un système de lazy-load ce ces composants est également mis en place. Ainsi, le serveur pourra envoyer au client uniquement les dépendances manquantes pour afficher une vue donnée encore une fois grâce au protocole HTTP/2 et au Service Worker.

Un nouveau pattern

On voit donc bien qu'il y a vraiment une nouvelle façon de faire et qu'un nouveau pattern semble émerger.

Pusher les composants nécessaires pour la première vue
Rendre la première vue dès que possible
Pré-cache les composants pour les routes principales restantes
Lazy-loader les composants des autres routes quand l'utilisateur tente d'y accéder

Ce pattern, la team Polymer l’a identifié comme étant le PRPL (prononcé "Purple") pattern. Et ce qui est bien avec ce pattern c'est que même s’il est très bien adapté à Polymer, il peut aussi être appliqué à d'autre frameworks étant donné qu'il utilise uniquement la plate-forme web qui est la base de tout développement web. Il s'agit uniquement d'un pattern pour charger et rendre progressivement des progressives web app modernes qui utilise les dernières fonctionnalités de la plateforme web.

Pour aller plus loin

Le site Web du projet Polymer

VT2016 Polymer

Contents