Depuis 1989, le Web fait régulièrement la course avec d'autres plateformes et technologies propriétaires. Cela nous a conduit à la révolution AJAX, le standard HTML5 et plus récemment au Responsive Web Design. Les "Progressive Web Apps" sont la nouvelle approche proposée par les éditeurs de navigateurs.

Qu’est qu’une Progressive Web App ?

Le terme est récent et a été introduit en juin 2015 par Alex Russel (Google) dans son article : Progressive Web Apps: Escaping Tabs Without Losing Our Soul. Il y définit l’ensemble des critères qui définissent une Progressive Web App. Depuis, le concept a fait son chemin et il est maintenant poussé par Chrome, Firefox et Opera.

Une Progressive Web App commence sa vie comme n’importe quel autre site Web. On entre une adresse ou on clique sur un lien et le navigateur charge une page HTML dans un onglet. La grosse différence est que ce site Web va pouvoir tirer partie de plusieurs futurs standards comme les Service Workers ou les Web App Manifests. Dans les navigateurs qui le supportent, les utilisateurs bénéficieront ainsi de beaucoup d’avantages jusqu’ici réservées aux applications natives et hybrides :

• Gestion des connexions lentes et le hors-ligne,
• Réception des messages push,
• Affichage des notifications,
• Synchronisation des données en arrière plan,
• Ajout à l'écran d’accueil.

De plus, une Progressive Web App évite aux utilisateurs les inconvénients des applications natives en se basant sur ce qui fait la force du Web depuis 26 ans :

• Les liens hypertextes,
• Des technologies standards et rétro-compatibles,
• Pas de téléchargement préalable avant utilisation,
• Pas d’installation explicite avec plein de permissions à accepter,
• Pas de magasin d’applications contrôlés par des géants.

D’après les dernières statistiques de Google, un possesseur de smartphone n’utilise que 25 applications (moyenne mensuelle). En comparaison sur la même période, il aura déjà visité plus d’une centaine de site Web différents. De plus, la majeure partie du temps passé sur ces applications se fait sur le top 4 : emails, SMS, réseaux sociaux et jeu.

Le modèle des applications natives à installer commence à atteindre une limite critique. Demain, une start-up ou une DSI ne pourront plus miser uniquement sur un développement natif ou hybride. Les utilisateurs n’ont pas forcément le temps, la place ou l’intérêt d’installer une énième application sur leur téléphone. C’est encore plus remarquable dans certains pays émergents où les connexions et les smartphones ne sont pas du tout les mêmes qu’en Europe.

Les Service Workers : le socle indispensable

Pour répondre à toutes les caractéristiques d’une Progressive Web App, la principale technologie à mettre en place, ce sont les Service Workers. Il s’agit d’un futur standard W3C actuellement en préparation qui donne aux développeurs Web, une API bas niveau pour gérer les mauvaises connexions et les environnements hors-ligne.

Un Service Worker peut être comparé à un proxy cache qui se trouve côté client. Son comportement est programmé dans un fichier JavaScript qui s’installe dans le navigateur de l’utilisateur au premier chargement du site. Il s’exécute aux chargements suivants dans un thread indépendant des onglets ouverts sur le site. Au sein du Service Worker, il est possible d’intercepter toutes les requêtes HTTP et de renvoyer n’importe quelle réponse. Celle-ci peut provenir du réseau, d’un cache dédié et peut même être générée à la volée. C’est pourquoi les Service Workers ne fonctionnent que sur les sites sécurisés avec HTTPS.

Côté performances, le gain est indéniable. Le concept de Progressive Web App propose une approche "coquille" + contenu. Après un premier chargement, la "coquille" composée des éléments graphiques qui changent très peu (menus, icônes, barres d’outils…​) peut s’afficher instantanément depuis le cache dédié. Il reste ensuite à déterminer la meilleure stratégie pour le chargement du contenu demandé par l’utilisateur. Faut-il charger instantanément depuis le cache ou faire attendre l’utilisateur en chargeant depuis le réseau ? La bonne "recette" dépendra beaucoup du métier et de la nature des données mais plusieurs conseils sont déjà disponibles dans cet article de Jake Archibald.

Les Service Workers : une technologie qui bouge

Les possibilités offertes par cette technologie ne s’arrêtent pas à l’interception des appels réseau et à la gestion des connexions lentes. Une fois qu’on a posé les bases tout est possible. Le fonctionnement des Service Workers repose sur l’exécution d’un thread en arrière plan qui reçoit un événement dès qu’une page du site fait une requête HTTP. Si aucune page ne fait de requête, le navigateur endort le thread pour économiser de la batterie. Si l’utilisateur se rend sur une autre page du site, la page tente de faire une requête HTTP. Le navigateur va donc réveiller le thread du Service Worker en lui envoyant un événement pour qu’il exécute le code nécessaire au traitement de la requête.

C’est grâce aux Service Workers et à ce modèle de thread en arrière plan que d’autres APIs ont vu le jour. C’est le cas de la Push API notamment utilisée par Facebook sur sa version Web mobile qui permet de s’affranchir d’une application native pour recevoir des notifications push. Quand Facebook envoie un message push pour notifier d’une demande d’ami ou d’un nouveau message, le navigateur réveille le thread du Service Worker qui décide de l’issue à donner à cet événement : afficher une notification, mettre à jour le cache…​

D’autres APIs se basant sur les Service Workers sont en réflexion. Parmi ces discussions, du Geofencing mais aussi des interactions avec les objets connectés via le futur Web Bluetooth.

Une nouvelle manière de développer pour le Web

L’arrivée des Service Workers et le concept de Progressive Web Apps vont changer notre manière de développer pour le Web.

Côté système, l’adoption d’HTTPS va accélérer. C’est un point indispensable pour les Service Workers mais aussi pour d’autres technologies comme HTTP2. Le succès grandissant de l’initiative Let Encrypt (encore en beta) promet une belle progression en 2016 sur ce point.

Côté développeurs, nous allons voir passer deux phases : expérimentation puis démocratisation. La première phase d’expérimentations en tout genre a déjà commencé. Elle est indispensable pour identifier les bonnes pratiques et les anti-patterns. À ce stade, les premiers articles, librairies et autres outils apparaissent. Pour la phase de démocratisation, il faudra attendre une intégration dans les frameworks Web. Polymer propose déjà des fonctionnalités se basant sur les Service Workers mais du côté d’Angular, de React ou d’Ember, cela risque du temps.

Côté utilisateur, il va falloir s’habituer à ne plus installer une application native pour tout. Il faudra envisager qu’un simple site peut progressivement devenir une application Web digne de ce nom en s’ajoutant à l'écran d’accueil, en fonctionnant en mode hors-ligne et en recevant des notifications push.

Le support des Service Workers est déjà présent sur Chrome, Opera et bientôt sur Firefox (janvier 2016). Côté Safari et IE/Edge, il faudra attendre mais ce n’est pas grave, au contraire. La nature même d’une Progressive Web Apps, c’est d’appliquer le pattern amélioration progressive. Ainsi avec un seul développement, on obtient un site Web classique qui fonctionne sur différents navigateurs (mobile, desktop…​) et qui propose une expérience plus riche (proche du natif) sur les navigateurs les plus en avance.

Surveillez cela de près ou de loin mais ce n’est pas la dernière fois que vous en entendrez parler.