Guide du débutant sur les applications Web progressives

Les applications Web progressives pourraient être la prochaine grande nouveauté pour le Web mobile. Proposés à l'origine par Google en 2015, ils ont déjà beaucoup attiré l'attention en raison de la relative facilité de développement et des gains quasi instantanés pour l'expérience utilisateur de l'application.

Lectures complémentaires sur SmashingMag :

• Les éléments de base des applications Web progressives
• Conversational Design Essentials : Conseils pour créer un chatbot
• Créer une application de première classe qui tire parti de votre site Web
• Création d'une application Web complète dans Foundation for Apps

Une application Web évolutive tire parti des dernières technologies pour combiner le meilleur des applications Web et mobiles . Considérez-le comme un site Web construit à l'aide de technologies Web, mais qui agit et se sent comme une application. Les avancées récentes dans le navigateur et dans la disponibilité des agents de service et dans les API Cache et Push ont permis aux développeurs Web de permettre aux utilisateurs d'installer des applications Web sur leur écran d'accueil, de recevoir des notifications push et même de travailler hors ligne.

Les applications Web progressives tirent parti de l'écosystème Web, des plugins et de la communauté beaucoup plus vastes et de la relative facilité de déploiement et de maintenance d'un site Web par rapport à une application native dans les magasins d'applications respectifs. Pour ceux d'entre vous qui développent à la fois sur mobile et sur le Web, vous apprécierez qu'un site Web peut être construit en moins de temps, qu'une API n'a pas besoin d'être maintenue avec une rétrocompatibilité (tous les utilisateurs exécuteront la même version de votre site Web code, contrairement à la fragmentation des versions des applications natives) et que l' application sera généralement plus facile à déployer et à maintenir .

Pourquoi les Progressive Web Apps ?

Une étude a montré qu'en moyenne, une application perd 20 % de ses utilisateurs à chaque étape entre le premier contact de l'utilisateur avec l'application et le début de l'utilisation de l'application. Un utilisateur doit d'abord trouver l'application dans une boutique d'applications, la télécharger, l'installer puis, enfin, l'ouvrir. Lorsqu'un utilisateur trouvera votre application Web progressive, il pourra immédiatement commencer à l'utiliser, éliminant ainsi les étapes inutiles de téléchargement et d'installation. Et lorsque l'utilisateur reviendra dans l'application, il sera invité à installer l'application et à passer à une expérience en plein écran.

Cependant, une application native n'est certainement pas mauvaise du tout. Les applications mobiles avec notifications push obtiennent jusqu'à trois fois plus de rétention que leurs homologues sans push, et un utilisateur est trois fois plus susceptible de rouvrir une application mobile qu'un site Web. De plus, une application mobile bien conçue consomme moins de données et est beaucoup plus rapide car certaines ressources résident sur l'appareil.

Une application Web progressive tire parti des caractéristiques d'une application mobile, ce qui améliore la rétention des utilisateurs et les performances, sans les complications liées à la maintenance d'une application mobile.

Cas d'utilisation

Quand devez-vous créer une application Web progressive ? Native est généralement recommandée pour les applications auxquelles vous vous attendez à ce que les utilisateurs reviennent fréquemment, et une application Web progressive n'est pas différente. Flipkart utilise une application Web progressive pour sa plate-forme de commerce électronique populaire, Flipkart Lite, et les CFF utilisent une application Web progressive pour leur processus d'enregistrement en ligne, permettant aux utilisateurs d'accéder à leurs billets sans connexion Internet.

Lorsque vous évaluez si votre prochaine application doit être une application Web progressive, un site Web ou une application mobile native, identifiez d'abord vos utilisateurs et les actions les plus importantes de l'utilisateur. Étant « progressive », une application Web progressive fonctionne dans tous les navigateurs, et l'expérience est améliorée chaque fois que le navigateur de l'utilisateur est mis à jour avec des fonctionnalités et des API nouvelles et améliorées.

Ainsi, il n'y a aucun compromis dans l'expérience utilisateur avec une application web progressive par rapport à un site web traditionnel ; cependant, vous devrez peut-être décider quelles fonctionnalités prendre en charge hors ligne et vous devrez faciliter la navigation (rappelez-vous qu'en mode autonome, l'utilisateur n'a pas accès au bouton de retour). Si votre site Web possède déjà une interface de type application, l'application des concepts d'applications Web progressives ne fera que le rendre meilleur .

Si certaines fonctionnalités sont requises pour les actions critiques des utilisateurs mais ne sont pas encore disponibles en raison d'un manque de prise en charge de plusieurs navigateurs, une application mobile native peut être la meilleure option, garantissant la même expérience pour tous les utilisateurs.

Caractéristiques d'une application Web progressive

Avant de nous lancer dans le code, il est important de comprendre que les applications Web progressives ont les caractéristiques suivantes :

• Progressif . Par définition, une application Web progressive doit fonctionner sur n'importe quel appareil et s'améliorer progressivement, en tirant parti de toutes les fonctionnalités disponibles sur l'appareil et le navigateur de l'utilisateur.
• Découvrable . Parce qu'une application Web progressive est un site Web, elle doit être visible dans les moteurs de recherche. Il s'agit d'un avantage majeur par rapport aux applications natives, qui sont encore à la traîne des sites Web en termes de capacité de recherche.
• Liable . Autre caractéristique héritée des sites Web, un site Web bien conçu doit utiliser l'URI pour indiquer l'état actuel de l'application. Cela permettra à l'application Web de conserver ou de recharger son état lorsque l'utilisateur marque ou partage l'URL de l'application.
• Réactif . L'interface utilisateur d'une application Web progressive doit s'adapter au facteur de forme et à la taille de l'écran de l'appareil.
• App-like . Une application Web progressive doit ressembler à une application native et être construite sur le modèle de shell d'application, avec des actualisations de page minimales.
• Indépendant de la connectivité . Cela devrait fonctionner dans les zones de faible connectivité ou hors ligne (notre caractéristique préférée).
• Réenclenchable . Les utilisateurs d'applications mobiles sont plus susceptibles de réutiliser leurs applications, et les applications Web progressives sont destinées à atteindre les mêmes objectifs grâce à des fonctionnalités telles que les notifications push.
• Installable . Une application Web progressive peut être installée sur l'écran d'accueil de l'appareil, ce qui la rend facilement disponible.
• Frais . Lorsqu'un nouveau contenu est publié et que l'utilisateur est connecté à Internet, ce contenu doit être mis à disposition dans l'application.
• Coffre -fort. Étant donné qu'une application Web progressive offre une expérience utilisateur plus intime et que toutes les requêtes réseau peuvent être interceptées par les techniciens de service, il est impératif que l'application soit hébergée sur HTTPS pour empêcher les attaques de l'homme du milieu.

Codez !

Notre première application Web progressive, Sky High, simulera l'horaire des arrivées d'un aéroport. La première fois que l'utilisateur accède à notre application Web, nous souhaitons lui montrer une liste des vols à venir, extraite d'une API. Si l'utilisateur n'a pas de connexion Internet et qu'il recharge l'application Web, nous voulons lui montrer l'horaire de vol tel qu'il était lors de son dernier téléchargement avec une connexion.

Les bases

La première caractéristique d'une application Web progressive est qu'elle doit fonctionner sur tous les appareils et doit s'améliorer sur les appareils et les navigateurs qui le permettent. Par conséquent, nous avons construit notre site Web en utilisant le HTML5 traditionnel et avec JavaScript qui simule la récupération de données à partir d'une API factice. Tout au long de l'application, nous utilisons de petits morceaux de Knockout pour gérer nos liaisons Model-View-ViewModel (MVVM) - un framework JavaScript léger qui nous permet de lier nos modèles JavaScript à nos vues HTML. Nous avons choisi d'utiliser Knockout car il est relativement simple à comprendre et n'encombre pas le code ; Cependant, vous pouvez le remplacer par tout autre framework, tel que React ou AngularJS.

Notre site Web suit les directives de conception matérielle de Google, un ensemble de principes qui guident la conception et l'interaction. La conception des matériaux sert non seulement de norme unifiée pour les applications et les appareils, mais donne également un sens à la conception. Nous avons utilisé la conception matérielle pour la vue des arrivées de Sky High afin de donner à notre application Web progressive l'apparence d'une application native.

Enfin, nous avons testé notre application pour nous assurer qu'elle est sans à-coups et que le défilement est fluide. Il a été démontré que le rendu sans Jank améliore l'engagement des utilisateurs. Visez un rendu de 60 images par seconde.

Pour cette démo, nous allons récupérer un fichier JSON statique, au lieu d'une véritable API. C'est simplement pour garder les choses simples. Dans le monde réel, vous interrogeriez une API ou utiliseriez WebSockets.

index.html

 <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Sky-High Airport Arrivals</title> <link async rel="stylesheet" href="./css/style.css"> <link href="https://fonts.googleapis.com/css?family=Roboto:300,600,300italic,600italic" rel="stylesheet" type="text/css"> </head> <body> <header> <div class="content"> <h3>Arrivals</h3> </div> </header> <div class="container"> <div class="content"> <ul class="arrivals-list" data-bind="foreach: arrivals"> <li class="item"> <span class="title" data-bind="html: title"></span> <span class="status" data-bind="html: status"></span> <span class="time" data-bind="html: time"></span> </li> </ul> </div> </div> <script src="./js/build/vendor.min.js"></script> <script src="./js/build/script.min.js"></script> </body> </html>
<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Sky-High Airport Arrivals</title> <link async rel="stylesheet" href="./css/style.css"> <link href="https://fonts.googleapis.com/css?family=Roboto:300,600,300italic,600italic" rel="stylesheet" type="text/css"> </head> <body> <header> <div class="content"> <h3>Arrivals</h3> </div> </header> <div class="container"> <div class="content"> <ul class="arrivals-list" data-bind="foreach: arrivals"> <li class="item"> <span class="title" data-bind="html: title"></span> <span class="status" data-bind="html: status"></span> <span class="time" data-bind="html: time"></span> </li> </ul> </div> </div> <script src="./js/build/vendor.min.js"></script> <script src="./js/build/script.min.js"></script> </body> </html>

Le fichier index.html est relativement standard. Nous avons créé une liste HTML et y avons lié les arrivals de notre propriété View Model à l'aide de Knockout, via l'attribut data-bind=“foreach: arrivals” . Les arrivals du modèle de vue sont déclarées dans le fichier page.js ci-dessous et exposées dans le module Page . Sur notre page HTML, pour chaque élément du tableau des arrivals , nous avons lié les title , status et time à la vue HTML.

page.js

 (var Page = (function() { // declare the view model used within the page function ViewModel() { var self = this; self.arrivals = ko.observableArray([]); } // expose the view model through the Page module return { vm: new ViewModel(), hideOfflineWarning: function() { // enable the live data document.querySelector(".arrivals-list").classList.remove('loading') // remove the offline message document.getElementById("offline").remove(); // load the live data }, showOfflineWarning: function() { // disable the live data document.querySelector(".arrivals-list").classList.add('loading') // load html template informing the user they are offline var request = new XMLHttpRequest(); request.open('GET', './offline.html', true); request.onload = function() { if (request.status === 200) { // success // create offline element with HTML loaded from offline.html template var offlineMessageElement = document.createElement("div"); offlineMessageElement.setAttribute("id", "offline"); offlineMessageElement.innerHTML = request.responseText; document.getElementById("main").appendChild(offlineMessageElement); } else { // error retrieving file console.warn('Error retrieving offline.html'); } }; request.onerror = function() { // network errors console.error('Connection error'); }; request.send(); } } })();

Ce fichier page.js expose le module Page , qui contient notre vm ViewModel et deux fonctions, hideOfflineWarning et showOfflineWarning . Le modèle de vue ViewModel est un littéral JavaScript simple qui sera utilisé dans toute l'application. La propriété qui arrive sur le arrivals est observableArray de Knockout, qui lie automatiquement notre code HTML à un tableau JavaScript, nous permettant de pousser et de faire apparaître des éléments sur notre tableau en JavaScript et de mettre à jour automatiquement le code HTML de la page.

Les fonctions hideOfflineWarning et showOfflineWarning permettent au reste de notre application d'appeler ces fonctions pour mettre à jour l'interface utilisateur de la page qui indique si nous sommes connectés en ligne. Le showOfflineWarning ajoute une classe de loading à notre élément HTML arrivals arrivals-list pour faire disparaître la liste, puis il récupère le fichier HTML offline.html via XHR. En supposant que le fichier a été récupéré avec succès ( response.status === 200 ), nous l'ajoutons à notre code HTML. Bien sûr, si nous n'utilisons pas de service workers et que l'utilisateur n'est pas connecté à Internet, il ne serait pas possible de récupérer offline.html , et l'utilisateur verrait donc la page hors ligne du navigateur.

La logique métier à partir de laquelle nous récupérons les données de notre API et les lions à nos modèles de vue et à nos vues se trouve dans arrivals.js et est une fonctionnalité MVVM standard utilisant Knockout. Dans le fichier arrivals.js , nous initialisons simplement les services et les modèles de vue que nous utiliserons dans l'application, et nous exposons une fonction - Arrivals.loadData() - qui récupère les données et les lie au modèle de vue.

Manifeste d'application Web

Faisons en sorte que notre application Web ressemble davantage à une application. Un fichier manifeste d'application Web est un simple fichier JSON qui suit les spécifications du W3C. Avec elle, il est possible d'exécuter l'application Web en mode plein écran en tant qu'application autonome, d'attribuer une icône qui s'affichera lorsque l'application sera installée sur l'appareil et d'attribuer un thème et une couleur d'arrière-plan à l'application. De plus, Chrome sur Android proposera de manière proactive à l'utilisateur d'installer l'application Web, via une bannière d'installation d'application Web. Pour afficher l'invite d'installation, votre application Web doit :

• avoir un fichier manifeste d'application Web valide,
• être servi sur HTTPS,
• avoir un travailleur de service valide enregistré,
• ont été visités deux fois, avec au moins cinq minutes entre chaque visite.

manifeste.json

 { "short_name": "Arrivals", "name": "Arrivals at Sky High", "description": "Progressive web application demonstration", "icons": [ { "src": "launcher-icon.png", "sizes": "48x48", "type": "image/png" }, { "src": "launcher-icon-96.png", "sizes": "96x96", "type": "image/png" }, { "src": "launcher-icon-144.png", "sizes": "144x144", "type": "image/png" }, { "src": "launcher-icon-192.png", "sizes": "192x192", "type": "image/png" }, { "src": "launcher-icon-256.png", "sizes": "256x256", "type": "image/png" } ], "start_url": "./?utm_source=web_app_manifest", "display": "standalone", "orientation": "portrait", "theme_color": "#29BDBB", "background_color": "#29BDBB" }

Décomposons ce fichier manifeste :

• short_name est un nom lisible pour l'application. Dans Chrome pour Android, c'est aussi le nom qui accompagne l'icône sur l'écran d'accueil.
• name est également un nom lisible pour l'application et définit comment l'application sera répertoriée.
• description fournit une description générale de l'application Web.
• icons définit un tableau d'images de différentes tailles qui serviront de jeu d'icônes de l'application. Dans Chrome pour Android, l'icône sera utilisée sur l'écran de démarrage, sur l'écran d'accueil et dans le sélecteur de tâches.
• start_url est l'URL de démarrage de l'application.
• display définit le mode d'affichage par défaut de l'application web : fullscreen , standalone , minimal-ui ou browser .
• orientation définit l'orientation par défaut de l'application Web : portrait ou landscape .
• theme_color est la couleur de thème par défaut pour l'application. Sur Android, cela est également utilisé pour colorer la barre d'état.
• background_color définit la couleur d'arrière-plan de l'application Web. Dans Chrome, il définit également la couleur d'arrière-plan de l'écran de démarrage.
• related_applications n'est pas implémenté dans notre exemple mais est utilisé pour spécifier des alternatives d'applications natives dans les différents magasins d'applications.

Ajoutez la référence manifest.json à la balise head du fichier index.html :

 <link rel="manifest" href="./manifest.json">

Une fois qu'un utilisateur a ajouté l'application Web à son écran d'accueil, il pourra se réengager avec votre application immédiatement depuis son appareil, sans avoir à ouvrir directement le navigateur. Vous pouvez voir à quel point il s'agit de bien plus qu'un signet Web.

Ajouter à l'écran d'accueil sur Chrome pour Android à partir de Smashing Magazine sur Vimeo.

Travailleurs des services

L'un des aspects les plus excitants des applications Web progressives est qu'elles peuvent fonctionner hors ligne. En utilisant les service workers, il est possible d'afficher les données qui ont été récupérées dans les sessions précédentes de l'application (en utilisant IndexedDB) ou, alternativement, d'afficher le shell de l'application et d'informer l'utilisateur qu'il n'est pas connecté à Internet (l'approche que nous avons prises dans cette démo). Une fois l'utilisateur reconnecté, nous pouvons alors récupérer les dernières données du serveur.

Tout cela est possible grâce aux service workers, qui sont des scripts pilotés par les événements (écrits en JavaScript) qui ont accès aux événements à l'échelle du domaine, y compris les extractions de réseau. Avec eux, nous pouvons mettre en cache toutes les ressources statiques, ce qui pourrait réduire considérablement les requêtes réseau et améliorer considérablement les performances également.

Shell d'application

Le shell de l'application est le minimum de HTML, CSS et JavaScript requis pour alimenter une interface utilisateur. Une application mobile native inclut le shell de l'application dans le cadre de sa distribution, alors que les sites Web le demandent généralement sur le réseau. Les applications Web progressives comblent cet écart en plaçant les ressources et les actifs du shell de l'application dans le cache du navigateur. Dans notre application Sky High, nous pouvons voir que notre shell d'application se compose de la barre d'en-tête supérieure, des polices et de tout CSS requis pour les rendre élégamment.

Pour commencer avec les service workers, nous devons d'abord créer le fichier JavaScript de notre service worker, sw.js , placé dans le répertoire racine.

sw.js

 // Use a cacheName for cache versioning var cacheName = 'v1:static'; // During the installation phase, you'll usually want to cache static assets. self.addEventListener('install', function(e) { // Once the service worker is installed, go ahead and fetch the resources to make this work offline. e.waitUntil( caches.open(cacheName).then(function(cache) { return cache.addAll([ './', './css/style.css', './js/build/script.min.js', './js/build/vendor.min.js', './css/fonts/roboto.woff', './offline.html' ]).then(function() { self.skipWaiting(); }); }) ); }); // when the browser fetches a URL… self.addEventListener('fetch', function(event) { // … either respond with the cached object or go ahead and fetch the actual URL event.respondWith( caches.match(event.request).then(function(response) { if (response) { // retrieve from cache return response; } // fetch as normal return fetch(event.request); }) ); });

Regardons de plus près notre travailleur de service. Tout d'abord, nous définissons une variable cacheName . Ceci est utilisé pour déterminer si des modifications ont été apportées à nos actifs mis en cache. Pour cet exemple, nous utiliserons un nom statique, ce qui signifie que nos actifs ne changeront pas ou ne nécessiteront pas de mise à jour.

 self.addEventListener('install', function(e) { // declare which assets to cache }

L'événement d' install se déclenche pendant la phase d'installation de l'agent de service et ne se déclenchera qu'une seule fois si l'agent de service est déjà installé. Par conséquent, l'actualisation de la page ne déclenchera pas à nouveau la phase d'installation. Lors de la phase d'installation, nous sommes en mesure de déclarer quels actifs seront mis en cache. Dans notre exemple ci-dessus, nous mettons en cache un fichier CSS, deux fichiers JavaScript, notre fichier de polices, notre modèle HTML hors ligne et, bien sûr, la racine de l'application. self.skipWaiting() force le service worker en attente à devenir actif.

Jusqu'à présent, nous avons déclaré notre service worker, mais avant de le voir entrer en vigueur, nous devons le référencer dans notre JavaScript. Dans notre application, nous l'enregistrons dans main.js

 // Register the service worker if available. if ('serviceWorker' in navigator) { navigator.serviceWorker.register('./sw.js').then(function(reg) { console.log('Successfully registered service worker', reg); }).catch(function(err) { console.warn('Error whilst registering service worker', err); }); } window.addEventListener('online', function(e) { // Resync data with server. console.log("You are online"); Page.hideOfflineWarning(); Arrivals.loadData(); }, false); window.addEventListener('offline', function(e) { // Queue up events for server. console.log("You are offline"); Page.showOfflineWarning(); }, false); // Check if the user is connected. if (navigator.onLine) { Arrivals.loadData(); } else { // Show offline message Page.showOfflineWarning(); } // Set Knockout view model bindings. ko.applyBindings(Page.vm);

Nous avons également inclus deux écouteurs d'événements pour vérifier si l'état de la session est passé de online à offline ou vice versa. Les gestionnaires d'événements appellent ensuite les différentes fonctions pour récupérer les données via Arrivals.loadData() et pour activer ou désactiver le message hors ligne via Page.showOfflineWarning et Page.hideOfflineWarning , respectivement. Notre application vérifie également si l'utilisateur est actuellement en ligne, en utilisant navigator.onLine, et récupère les données ou affiche l'avertissement hors ligne en conséquence. Et dans la dernière ligne de main.js , nous appliquons les liaisons Knockout à notre View Model Page.vm .

Si nous chargeons notre application pour la première fois (avec Chrome Developer Tools), nous ne verrons rien de nouveau. Cependant, lors du rechargement, nous verrons qu'un certain nombre de ressources réseau ont été récupérées auprès du service worker. Ceci est notre shell d'application.

Test hors ligne

Un utilisateur exécutant l'application sans connexion Internet (en supposant qu'il ait déjà été sur la page) entraînera simplement l'affichage du shell de l'application et de l'avertissement hors ligne - une amélioration par rapport au t-rex rôdant de Chrome. Une fois que l'utilisateur a établi une connexion réseau, nous désactivons l'avertissement et récupérons les dernières données.

The Guardian adopte une approche particulièrement intéressante lorsque les utilisateurs hors ligne accèdent à son site Web, en proposant une grille de mots croisés :

Notifications push

Les notifications push permettent aux utilisateurs d'accepter les mises à jour opportunes des applications auxquelles ils font confiance, ce qui les aide à se réengager avec les applications. Les notifications push sur le Web vous permettent d'interagir avec votre public même lorsque le navigateur est fermé.

L'API Push est prise en charge dans Chrome, Opera et le navigateur de Samsung et est en cours de développement dans Firefox et Microsoft Edge. Malheureusement, rien n'indique que la fonctionnalité sera implémentée dans Safari.

Performance

L'un des gains les plus faciles avec les travailleurs de service est que nous pouvons améliorer les performances avec peu ou pas d'effort. Comparer notre site Web à lui-même avant la mise en œuvre des service workers, avant que nous ne récupérions plus de 200 Ko lors du chargement de la page ; qui est maintenant réduit à 13 Ko. Sur un réseau 3G classique, la page aurait mis 3,5 secondes à se charger ; maintenant cela prend 500 millisecondes.

Ces améliorations de performances sont drastiques car l'application elle-même est très petite et a des fonctionnalités limitées. Néanmoins, grâce à l'utilisation correcte de la mise en cache, il est possible d'améliorer considérablement les performances et les performances perçues, en particulier pour les utilisateurs dans des endroits à faible connectivité.

Phare

L'équipe Chrome de Google a mis au point un outil pour tester les applications Web progressives. Lighthouse s'exécute dans Node.js ou en tant que plugin Chrome et peut également être trouvé sur GitHub.

Pour exécuter un test Lighthouse, votre site Web doit être disponible en ligne, ce qui signifie que vous ne pouvez pas tester sur localhost .

Pour commencer, téléchargez le package npm :

 npm install -g GoogleChrome/lighthouse

Une fois installé, lancez Chrome (à partir de la version 52) :

 npm explore -g lighthouse -- npm run chrome lighthouse https://incredibleweb.github.io/pwa-tutorial/

La sortie de l'exécution de Lighthouse sera visible dans la ligne de commande et évaluera votre site Web en fonction des fonctionnalités et des propriétés de l'application Web progressive que vous avez implémentées, par exemple, si vous utilisez un fichier manifest.json ou si votre page est disponible hors connexion. .

Conclusion

Cet article est simplement un apéritif pour les applications Web progressives. Nous pourrions faire beaucoup plus pour créer l'expérience de type application que les utilisateurs recherchent, que ce soit en prenant en charge les notifications push avec l'API Push, en rendant l'application réactivable ou en utilisant IndexedDB et la synchronisation en arrière-plan pour améliorer l'expérience hors ligne.

Prise en charge de plusieurs navigateurs

Les applications Web progressives en sont encore à leurs débuts, et la prise en charge de plusieurs navigateurs est encore limitée, en particulier dans Safari et Edge. Cependant, Microsoft prend ouvertement en charge les applications Web progressives et devrait implémenter davantage de fonctionnalités d'ici la fin de l'année.

• Travailleurs de service et API de cache . Pris en charge dans Chrome, Firefox, Opera et le navigateur de Samsung. En développement dans Microsoft Edge, devrait être disponible fin 2016. A l'étude pour Safari.
• Ajouter à l'écran d'accueil . Pris en charge dans Chrome, Firefox, Opera, le navigateur Android et le navigateur de Samsung. Microsoft semble indiquer que les applications Web progressives seront disponibles en tant que listes de magasins. Pas de plans pour Safari pour le moment.
• Pousser l'API . Principalement pris en charge dans Chrome, Firefox, Opera et le navigateur de Samsung. En développement dans Microsoft Edge. Pas de plans pour Safari pour le moment.

Si davantage de développeurs tirent parti des fonctionnalités offertes par les applications Web progressives - qui sont relativement faciles à mettre en œuvre et offrent des récompenses immédiates -, les utilisateurs préféreront consommer ces applications Web dans les navigateurs pris en charge, en espérant convaincre les autres fournisseurs de navigateurs de s'adapter.

Code source

L'intégralité du code source de ce didacticiel est disponible dans un référentiel Github et la démonstration est disponible sur les pages GitHub.