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 (10) -

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

Hoy puedes desarrollar facilmente para todas las plataformas y dispositivos con un mismo codigo fuente usando Delphi...

Saludos

Responder

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

Claro que sí, y con Xamarin y con React Native y con Cordova... Lo que sobran son plataformas. Pero esto son una serie de técnicas para usar directamente el navegador sin más adaptación, usando HTML, CSS y JavaScript puros. Opciones hay muchas.

Saludos!

Responder

Gracias por responder, pero quería hacerle una pregunta, llevo mucho tiempo trabajando con Delphi, y ahora con el desarrollo para móviles considero que han dando un paso sustancial en ese sentido, pero cuando reviso la documentación en blogs, webs, revistas, no veo a Delphi, ni nadie lo menciona. Personalmente creo que están por encima de muchos en el desarrollo multiplataforma y multidispositivo con aplicaciones nativas. A que usted cree que se deba la ausencia de Delphi en esos foros, tal parece que hubiesen cosas que no se pueden hacer o algo que desconozco y me pudieran explicar, sin caer en el precio de la Licencia, etc. Muchas Gracias, saludos y buen artículo.

Responder

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

Hola Ernesto:

Estoy de acuerdo contigo: Delphi siempre ha sido una plataforma espectacular, que te permitía hacer de todo y siempre adaptándose a los tiempos, y encima usando Object Pascal que es un lenguaje potente pero al mismo tiempo sencillo de aprender (detrás estuvo nadamás y nada menos que  Anders Hejlsberg, ahora detrás de Linq, Typscript... Toda una garantía). De hecho en los años 90 a mi me encantaba y llego a tener una aceptación muy grande en los tiempos de Borland.

En mi opinión (pero puede que esté equivocado) el hecho de que Borland pegase tantos bandazos a finales de esa década, luego la fueran comprando y pasando de manos hizo que muchas empresas viesen demasiado riesgo en la plataforma. Que luego Delphi lo comprase Embarcadero en 2008 yo creo que lo acabó de rematar.

Pero es que además creo que el mayor problema que tiene es el modelo de licenciamiento, que en la actualidad es muy complicado. Y es que su versión más barata cuesta casi 2.000€ echa para atrás a muchos desarrolladores. Lo sé: llega con hacer cuatro números para darse cuenta de que con la productividad que ganas, si te dedicas profesionalmente a esto, ese dinero lo recuperas en la primera aplicación, pero los desarrolladores se han acostumbrado a que todo (o casi todo) debe ser gratis y eso es un grave problema. De hecho, por ejemplo, otra plataforma estupenda como Xamarin no subió en popularidad de verdad hasta que la compró Microsoft hace año y medio y la hizo gratuita. Ahora es quizá la más popular. Es lo que hay :-S

Mi opinión es que plataformas independientes (hasta cierto) punto como Delphi o un similar,  que deban vivir exclusivamente de las ventas del producto y no subsidiadas como están la mayoría de las populares, lo tienen muy difícil. Google puede regalar Angular, Facebook react o Microsoft .NET porque viven de otras cosas y lo que quieren es adopción de sus plataformas. Embarcadero (o Borland en sus tiempos) tenía muy difícil competir con eso porque debían vender sus herramientas para poder vivir. La verdad es que es una pena porque debido a ello no se fomenta la innovación y mejora de algunas herramientas privadas, porque no hay mercado real, pero esto ya es otro tema y daría para hablar largo y tendido, pues tiene sus luces y sus sombras.

Yo hace mucho años que desconecté del mundo Delphi así que desconozco su estado actual exacto, pero si es la mitad de bueno que era entonces, seguro que es un herramienta sensacional, aunque con un gran riesgo de que la empresa que lo gestiona deje de repente de venderlo o darle soporte porque las ventas no lo justifiquen :-S

Saludos!

Responder

Muchas gracias por su respuesta, es cierto lo que comenta y espero que en estos proximos años no muera delphi, pues me formé en él, que tome su camino y deje la historia sin rumbo que tomo hace unos años. Hoy esta centrado en el desarrollo de aplicaciones móviles, multiplataforma y multidispositivo, a una velocidad increible como es RAD, todo se hace con componentes y con poco codigo haces mucho. En mi opinión, ni Xamarin, ni ningun otro el desarrollo para moviles multiplataforma se hace tan rapido y tan facil como en Delphi, en su web usan la palabra ridiculo, es decir ridiculamente agil, y es cierto. Ojalá que se diversifiquen o hagan algo que les permita durar años. Por otra parte, todo me lleva a las aplicaciones progresivas o hibridas para dispositivos moviles, ahora en mi proyecto actual debo usar mongodb, por eso llegue a su articulo y comenzamos este intercambio. Muchas gracias por sus respuestas y continúe publicando artículos. Saludos!

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

Mark Sirocus
Mark Sirocus

Habrá que investigar un poco sobre el tema, me parece muy interesante. Andaba metido en varios temas Angular, NodeJS e incluso quería empezar a jugar con Ionic, pero esto también abre otra nueva ventana.

Responder

Pingbacks and trackbacks (1)+

Agregar comentario