Seguro que has escuchado mucho la palabra PWA, que se refiere a las Aplicaciones Web Progressivas o Progressive Web Apps en sus siglas en inglés.
En este artículo vamos a aprender qué son las Aplicaciones Web Progresivas, qué problemas tratan de solucionar, en qué se basan para hacerlo, el soporte que existe actualmente en los sistemas y si merece la pena tanto revuelo.
Las limitaciones de las aplicaciones web en los móviles
Como sabemos, es posible crear aplicaciones para móviles utilizando desarrollo nativo o bien lo que se ha dado en llamar desarrollo híbrido. Este desarrollo híbrido consiste en crear aplicaciones web pensadas para trabajar en un móvil y luego convertirlas en aplicaciones nativas usando algún envoltorio como Apache Cordova/Phonegap.
Sin embargo, y aunque cueste creerlo a estas alturas, la idea original cuando se lanzó el primer iPhone en 2007 (el dispositivo que marcó la senda de lo que hoy son los móviles), era que las aplicaciones fueran en su mayoría aplicaciones web. El desarrollo nativo tardó todavía 1 año en habilitarse. La idea era crear aplicaciones web, anclarlas a la pantalla de inicio y trabajar con ellas.
Lo cierto es que este concepto no funcionó y hubo pocas aplicaciones web que funcionasen de esta manera. En primer lugar porque casi nadie ancla nada a la pantalla de inicio salvo que s elo pongas muy fácil, pero también porque no solían ser tan ágiles normalmente como las nativas, no suelen tener un aspecto igual de natural y, sobre todo, porque las aplicaciones web carecían de muchas de las capacidades que se necesitan en una aplicación nativa (trabajar sin conexión, enviar notificaciones, almacenar datos localmente…).
Por supuesto, muchas de estas limitaciones se eliminan si utilizas un envoltorio como Cordova, que ofrece a tu aplicación web acceso al hardware subyacente mediante unas sencillas bibliotecas JavaScript.
Pero si lo que quieres es crear una aplicación web «pura», sin envoltorio, que funcione en un navegador móvil casi de la misma manera que si fuera una aplicación nativa, la cosa antes resultaba muy complicada.
Para lograr superar estas limitaciones nacieron muchas de las APIs de HTML5 y también las PWAs.
¿Qué es una Aplicación Web Progresiva?
Google fue el que más promovió este tipo de aplicaciones. En su página dedicada al tema ofrece una definición breve pero bastante descriptiva de qué es una PWA, que sería más o menos la siguiente:
Una PWA utiliza las últimas tecnologías disponibles en los navegadores para ofrecer una experiencia en móviles lo más parecida a la de una aplicación nativa.
La verdad es que es como no decir nada, y al mismo tiempo decirlo todo.
La idea que transmite esta definición es que los objetivos que debemos buscar al crear una PWA son:
- Que tenga el mayor rendimiento posible en móviles y que cargue de manera casi instantánea
- Una buena interfaz que se parezca lo máximo posible a una nativa
- La posibilidad de trabajar sin conexión
- Poder enviar notificaciones a los usuarios, como una app nativa
Básicamente con estas cuatro premisas estaríamos cubiertos, así que detrás de ese nombre lo que hay es realmente una idea sencilla.
Tecnologías que aprovechan las PWA
Vale. Ahora que ya sabemos lo que queremos conseguir, ¿cómo podemos hacerlo?
Para conseguirlo, las PWAs se basan en unos conceptos bastante simples:
- Responsive Web Design, animaciones CSS y frameworks específicos para crear interfaces móviles con aspecto de nativas
- Service Workers
- App Shell
- Manifiesto de aplicación
No voy a entrar hoy en lo primero, pero veamos qué es cada una de las otras 3 cosas…
Service Workers
Los Service workers son una tecnología muy interesante y a la vez bastante compleja que nos permite ejecutar servicios en segundo plano en los navegadores.
Van más allá de lo que ofrece un Web Worker. Éstos últimos nos permiten ejecutar código pesado en segundo plano (en un subproceso dedicado) y comunicarnos con ellos, de modo que una o varias tareas largas no bloqueen la interfaz de usuario. Pero los Service Workers son más potentes y complejos, puesto que pueden ejecutarse de manera independiente a la aplicación (es decir, estar en ejecución aunque la página de nuestra app web esté cerrada) y ofrecen capacidades avanzadas como la intercepción de las comunicaciones, el cacheado de información, la descarga en segundo plano de contenidos, el trabajo sin conexión o la posibilidad de enviar notificaciones.
El Service Worker nos puede proporcionar mucha funcionalidad a la hora de hacer almacenamiento off-line de información, sobre todo a la hora de tomar decisiones para hacerlo, y no solo asegurar que se encuentra almacenada.
De todos modos para crear una PWA no es necesario estrictamente usar Service Workers salvo que requiramos ciertas funcionalidades avanzadas.
En el momento de escribir esto todos los navegadores modernos permiten el uso de Service Workers.
App Shell
App Shell no es una tecnología, sino un modelo o patrón a la hora de crear las aplicaciones. La idea es muy sencilla: separar la aplicación entre funcionalidad y contenido y cargarlos por separado.
Lo cierto es que la mayor parte de las aplicaciones de tipo Single Page (SPAs) ya suelen usar una u otra forma de hacer eso.
Lo suyo es tener, por un lado, la aplicación en sí cacheada para uso off-line (con Service Workers o no) de modo que cargue a toda velocidad, y luego el contenido (los datos) que cargue por otro lado, bien de una caché inicial también y luego se actualicen, o directamente desde la web si hay conexión.
Esto, bien realizado, hace que la percepción que tiene el usuario de la velocidad de carga de la app sea mayor. Parece que carga mucho más rápido porque al cargar el «shell» antes de nada y desde una caché, el usuario verá la app enseguida.
En mi opinión no es más que una «buzzword» para algo que cualquier programador preocupado por el rendimiento y la usabilidad ya debería estar haciendo. Pero no está mal que nos lo recuerden y nos «fuercen» a ello si queremos que nuestra aplicación web se pueda considerar «progresiva».
Manifiesto de aplicación
Como comentaba al principio, desde los primeros smartphones como hoy los conocemos, siempre ha sido posible anclar al inicio una página web desde el navegador para luego poder ir directamente a ella. Para controlar el aspecto que tendrá el icono que los usuarios van a anclar es posible utilizar diversas técnicas dependiendo del navegador y el sistema operativo. Así, en iOS, por ejemplo, eso se controla a través de unas cabeceras de tipo «meta» que podemos añadir a la página principal de la aplicación web. En el caso de Android y Chrome se utiliza un archivo llamado «Manifiesto» cuyo nombre es manifest.json (que funciona hace años, desde la versión 38 de Chrome en 2014).
Google además hace que cuando se añade una aplicación al menú de inicio de Android salga un banner de instalación como el de una aplicación real, todo ello conducente a que la experiencia cada vez sea más parecida a la de las aplicaciones nativas. Pero no deja de ser una cuestión cosmética.
