Una guía para principiantes sobre aplicaciones web progresivas

Las aplicaciones web progresivas podrían ser el próximo gran avance para la web móvil. Propuestos originalmente por Google en 2015, ya han atraído mucha atención debido a la relativa facilidad de desarrollo y las ganancias casi instantáneas para la experiencia del usuario de la aplicación.

Lectura adicional en SmashingMag:

• Los componentes básicos de las aplicaciones web progresivas
• Elementos esenciales del diseño conversacional: consejos para construir un chatbot
• Creación de una aplicación de primera clase que aproveche su sitio web
• Creación de una aplicación web completa en Foundation For Apps

Una aplicación web progresiva aprovecha las últimas tecnologías para combinar lo mejor de las aplicaciones web y móviles . Piense en ello como un sitio web creado con tecnologías web pero que actúa y se siente como una aplicación. Los avances recientes en el navegador y en la disponibilidad de los trabajadores del servicio y en las API de caché y push han permitido a los desarrolladores web permitir a los usuarios instalar aplicaciones web en su pantalla de inicio, recibir notificaciones push e incluso trabajar sin conexión.

Las aplicaciones web progresivas aprovechan el ecosistema web, los complementos y la comunidad mucho más grandes y la relativa facilidad de implementar y mantener un sitio web en comparación con una aplicación nativa en las respectivas tiendas de aplicaciones. Aquellos de ustedes que desarrollan tanto en dispositivos móviles como en la web, apreciarán que se puede crear un sitio web en menos tiempo, que no es necesario mantener una API con compatibilidad con versiones anteriores (todos los usuarios ejecutarán la misma versión de su sitio web). código, a diferencia de la fragmentación de versiones de las aplicaciones nativas) y que , en general, la aplicación será más fácil de implementar y mantener .

¿Por qué aplicaciones web progresivas?

Un estudio ha demostrado que, en promedio, una aplicación pierde el 20% de sus usuarios por cada paso entre el primer contacto del usuario con la aplicación y el inicio del uso de la aplicación. Un usuario primero debe encontrar la aplicación en una tienda de aplicaciones, descargarla, instalarla y luego, finalmente, abrirla. Cuando un usuario encuentre su aplicación web progresiva, podrá comenzar a usarla de inmediato, eliminando las etapas innecesarias de descarga e instalación. Y cuando el usuario regrese a la aplicación, se le pedirá que la instale y actualice a una experiencia de pantalla completa.

Sin embargo, una aplicación nativa definitivamente no es del todo mala. Las aplicaciones móviles con notificaciones push logran hasta tres veces más retención que sus contrapartes sin push, y es tres veces más probable que un usuario vuelva a abrir una aplicación móvil que un sitio web. Además, una aplicación móvil bien diseñada consume menos datos y es mucho más rápida porque algunos recursos residen en el dispositivo.

Una aplicación web progresiva aprovecha las características de una aplicación móvil, lo que resulta en una mejor retención y rendimiento del usuario, sin las complicaciones que implica el mantenimiento de una aplicación móvil.

Casos de uso

¿Cuándo debería crear una aplicación web progresiva? Por lo general, se recomienda Native para aplicaciones a las que espera que los usuarios regresen con frecuencia, y una aplicación web progresiva no es diferente. Flipkart usa una aplicación web progresiva para su popular plataforma de comercio electrónico, Flipkart Lite, y SBB usa una aplicación web progresiva para su proceso de registro en línea, lo que permite a los usuarios acceder a sus boletos sin conexión a Internet.

Al evaluar si su próxima aplicación debe ser una aplicación web progresiva, un sitio web o una aplicación móvil nativa, primero identifique a sus usuarios y las acciones de los usuarios más importantes. Al ser "progresiva", una aplicación web progresiva funciona en todos los navegadores, y la experiencia mejora cada vez que el navegador del usuario se actualiza con funciones y API nuevas y mejoradas.

Por lo tanto, no hay compromiso en la experiencia del usuario con una aplicación web progresiva en comparación con un sitio web tradicional; sin embargo, es posible que deba decidir qué funcionalidad admitir sin conexión y deberá facilitar la navegación (recuerde que en el modo independiente, el usuario no tiene acceso al botón Atrás). Si su sitio web ya tiene una interfaz similar a una aplicación, la aplicación de los conceptos de aplicaciones web progresivas solo lo mejorará .

Si se requieren ciertas características para las acciones críticas del usuario, pero aún no están disponibles debido a la falta de compatibilidad entre navegadores, entonces una aplicación móvil nativa podría ser la mejor opción, garantizando la misma experiencia para todos los usuarios.

Características de una aplicación web progresiva

Antes de pasar al código, es importante comprender que las aplicaciones web progresivas tienen las siguientes características:

• progresivo Por definición, una aplicación web progresiva debe funcionar en cualquier dispositivo y mejorar progresivamente, aprovechando las funciones disponibles en el navegador y el dispositivo del usuario.
• Descubrible . Debido a que una aplicación web progresiva es un sitio web, debe ser visible en los motores de búsqueda. Esta es una gran ventaja sobre las aplicaciones nativas, que todavía van a la zaga de los sitios web en cuanto a capacidad de búsqueda.
• Enlazable . Como otra característica heredada de los sitios web, un sitio web bien diseñado debe utilizar la URI para indicar el estado actual de la aplicación. Esto permitirá que la aplicación web conserve o vuelva a cargar su estado cuando el usuario marque o comparta la URL de la aplicación.
• receptivo La interfaz de usuario de una aplicación web progresiva debe ajustarse al factor de forma y al tamaño de la pantalla del dispositivo.
• Similar a una aplicación . Una aplicación web progresiva debe parecerse a una aplicación nativa y estar construida sobre el modelo de shell de la aplicación, con actualizaciones de página mínimas.
• Independiente de la conectividad . Debería funcionar en áreas de baja conectividad o fuera de línea (nuestra característica favorita).
• Reconectable . Es más probable que los usuarios de aplicaciones móviles reutilicen sus aplicaciones, y las aplicaciones web progresivas están destinadas a lograr los mismos objetivos a través de funciones como las notificaciones automáticas.
• Instalable . Se puede instalar una aplicación web progresiva en la pantalla de inicio del dispositivo, lo que la hace fácilmente disponible.
• fresco Cuando se publica contenido nuevo y el usuario está conectado a Internet, ese contenido debe estar disponible en la aplicación.
• seguro Debido a que una aplicación web progresiva tiene una experiencia de usuario más íntima y debido a que todas las solicitudes de red pueden ser interceptadas a través de los trabajadores del servicio, es imperativo que la aplicación se aloje en HTTPS para evitar ataques de intermediarios.

¡Codifiquemos!

Nuestra primera aplicación web progresiva, Sky High, simulará el horario de llegadas de un aeropuerto. La primera vez que el usuario accede a nuestra aplicación web, queremos mostrarle una lista de próximos vuelos, recuperada de una API. Si el usuario no tiene conexión a Internet y recarga la web app, queremos mostrarle el horario de vuelo tal y como estaba la última vez que lo descargó con conexión.

Los basicos

La primera característica de una aplicación web progresiva es que debe funcionar en todos los dispositivos y debe mejorar en los dispositivos y navegadores que lo permitan. Por lo tanto, hemos construido nuestro sitio web usando HTML5 tradicional y con JavaScript que simula la recuperación de datos de una API simulada. A lo largo de la aplicación, usamos pequeños fragmentos de Knockout para manejar nuestros enlaces Model-View-ViewModel (MVVM), un marco JavaScript ligero que nos permite enlazar nuestros modelos JavaScript a nuestras vistas HTML. Elegimos usar Knockout porque es relativamente simple de entender y no abarrota el código; sin embargo, puede reemplazarlo con cualquier otro marco, como React o AngularJS.

Nuestro sitio web sigue las pautas de diseño de materiales de Google, un conjunto de principios que guían el diseño y la interacción. El diseño de materiales no solo sirve como un estándar unificado en todas las aplicaciones y dispositivos, sino que también le da significado al diseño. Usamos el diseño de materiales para la vista de llegadas de Sky High para darle a nuestra aplicación web progresiva esa apariencia y sensación de aplicación nativa.

Finalmente, probamos nuestra aplicación para asegurarnos de que esté libre de bloqueos y que el desplazamiento sea suave como la seda. Se ha demostrado que el renderizado sin bloqueos mejora la participación del usuario. Apunta a una renderización de 60 cuadros por segundo.

Para esta demostración, recuperaremos un archivo JSON estático, en lugar de una API real. Esto es simplemente para mantener las cosas simples. En el mundo real, consultaría una API o usaría WebSockets.

índice.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>

El archivo index.html es relativamente estándar. Creamos una lista HTML y vinculamos las arrivals de nuestra propiedad Ver modelo usando Knockout, a través del atributo data-bind=“foreach: arrivals” . Las arrivals del modelo de vista se declaran en el archivo page.js continuación y se exponen en el módulo de Page . En nuestra página HTML, para cada elemento de la matriz de arrivals , hemos vinculado las propiedades de title , status y time a la vista HTML.

página.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(); } } })();

Este archivo page.js expone el módulo Page , que contiene nuestra ViewModel vm y dos funciones, hideOfflineWarning y showOfflineWarning . El modelo de vista ViewModel es un literal de JavaScript simple que se usará en toda la aplicación. La arrivals de la propiedad en ViewModel es observableArray de Knockout, que vincula automáticamente nuestro HTML a una matriz de JavaScript, lo que nos permite insertar y abrir elementos en nuestra matriz en JavaScript y actualizar automáticamente el HTML de la página.

Las funciones hideOfflineWarning y showOfflineWarning permiten que el resto de nuestra aplicación llame a estas funciones para actualizar la interfaz de usuario de la página que muestra si estamos conectados en línea. El showOfflineWarning agrega una clase de loading a nuestro elemento HTML de la arrivals-list para atenuar la lista, y luego recupera el archivo HTML offline.html a través de XHR. Suponiendo que el archivo se haya recuperado correctamente ( response.status === 200 ), lo agregamos a nuestro HTML. Por supuesto, si no usamos trabajadores de servicio y el usuario no está conectado a Internet, entonces no sería posible recuperar offline.html y, por lo tanto, el usuario vería la página sin conexión del navegador.

La lógica comercial desde donde recuperamos los datos de nuestra API y los vinculamos a nuestros modelos de vista y vistas se encuentra en arrivals.js y es una funcionalidad estándar de MVVM que usa Knockout. En el archivo arrivals.js , simplemente inicializamos los servicios y los modelos de vista que usaremos en toda la aplicación, y exponemos una función, Arrivals.loadData() , que recupera los datos y los vincula al modelo de vista.

Manifiesto de la aplicación web

Hagamos que nuestra aplicación web se parezca más a una aplicación. Un archivo de manifiesto de aplicación web es un archivo JSON simple que sigue la especificación de W3C. Con él, es posible ejecutar la aplicación web en modo de pantalla completa como una aplicación independiente, asignar un ícono que se mostrará cuando la aplicación esté instalada en el dispositivo y asignar un tema y un color de fondo a la aplicación. Además, Chrome en Android sugerirá de manera proactiva que el usuario instale la aplicación web a través de un banner de instalación de la aplicación web. Para mostrar el mensaje de instalación, su aplicación web debe:

• tener un archivo de manifiesto de aplicación web válido,
• ser servido a través de HTTPS,
• tener un trabajador de servicio válido registrado,
• han sido visitados dos veces, con al menos cinco minutos entre cada visita.

manifiesto.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" }

Analicemos este archivo de manifiesto:

• short_name es un nombre legible por humanos para la aplicación. En Chrome para Android, este también es el nombre que acompaña al ícono en la pantalla de inicio.
• name también es un nombre legible por humanos para la aplicación y define cómo se listará la aplicación.
• description proporciona una descripción general de la aplicación web.
• icons define una serie de imágenes de diferentes tamaños que servirán como conjunto de iconos de la aplicación. En Chrome para Android, el ícono se usará en la pantalla de bienvenida, en la pantalla de inicio y en el selector de tareas.
• start_url es la URL de inicio de la aplicación.
• display define el modo de visualización predeterminado para la aplicación web: fullscreen , standalone , minimal-ui o browser .
• La orientation define la orientación predeterminada para la aplicación web: portrait u landscape .
• theme_color es el color del tema predeterminado para la aplicación. En Android, esto también se usa para colorear la barra de estado.
• background_color define el color de fondo de la aplicación web. En Chrome, también define el color de fondo de la pantalla de inicio.
• related_applications no están implementadas en nuestro ejemplo, pero se usan para especificar alternativas de aplicaciones nativas en las distintas tiendas de aplicaciones.

Agregue la referencia manifest.json a la etiqueta head del archivo index.html :

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

Una vez que un usuario haya agregado la aplicación web a su pantalla de inicio, podrá volver a interactuar con su aplicación inmediatamente desde su dispositivo, sin tener que abrir directamente el navegador. Puedes ver cómo esto es mucho más que un marcador web.

Agregar a la pantalla de inicio en Chrome para Android de Smashing Magazine en Vimeo.

Trabajadores de servicios

Uno de los aspectos más emocionantes de las aplicaciones web progresivas es que pueden funcionar sin conexión. Con los trabajadores del servicio, es posible mostrar datos que se recuperaron en sesiones anteriores de la aplicación (usando IndexedDB) o, alternativamente, mostrar el shell de la aplicación e informar al usuario que no está conectado a Internet (el enfoque que hemos tomado en esta demostración). Una vez que el usuario se vuelve a conectar, podemos recuperar los datos más recientes del servidor.

Todo esto es posible a través de los trabajadores del servicio, que son scripts controlados por eventos (escritos en JavaScript) que tienen acceso a eventos de todo el dominio, incluidas las recuperaciones de red. Con ellos, podemos almacenar en caché todos los recursos estáticos, lo que podría reducir drásticamente las solicitudes de red y también mejorar considerablemente el rendimiento.

Carcasa de la aplicación

El shell de la aplicación es el HTML, CSS y JavaScript mínimos necesarios para impulsar una interfaz de usuario. Una aplicación móvil nativa incluye el shell de la aplicación como parte de su distribuible, mientras que los sitios web normalmente lo solicitan a través de la red. Las aplicaciones web progresivas cierran esta brecha colocando los recursos y activos del shell de la aplicación en la memoria caché del navegador. En nuestra aplicación Sky High, podemos ver que el shell de nuestra aplicación consta de la barra de encabezado superior, las fuentes y cualquier CSS necesario para representarlas con elegancia.

Para comenzar con los trabajadores de servicio, primero debemos crear el archivo JavaScript de nuestro trabajador de servicio, sw.js , ubicado en el directorio raíz.

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); }) ); });

Miremos más de cerca a nuestro trabajador de servicio. Primero, estamos configurando una variable cacheName . Esto se utiliza para determinar si se han realizado cambios en nuestros activos almacenados en caché. Para este ejemplo, usaremos un nombre estático, lo que significa que nuestros activos no cambiarán ni requerirán actualización.

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

El evento de install se activa durante la fase de instalación del trabajador de servicio y se activará solo una vez si el trabajador de servicio ya está instalado. Por lo tanto, actualizar la página no activará nuevamente la fase de instalación. Durante la fase de instalación, podemos declarar qué activos se almacenarán en caché. En nuestro ejemplo anterior, estamos almacenando en caché un archivo CSS, dos archivos JavaScript, nuestro archivo de fuentes, nuestra plantilla HTML sin conexión y, por supuesto, la raíz de la aplicación. self.skipWaiting() obliga al trabajador del servicio de espera a activarse.

Hasta ahora, hemos declarado nuestro trabajador de servicio, pero antes de que entre en vigor, debemos hacer referencia a él en nuestro JavaScript. En nuestra aplicación, lo registramos en 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);

También hemos incluido dos detectores de eventos para verificar si el estado de la sesión ha cambiado de en online a offline o viceversa. Luego, los controladores de eventos llaman a las diferentes funciones para recuperar los datos a través de Arrivals.loadData() y para habilitar o deshabilitar el mensaje fuera de línea a través Page.showOfflineWarning y Page.hideOfflineWarning , respectivamente. Nuestra aplicación también verifica si el usuario está actualmente en línea, utilizando navigator.onLine, y recupera los datos o muestra la advertencia de desconexión correspondiente. Y en la última línea de main.js , aplicamos los enlaces Knockout a nuestro View Model Page.vm

Si cargamos nuestra aplicación por primera vez (con Chrome Developer Tools), no veremos nada nuevo. Sin embargo, al volver a cargar, veremos que se ha recuperado una cantidad de recursos de red del trabajador del servicio. Este es nuestro shell de aplicación.

Prueba fuera de línea

Un usuario que ejecute la aplicación sin conexión a Internet (suponiendo que ya haya estado en la página) simplemente mostrará el shell de la aplicación y la advertencia de fuera de línea, una mejora con respecto al merodeador t-rex de Chrome. Una vez que el usuario ha establecido una conexión de red, desactivamos la advertencia y recuperamos los datos más recientes.

The Guardian adopta un enfoque particularmente interesante cuando los usuarios sin conexión acceden a su sitio web, proporcionando un crucigrama:

Notificaciones push

Las notificaciones automáticas permiten a los usuarios optar por recibir actualizaciones oportunas de las aplicaciones en las que confían, lo que les ayuda a volver a interactuar con las aplicaciones. Las notificaciones automáticas en la web le permiten interactuar con su audiencia incluso cuando el navegador está cerrado.

Push API es compatible con Chrome, Opera y el navegador de Samsung y está en desarrollo en Firefox y Microsoft Edge. Desafortunadamente, no hay indicios de que la función se implementará en Safari.

Rendimiento

Una de las ventajas más sencillas de los trabajadores de servicios es que podemos mejorar el rendimiento con poco o ningún esfuerzo. Comparando nuestro sitio web consigo mismo antes de que se implementaran los trabajadores de servicio, antes de que recuperáramos más de 200 KB al cargar la página; que ahora se reduce a 13 KB. En una red 3G normal, la página habría tardado 3,5 segundos en cargarse; ahora tarda 500 milisegundos.

Estas mejoras de rendimiento son drásticas porque la aplicación en sí es muy pequeña y tiene una funcionalidad limitada. Sin embargo, mediante el uso correcto del almacenamiento en caché, es posible mejorar significativamente el rendimiento y el rendimiento percibido, especialmente para los usuarios en lugares con baja conectividad.

Faro

El equipo Chrome de Google ha creado una herramienta para probar aplicaciones web progresivas. Lighthouse se ejecuta en Node.js o como complemento de Chrome y también se puede encontrar en GitHub.

Para ejecutar una prueba de Lighthouse, su sitio web debe estar disponible en línea, lo que significa que no puede probar en localhost .

Para comenzar, descargue el paquete npm:

 npm install -g GoogleChrome/lighthouse

Una vez que esté instalado, ejecute Chrome (versión 52 en adelante):

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

El resultado de la ejecución de Lighthouse será visible en la línea de comando y calificará su sitio web de acuerdo con las funciones y propiedades progresivas de la aplicación web que haya implementado, por ejemplo, si está utilizando un archivo manifest.json o si su página está disponible sin conexión. .

Conclusión

Este artículo es simplemente un aperitivo para las aplicaciones web progresivas. Podríamos hacer mucho más para crear esa experiencia similar a la aplicación que buscan los usuarios, ya sea admitiendo notificaciones automáticas con la API Push, haciendo que la aplicación se pueda volver a conectar o usando IndexedDB y sincronización en segundo plano para mejorar la experiencia fuera de línea.

Compatibilidad con varios navegadores

Todavía son los primeros días para las aplicaciones web progresivas, y la compatibilidad entre navegadores aún es limitada, especialmente en Safari y Edge. Sin embargo, Microsoft apoya abiertamente las aplicaciones web progresivas y debería implementar más funciones para fin de año.

• Trabajadores de servicios y API de caché . Compatible con Chrome, Firefox, Opera y el navegador de Samsung. En desarrollo en Microsoft Edge, se espera que esté disponible a finales de 2016. Bajo consideración para Safari.
• Añadir a la pantalla de inicio . Compatible con Chrome, Firefox, Opera, navegador de Android y el navegador de Samsung. Microsoft parece indicar que las aplicaciones web progresivas estarán disponibles como listas de tiendas. No hay planes para Safari hasta el momento.
• Empuje la API . Mayormente compatible con Chrome, Firefox, Opera y el navegador de Samsung. En desarrollo en Microsoft Edge. No hay planes para Safari hasta el momento.

Si más desarrolladores aprovechan las funciones que ofrecen las aplicaciones web progresivas, que son relativamente fáciles de implementar y brindan recompensas inmediatas, los usuarios preferirán consumir estas aplicaciones web en navegadores compatibles, con la esperanza de convencer a los otros proveedores de navegadores para que se adapten.

Código fuente

El código fuente completo de este tutorial está disponible en un repositorio de Github y la demostración está disponible en las páginas de GitHub.