Qué son las Aplicaciones Web Progresivas o "Progressive Web Apps"
Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

Qué son las Aplicaciones Web Progresivas o "Progressive Web Apps"

Progressive-Web-Apps

Últimamente se está escuchando mucho una nueva buzzword, PWAs, que se refiere a las Aplicaciones Web Progressivas o Progressive Web Apps en sus siglas en inglés.

Si nos atenemos a lo que se oye, deben de ser lo mejor que se ha visto en desarrollo web desde que se inventó JavaScript, pero ¿qué hay de cierto y qué hay de "hype" en todo esto? ¿Son para tanto o es más una moda?

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 hay muy pocas aplicaciones web que funcionen de esta manera. En primer lugar porque casi nadie ancla nada a la pantalla de inicio, pero también porque no son tan ágiles normalmente como las nativas, no tienen un aspecto igual de natural y, sobre todo, porque las aplicaciones web carecen 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 es muy complicada.

Es ahí donde entran las AWPs.

¿Qué es una Aplicación Web Progresiva?

Google ha sido el que ha promovido 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.

En realidad para algunas cosas no es necesario utilizar un Service Worker. Por ejemplo, es posible crear aplicaciones web que funcionen off-line (sin conexión) utilizando la API de AppCache. El Service Worker nos puede dar más funcionalidad, sobre todo si necesitamos tomar decisiones a la hora de cachear la información y no solo asegurar que se encuentra almacenada, pero no son estrictamente necesarios. Es decir, para crear una PWA no es necesario estrictamente usar Service Workers salvo que requiramos ciertas funcionalidades avanzadas.

En el momento de escribir esto los únicos navegadores que permiten el uso de Service Workers son Chrome (el promotor de los mismos) y Firefox. En el caso que nos ocupa, los móviles, el único navegador móvil que ofrece soporte para esta tecnología es Chrome 51 o posterior en Android. Si queremos que la PWA funcione también en iOS, Windows Phone o teléfonos Android que no sean muy recientes, no estamos de suerte.

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 o Windows Phone 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).

Hace poco Google ha hecho 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.

Esto, nuevamente, solo funciona con Chrome en Android, así que no sirve de mucho en otros sistemas, aunque todos tienen algo similar para definir el aspecto de los accesos directos.

En resumen

Aunque las PWAs ahora parecen estar muy de moda y pueda parecer que nos quedamos atrás por no "controlarlas", en mi opinión hay mucho de hype detrás de ellas.

Realmente lo más importante y complejo que tienen es el uso de los Service Workers. No obstante hay que tener en cuenta que los usos de esta tecnología son los que son y ya existen multitud de bibliotecas que nos dan muchas de las funcionalidades hechas, y algunos frameworks de desarrollo están metiendo ya la funcionalidad de serie, sin que tengamos que hacer nada.

Que nadie me malinterprete. No quiero decir con esto que las PWAs no sean interesantes o que no haya nada que aprender acerca de ellas. Al contrario. Simplemente quiero desmitificarlas un poco y resaltar que no se trata de una tecnología nueva y maravillosa que acaba de aparecer y que tenemos que aprender desde cero. Es más bien un conjunto de tecnologías pre-existentes, técnicas y patrones sencillos que nos ayudan a conseguir aplicaciones web orientadas a móviles que se comportan cada vez más como aplicaciones nativas.

De momento muchas de las técnicas que necesitan las PWAs solo están disponibles para Chrome sobre Android, y además solo en versiones recientes del navegador, así que la audiencia es limitada. Sin embargo, teniendo en cuenta que Android representa el 85% del mercado de móviles puede que en el medio plazo lleguemos a mucha más gente.

Ahora sería estupendo que el resto de navegadores y sistemas operativos siguieran la estela marcada por Google y dieran soporte para todo esto en su software.

En la página de Google para las Progressive Web Apps puedes encontrar varios ejemplos de aplicaciones web creadas de esta manera así como abundante documentación.

Espero haberte aclarado las ideas alrededor de esta tecnología de moda :-)

José Manuel Alarcón Director de campusMVP, es ingeniero industrial y especialista en consultoría de empresa. Ha escrito diversos libros, habiendo publicado hasta la fecha cientos de artículos sobre informática e ingeniería en publicaciones especializadas. Puedes seguirlo en Twitter en @jm_alarcon o leer sus blog técnico o personal. Ver todos los posts de José Manuel Alarcón

No te pierdas ningún post

Únete gratis a nuestro canal en Telegram y te avisaremos en el momento en el que publiquemos uno nuevo.


Comentarios (4) -

Esperemos que en un futuro próximo, podamos prescindir de desarrollar varias versiones de nuestra aplicación: IOS, Android, Windows y Web y solamente tengamos que hacer una que funcione de la misma forma en movil (android e ios), además de escritorio.

Yo por ahora, ya estoy adaptando varias webs sencillas para que se comporten como "progressive web apps".

Muy buen artículo José, como siempre :).

Responder

José Manuel Alarcón
José Manuel Alarcón

Gracias Eduardo :-)

Responder

Hola, muy buen articulo. Me parecen muy interesantes.

Sabrían de algún curso aparte de la documentación de google?

Gracias.

Responder

José Manuel Alarcón
José Manuel Alarcón

Hola Álex:

Realmente, como explico en el artículo, lo que implican es seguir buenas prácticas y conocer unas APIs muy concretas, pero poco más, y su aplicación de momento es pequeña.

Nuestro curso de APIs de HTML5 (incluido en el 70-480 y en nuestro máster) es muy potente y tiene de todo, pero no trata los Service Workers, precisamente por su pequeña aplicación ahora mismo, pero lo acabaré incluyendo más pronto que tarde...

Saludos!

Responder

Pingbacks and trackbacks (1)+

Agregar comentario