Los componentes básicos de las aplicaciones web progresivas

Las aplicaciones web pueden reemplazar todas las funciones de las aplicaciones y sitios web nativos a la vez. Están cobrando cada vez más protagonismo en estos días, pero todavía no hay suficientes personas que estén familiarizadas con ellos o que los adopten.

En este artículo, podrá encontrar algunas recomendaciones sobre cómo crear una aplicación web progresiva, así como recursos para futuras investigaciones. También analizaré los diversos componentes y los problemas de soporte relacionados con las aplicaciones web. Aunque no todos los navegadores son compatibles con ellos, todavía hay algunas razones de peso para aprender más sobre esta tecnología.

¿Qué hace que una aplicación web sea progresiva?

Una aplicación web progresiva es un término general para ciertas tecnologías que se combinan para producir una experiencia similar a la de una aplicación en la web. En aras de la simplicidad, me referiré a ellos simplemente como aplicaciones web de ahora en adelante.

Una aplicación web ideal es una página web que tiene los mejores aspectos tanto de la web como de las aplicaciones nativas. Debe ser rápido para interactuar con él, ajustarse a la ventana gráfica del dispositivo, permanecer usable sin conexión y poder tener un icono en la pantalla de inicio.

Al mismo tiempo, no debe sacrificar las cosas que hacen que la web sea excelente, como la capacidad de vincular profundamente en la aplicación y usar URL para permitir compartir contenido. Al igual que la web, debería funcionar bien en todas las plataformas y no centrarse únicamente en los dispositivos móviles. Debería comportarse tan bien en una computadora de escritorio como en otros factores de forma, para no correr el riesgo de tener otra era de sitios web m.example.com que no responden.

Las aplicaciones web progresivas no son nuevas. Los navegadores móviles han tenido la capacidad de marcar un sitio web en la pantalla de inicio de su teléfono desde 2011 (2013 en Chrome Android), con etiquetas meta en el head que determinan la apariencia de la página web instalada. The Financial Times ha estado utilizando una aplicación web para la entrega de contenido digital en dispositivos móviles desde 2012.

Pasar a una aplicación web permitió que Financial Times usara la misma aplicación para realizar envíos a través de plataformas en un solo canal de distribución. Cuando trabajaba para el Financial Times, con una sola compilación pudimos admitir lo siguiente:

• iOS,
• Android (4.4+) cromo,
• Android más antiguo (a través de un contenedor),
• ventanas 8,
• Mora,
• Sistema operativo Firefox.

Eso realmente logra "construir una vez, implementar en cualquier lugar".

“Pero no está en una tienda de aplicaciones”

Hay algunas buenas razones por las que complementar una aplicación nativa con un sitio web sigue siendo una práctica estándar para la mayoría de las empresas importantes. Entre ellos se encuentran las preocupaciones sobre la compatibilidad con los navegadores y el hecho de que la mayoría de los usuarios están acostumbrados a usar aplicaciones nativas. Abordaré estas cuestiones con más detalle más adelante. No menos importante de estas preocupaciones es cómo la aplicación obtendrá exposición si no está en una tienda de aplicaciones.

Yo diría que estar en una tienda de aplicaciones no tiene una gran ventaja porque se ha demostrado que si no está en el 0,1% superior de las aplicaciones en la tienda de aplicaciones, no obtiene un beneficio significativo por estar allí.

Los usuarios tienden a encontrar sus aplicaciones al encontrar primero su sitio web. Si su sitio web es una aplicación web, ya están en su destino.

Uno de los puntos fuertes de una aplicación web es que le permite mejorar la participación al reducir la cantidad de clics necesarios para volver a involucrar al usuario entre el aterrizaje en su sitio web y la interacción con su aplicación.

Al hacer que el usuario "instale" su aplicación web agregándola a su pantalla de inicio, puede continuar interactuando con su sitio web. Cuando cierren el navegador web, el teléfono les mostrará dónde está instalada la aplicación web, lo que lo hará volver a su conocimiento.

Antecedentes y clima actual

Las aplicaciones web modernas se basan en una nueva tecnología llamada trabajadores de servicios. Los trabajadores del servicio son proxies programables que se ubican entre la pestaña del usuario y la Internet más amplia. Interceptan y reescriben o fabrican solicitudes de red para permitir un almacenamiento en caché muy granular y soporte fuera de línea.

Desde los orígenes de la aplicación web en 2011, que permitía marcar los sitios web en la pantalla de inicio, se han producido una serie de desarrollos para sentar las bases para la creación de aplicaciones web progresivas.

Chrome 38 introdujo el manifiesto de la aplicación web, que es un archivo JSON que describe la configuración de su aplicación web. Esto nos permitió eliminar la configuración de la head .

En Chrome 40 (diciembre de 2014), los trabajadores de servicios comenzaron a implementarse en Firefox y Chrome. Hasta ahora, Apple ha optado por no implementar esta función en Safari en el momento de escribir este artículo, pero la tiene "en consideración". La función del trabajador del servicio es simplificar el proceso de poner una aplicación fuera de línea; también sienta las bases para futuras funciones similares a las de una aplicación, como las notificaciones automáticas y la sincronización en segundo plano.

Las aplicaciones que se crearon en función de los nuevos trabajadores de servicio y el manifiesto de la aplicación web se conocieron como aplicaciones web progresivas.

Una aplicación web progresiva no es lo mismo que la especificación. De hecho, comenzó como una definición de lo que debería ser una aplicación web en la era de los trabajadores de servicios, dada la nueva tecnología que se está incorporando en los navegadores. Específicamente, Chrome usa esta definición para activar un mensaje de instalación en el navegador cuando se cumplen una serie de condiciones. Las condiciones son que la aplicación web:

• tiene un trabajador de servicio (requiere HTTPS);
• tiene un archivo de manifiesto de aplicación web (con al menos una configuración mínima y con display: "standalone" );
• Ha tenido dos visitas distintas.

En este caso, "progresivo" significa que cuantas más funciones admita el navegador, más similar a una aplicación puede ser la experiencia.

El mensaje para instalar la aplicación web se muestra actualmente en diferentes condiciones en Opera, Chrome y el navegador Samsung.

Apple ha mostrado interés en las aplicaciones web progresivas para iOS, pero en el momento de escribir este artículo todavía se basa en metaetiquetas para la configuración de la aplicación web y la memoria caché de la aplicación (AppCache) para el uso sin conexión.

¿En qué momento un sitio web se convierte en una aplicación web?

Sabemos cómo es un sitio web y cómo es una aplicación, pero ¿en qué momento un sitio web se convierte en una aplicación web? No existe una métrica definitiva sobre qué hace que algo sea una aplicación web en lugar de un sitio web.

Aquí entraremos en más detalles sobre las características de una aplicación web.

Una aplicación web progresiva debe exhibir ciertas propiedades similares a las de una aplicación...

• Sensible
  Llenando perfectamente la pantalla, estos sitios web están dirigidos principalmente a teléfonos y tabletas y deben responder a la gran cantidad de tamaños de pantalla. También deberían funcionar como sitios web de escritorio. El diseño receptivo ha sido una parte importante de la creación de sitios web durante muchos años. Smashing Magazine tiene excelentes artículos al respecto.
• Fuera de línea primero
  La aplicación debe poder iniciarse sin conexión y seguir mostrando información útil.
• Capacidad táctil
  La interfaz debe estar diseñada para el tacto, con interacción por gestos. La interacción del usuario debe sentirse receptiva y rápida, sin demora entre un toque y una respuesta.
• metadatos de la aplicación
  La aplicación debe proporcionar metadatos para decirle al navegador cómo debe verse cuando se instala, de modo que obtenga un bonito icono de alta resolución en la pantalla de inicio y una pantalla de bienvenida en algunas plataformas.
• Notificaciones push
  La aplicación puede recibir notificaciones cuando la aplicación no se está ejecutando (si corresponde).

… pero debería mantener ciertas propiedades similares a las de la web

• Progresivo
  La capacidad de instalación de la aplicación es una mejora progresiva. Es vital que la aplicación siga funcionando como un sitio web normal, especialmente en plataformas que aún no admiten trabajadores de instalación o servicio.
• HTTPS en la web abierta
  La aplicación no debe estar bloqueada en ningún navegador o tienda de aplicaciones. Debería poder vincularse profundamente y proporcionar métodos para compartir la URL actual.

Desconectar su sitio web

Desconectar su sitio web trae algunas ventajas importantes.

Primero, seguirá funcionando cuando el usuario esté en una conexión de red inestable.

Además, el tiempo que transcurre desde que se abre la aplicación hasta que se usa se reduce considerablemente si la aplicación no depende de la red. Esto le da al usuario una gran experiencia. Una aplicación web cuidadosamente optimizada puede comenzar más rápido que una nativa si el navegador se usó recientemente.

Hay dos métodos para hacer que un sitio web funcione sin conexión:

• Método viejo y roto
  El soporte para iniciar su sitio web sin conexión ha existido durante años en forma de AppCache. Sin embargo, AppCache tiene algunos defectos graves e incluso ha quedado obsoleto en la especificación. Es difícil trabajar con él y, si está mal configurado, podría dañar permanentemente su sitio web. Aún así, es la única forma de hacerlo sin conexión en iOS, al menos hasta que Apple haga un movimiento para apoyar a los trabajadores de servicios.
• nuevo picor
  También son efectivos los trabajadores de servicio, que actualmente son compatibles con Chrome, Firefox y Opera y muy pronto llegarán a Edge. El equipo de WebKit de Apple lo tiene marcado como "bajo consideración".

Los trabajadores de servicio son como otros trabajadores web en el sentido de que se ejecutan en un subproceso separado, pero no están vinculados a ninguna pestaña específica. Se les asigna un ámbito de URL cuando se crean y pueden interceptar y reescribir cualquier solicitud en este ámbito. Si su trabajador de servicio se encuentra en https://example.com/my-site/sw.js , podrá interceptar cualquier solicitud realizada a /my-site/ o inferior, pero no podrá interceptar solicitudes a la raíz https://example.com/ .

Debido a que no están vinculados a ninguna pestaña, pueden cobrar vida en segundo plano para manejar notificaciones automáticas o sincronización en segundo plano. No menos importante, es imposible romper permanentemente su sitio web con ellos porque se actualizarán automáticamente cuando se detecte un nuevo script de trabajador de servicio.

Una buena pauta es que, si está creando un nuevo sitio web desde cero, comience con un trabajador de servicio. Sin embargo, si su sitio web ya funciona sin conexión con AppCache, entonces puede usar la herramienta sw-appcache-behavior para generar un trabajador de servicio a partir de esto, porque pronto podemos llegar al punto en que algunos navegadores solo aceptarán trabajadores de servicio y otros solo aceptarán Caché de aplicaciones.

Debido a que AppCache está en desuso, no lo discutiré más en este artículo.

Configuración de un trabajador de servicio

(También, consulte "Configuración de un Service Worker" para obtener instrucciones más detalladas).

Debido a que un trabajador de servicio es un tipo especial de trabajador web compartido, se ejecuta en un hilo separado de su página principal. Esto significa que lo comparten todas las páginas web en la misma ruta que el trabajador del servicio. Por ejemplo, un trabajador de servicio ubicado en /my-page/sw.js podría afectar /my-page/index.html y my-page/images/header.jpg , pero no /index.html .

Los trabajadores del servicio pueden interceptar y reescribir o falsificar todas las solicitudes de red realizadas en la página, incluidas las realizadas a las URL data:// .

Este poder le permite proporcionar respuestas almacenadas en caché para que las páginas funcionen cuando no hay conexión de datos. Aún así, es lo suficientemente flexible como para permitir muchos casos de uso posibles.

Solo se permite en contextos seguros (es decir, HTTPS) porque es muy poderoso. Esto evita que terceros anulen permanentemente su sitio web utilizando un trabajador de servicio inyectado desde un punto de acceso Wi-Fi infectado o malicioso.

Configurar HTTPS hoy en día puede parecer desalentador y costoso, pero en realidad nunca ha sido más fácil o más barato. Let's Encrypt proporciona certificados y scripts SSL gratuitos para que configure automáticamente su servidor. En caso de que alojes en GitHub, las páginas de GitHub se sirven automáticamente a través de HTTPS. Las páginas de Tumblr también se pueden configurar para ejecutarse en HTTPS. CloudFlare puede enviar solicitudes de proxy para actualizar a HTTPS.

La desconexión generalmente implica elegir ciertos métodos de almacenamiento en caché para diferentes partes de su sitio web para permitir que se sirvan más rápido o cuando no hay conexión a Internet. Discutiré varios métodos de almacenamiento en caché a continuación.

Utilizo Service Worker Toolbox para abstraer la lógica de almacenamiento en caché compleja. Esta biblioteca se puede configurar para manejar el enrutamiento al proporcionar cuatro rutas preconfiguradas, que se pueden configurar de manera limpia. Se puede importar a su trabajador de servicio.

Caso de uso 1: Precaching

El almacenamiento previo en caché retira las solicitudes antes de que su sitio web determine que son necesarias. Esto puede disminuir en gran medida el tiempo de primera pintura porque su sitio web no necesita analizar /site.css antes de que comience a descargar el logotipo de su sitio web, /images/logo.png .

 toolbox.precache(['/index.html', '/site.css', '/images/logo.png']);

Caso de uso 2: fuera de línea

Permitir que los usuarios vuelvan a visitar su sitio web cuando están desconectados en el caso más simple significa recurrir al caché si el dispositivo está desconectado. Establecer un tiempo de espera aquí es importante porque una red inestable, un enrutador mal configurado o un portal cautivo podrían dejar al usuario esperando indefinidamente.

 toolbox.router.default = toolbox.networkFirst; toolbox.options.networkTimeoutSeconds = 5;

En realidad, podemos ser un poco más inteligentes porque la mayoría de sus activos no cambiarán con el tiempo. Probablemente solo queramos obtener el contenido lo antes posible, ya sea del caché o de la red. La siguiente línea le dice a Service Worker Toolbox que todas las solicitudes a las rutas de las imágenes deben provenir del caché si están disponibles allí.

 toolbox.router.all('/images/*', toolbox.fastest);

En este caso, cuando el usuario se está autenticando, es importante que no solo devolvamos una respuesta almacenada en caché; debemos indicar que las solicitudes realizadas a /auth/ deben ser solo de red.

 toolbox.router.post('/auth/*', toolbox.networkOnly);

Estas son algunas buenas prácticas para desconectarse:

• Los activos estáticos iniciales deben almacenarse en caché. Esto los descarga y los almacena en caché cuando se instala el trabajador de servicio. Esto significa que no es necesario cargarlos desde el servidor cuando finalmente se requieran.
• De forma predeterminada, lo ideal es que las solicitudes se obtengan recientemente de la red, pero recurran a la memoria caché para que estén disponibles sin conexión.
• Un tiempo de espera de red relativamente corto significa que las solicitudes podrán devolver datos almacenados en caché en una conexión de red que dice que tiene una conexión de datos, pero no se devuelven respuestas.
• Los activos que se actualizan con poca frecuencia, como las imágenes, deben enviarse primero desde el caché, luego el navegador también intentará actualizarlos. Si se usa toolbox.cacheOnly , también podría guardar los datos del usuario.

Nota: El caché del navegador y la API de caché son animales diferentes. La API de caché se ha omitido en el caso de red primero o solo red. Es posible que la solicitud aún llegue a la memoria caché del navegador porque los encabezados de almacenamiento en caché de la solicitud indican que aún es válida. Esto podría resultar en el problema de que el usuario reciba una combinación de datos almacenados en caché y nuevos. Jake Archibald tiene algunas buenas sugerencias para evitar este problema.

Depuración de su Service Worker

Si está en Chrome u Opera, vaya a chrome://serviceworker-internals . Esto le permitirá inspeccionar, pausar y desinstalar la secuencia de comandos de Service Worker.

En versiones recientes de Chrome y Opera, puede obtener vistas detalladas y herramientas de depuración a través de la pestaña "Aplicación" en el inspector.

Rendimiento de interacción y animación

La gente espera que la web no tenga las interfaces animadas fluidas que tienen las aplicaciones nativas. Sin embargo, el mismo estándar no es aceptable para las aplicaciones web. Las aplicaciones web deben animarse sin problemas, para que nuestros usuarios no sientan que estamos brindando una experiencia degradada de segunda clase. Tenemos tres objetivos para que se sienta rápido:

• Cuando el usuario hace algo, la aplicación también debe hacer algo en 100 milisegundos; de lo contrario, el usuario notará un retraso. Esto cuenta para toques, clics, arrastres y desplazamientos.
• Cada fotograma debe procesarse a una velocidad constante de 60 fotogramas por segundo (16 milisegundos por fotograma). Incluso unos pocos fotogramas lentos serán evidentes.
• Debe ser rápido en un teléfono económico de tres años que se ejecuta en una red deficiente, no solo en su brillante máquina de desarrollo.
• Debe comenzar rápidamente. Durante mucho tiempo nos hemos centrado en mantener la participación de los usuarios haciendo que nuestros sitios web sean visibles y utilizables en menos de 1 a 2 segundos. Cuando se trata de aplicaciones web, el tiempo de inicio es tan importante como siempre. Si todo el contenido de una aplicación se almacena en caché y el navegador aún está en la memoria del dispositivo, una aplicación web puede iniciarse más rápido que una aplicación nativa. Un error que cometen los desarrolladores de aplicaciones nativas y sitios web es requerir contenido en red para que el producto funcione.
• La aplicación web debe ser pequeña para descargar y actualizar: 10 MB de una tienda de aplicaciones no parece mucho, pero 10 MB descargados cada vez que no están almacenados en caché es imposible de administrar para muchos usuarios móviles.

De buenas a primeras, el elemento más esencial es este, en el head del documento:

 <meta name="viewport" content="width=device-width">

Esta línea garantiza que no haya un retraso de toque de 300 milisegundos en los navegadores de teléfonos basados ​​en Chromium o Firefox, pero aun así permite al usuario acercar el zoom al pellizcar (excelente para la accesibilidad).

Desde que salió iOS 8, los clics son rápidos de forma predeterminada, pero pueden parecer lentos si el toque es rápido, de acuerdo con ciertas heurísticas. Si esto es un problema para usted, le recomiendo usar FastClick para eliminar el retraso.

También está el tema del rendimiento de la animación. Probablemente querrá muchos elementos bonitos animando dentro y fuera, elementos que el usuario pueda arrastrar y otras interacciones encantadoras.

El rendimiento web se puede analizar con gran detalle y es un tema muy importante para mí, pero no entraré en muchos detalles aquí. Me referiré a lo que hago para asegurarme de que mis interacciones y animaciones sean nítidas y fluidas.

Busque o pregunte a sus amigos o familiares por un teléfono inteligente viejo. Normalmente tomo prestado el Nexus 4 de mi pareja.

Conecta el teléfono a tu computadora y ve a chrome://inspect/#devices . Esto abrirá una ventana de inspección, que puede usar para inspeccionar las páginas web que se ejecutan en el teléfono. Puede usar la creación de perfiles y ver la línea de tiempo para encontrar fuentes de bajo rendimiento y luego optimizarlas en función de un dispositivo de referencia real.

Animar ciertas propiedades CSS es una de las principales causas de la animación nerviosa, conocida como bloqueo. CSS Triggers es un gran recurso para determinar qué propiedades se pueden animar de forma segura sin que el navegador vuelva a pintar o rediseñar toda la página.

Si escribir animaciones eficaces es una tarea abrumadora para usted, muchas bibliotecas se encargarán del trabajo. Uno de mis favoritos es GreenSock, que puede manejar muy bien las interacciones táctiles, como arrastrar elementos, y que puede hacer animaciones e interpolaciones muy elegantes.

Notificaciones push

Las notificaciones push son una excelente manera de volver a interactuar con los usuarios. Al preguntarle al usuario, trae su aplicación al frente de su mente. Podrían terminar una transacción inconclusa o recibir alertas sobre contenido nuevo relevante.

Asegúrese de que sus notificaciones automáticas sean relevantes para el usuario para los eventos que suceden en ese momento. No pierda su tiempo en cosas que se pueden hacer más tarde. Lo que les estás notificando debe requerir su acción (responder a alguien o asistir a un evento). Además, no envíe una notificación si su aplicación web está visible o enfocada.

Cuando se interactúa, una notificación debe llevar al usuario a una página que funciona sin conexión. Las notificaciones pueden quedarse sin leer; se puede interactuar con ellos cuando el usuario no tiene conexión a la red. El usuario se frustrará si su notificación automática se niega a funcionar después de haber intentado interactuar con ella.

¡La mejor experiencia para las notificaciones automáticas libera al usuario de tener que abrir su aplicación web ! “Tienes un nuevo mensaje” es inútil y tan molesto como un titular de clickbait. Muestra el mensaje y el remitente.

Los botones de acción en la notificación pueden proporcionar indicaciones de interacción que no necesariamente abren el navegador ("Me gusta esta publicación", "Responder con sí", "Responder con no", "Recordarme más tarde"). Estos sirven al usuario en sus términos, lo mantienen comprometido y minimiza su inversión de tiempo.

Si envía spam al usuario con notificaciones regulares o irrelevantes, es posible que deshabilite las notificaciones de su aplicación en el navegador. Después de eso, será casi imposible volver a interactuar con ellos, ¡y no podrás pedirles permiso de nuevo fácilmente!

Para evitar esto, haga que la ruta hacia el botón de "deshabilitar notificación" de su aplicación sea clara y fácil. Una vez que haya resuelto los problemas que frustran a los usuarios, puede intentar volver a participar.

La API de notificaciones push requiere un trabajador de servicio. Debido a que es posible recibir notificaciones automáticas cuando no hay una pestaña del navegador abierta, el trabajador del servicio manejará la solicitud de notificación en un subproceso en segundo plano. Puede realizar operaciones asíncronas, como realizar una solicitud de recuperación a su API antes de mostrar la notificación al usuario.

Para crear una notificación push, realice una solicitud a un punto final proporcionado por el fabricante del navegador. Para navegadores basados ​​en Chromium (Opera, Samsung y Chrome), esto sería Firebase Cloud Messaging. Estos navegadores también se comportan un poco fuera de especificación.

Uno puede encontrar los detalles de esto solicitando el permiso de notificación automática:

 serviceWorkerRegistration .pushManager .subscribe({ // Required parameter as receiving updates // but not displaying a message is not supported everywhere. userVisibleOnly: true }) .then(function(subscription) { return sendSubscriptionToServer(subscription); })

La suscripción es un objeto que se ve así:

 { "endpoint": "https://example.com/some/uuid" }

En el ejemplo anterior, el uuid identifica de forma única el navegador que se está utilizando actualmente.

Nota: los navegadores basados ​​en Chromium se comportan de forma un poco diferente. Necesitará un ID de aplicación de Firebase, que debe ingresarse en el archivo de manifiesto de su aplicación web (por ejemplo, "gcm_sender_id": "90157766285" ).

Además, el punto final no funcionará en el formato que se le proporcione. Su servidor necesita destrozarlo ligeramente para que funcione. Debe ser una solicitud POST , con su clave API en el head y el uuid en el body .

Al enviar una notificación automática, es posible enviar datos en el cuerpo de la propia notificación automática. Esto es complejo e implica cifrar los contenidos en la solicitud de API. El paquete web-push para Node.js puede manejar esto, pero no lo prefiero.

Es posible realizar solicitudes asíncronas una vez que se ha recibido la notificación, por lo que prefiero enviar una notificación mínima, conocida como "cosquillas", al cliente, y luego el trabajador del servicio realizará una solicitud de recuperación a mi API para extraer cualquier actualizaciones recientes.

Nota: el navegador puede cerrar el service worker en cualquier momento. La función event.waitUntil en el evento push le dice al trabajador del servicio que no cierre hasta que finalice el evento.

 self.addEventListener('push', function(event) { event.waitUntil( // Makes API request, returns Promise getMessageDetails() .then(function (details) { self.registration.showNotification( details.title, { body: details.message, icon: '/my-app-logo-192x192.png' }) }) ); });

También puede escuchar un clic o presionar la interacción en los eventos de notificación. Utilícelos para decidir cómo responder. Puede abrir una nueva pestaña del navegador, enfocar una pestaña existente o realizar una solicitud de API. También puede elegir cerrar la notificación o mantenerla abierta. Utilice esta funcionalidad con acciones en la notificación para crear una gran funcionalidad en la propia notificación. Esto hará que la experiencia sea excelente, ya que no se requerirá que el usuario abra su aplicación cada vez.

No ignore las fortalezas de la web

El punto final y más importante es que, en nuestra prisa por una experiencia similar a la de una aplicación, no debemos olvidarnos de mantenernos similares a la web en un aspecto muy importante: las URL.

Las aplicaciones web instaladas a menudo ocultan el shell del navegador. No hay una barra de direcciones para que el usuario comparta la URL actual y el usuario no puede guardar la página actual para más adelante.

Las URL tienen una ventaja web única: puede hacer que las personas usen su aplicación haciendo clic, en lugar de describir cómo navegar por ella. De todos modos, es muy fácil olvidarse de exponer esto a los usuarios. Podrías escribir la mejor aplicación del mundo, pero si nadie puede compartirla, te habrás hecho un gran perjuicio.

Todo se reduce a esto: proporcione formas de compartir su aplicación a través de botones para compartir o un botón para exponer la URL.

¿Qué pasa con los navegadores que no son compatibles con las aplicaciones web progresivas?

Consulte ¿Está listo ServiceWorker? para conocer el estado actual de la compatibilidad con los trabajadores de servicios en todos los navegadores.

Es posible que haya notado a lo largo de todo esto que mencioné Chrome, Firefox y Edge, pero omití Safari. Apple presentó las aplicaciones web al mundo y ha mostrado interés en las aplicaciones web progresivas, pero aún no es compatible con los trabajadores de servicio o el manifiesto de la aplicación web. ¿Qué puedes hacer?

Es posible crear un sitio web fuera de línea para Safari con AppCache, pero hacerlo es difícil y está plagado de casos extraños que pueden romper la página o mantenerla desactualizada permanentemente después de la primera carga.

En su lugar, cree una excelente experiencia de aplicación web. Tu trabajo no habrá sido en vano porque la experiencia seguirá siendo excelente en Safari, que es un navegador muy bueno. Cuando los trabajadores de servicio vengan a Safari, estará listo para aprovecharlos.

Finalmente, podemos esperar muchos desarrollos emocionantes en el mundo de las aplicaciones web, con un soporte cada vez mayor para las tecnologías detrás de ellas y nuevas funciones que llegan a la plataforma web, como la API Web Bluetooth para interactuar con el hardware, WebVR para aplicaciones virtuales. realidad y WebGL 2 para juegos de alta velocidad. Ahora es un buen momento para explorar las posibilidades de las aplicaciones web y participar en la configuración del futuro de la web.

Enlaces

Otros escritos sobre aplicaciones web progresivas

• "Otro blog más sobre el estado y el futuro de las aplicaciones web progresivas", Ada Rose Edwards

Enlaces a los que se hace referencia en el artículo

• “La forma de la tienda de aplicaciones”, Charles Perry
• Ayudantes de trabajadores de servicio, Google, GitHub
• Caja de herramientas para trabajadores de servicios, Google, GitHub
• “El retraso de clic de 300 milisegundos e iOS 8”, TJ VanToll
• "Prácticas recomendadas de almacenamiento en caché y trampas de edad máxima", Jake Archibald