Menú de navegaciónMenú
Categorías

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

?id=94ca5d4f-f3e6-467b-a09e-5663a43a9d78

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

Progressive-Web-Apps

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.

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

Fecha de publicación:
José Manuel Alarcón Fundador 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. Microsoft lo ha reconocido como MVP (Most Valuable Professional) en desarrollo web desde el año 2004 hasta la actualidad. 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 nada, recibe lo mejor en tu email

Si te ha gustado este art­ículo, únete a miles de desarrolladores que ya reciben cada mes nuestro boletí­n por email. No te pierdas los mejores trucos, noticias y frikadas.

Enviamos poco, pero bueno. Palabra de desarrollador.

Suscríbete aquí­

Sí­guenos también en:

Telegram LinkedIn YouTube
La mejor formación online para desarrolladores como tú

Comentarios (25) -

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

Jafeth Vásquez Herrera
Jafeth Vásquez Herrera

Los invito a probar también Flutter, es un nuevo framework de Google para desarrollar aplicaciones nativas, multiplataforma. Te permite reutilizar todo el código, programas una vez y ya pueden instalar en Android y IOS.

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

Me ha gustado, gracias por la informacion.

Responder

Pablo López
Pablo López

He visto que las PWA se pueden desarrollar con HTML5 y JavaScript, obviamente CSS, también he visto que se puede trabajar con varios Frameworks, pero en el caso específico de Angular 2-5 sólo he visto que lo trabajan con Angular Universal.

Mi duda concreta es, siguiendo las reglas de las PWA podría construir una desde Angular 5 (sin usar Angular Universal) o es necesario usarlo.

Por que entiendo que Angular Universal entre varias cosas que ofrece una de las más importantes es que el código se renderiza desde el servidor, además de que la app se construye desde el backend.

Y a esto me surge una duda más, en caso de que sea posible, que desventaja hay en hacer una PWA en Angular 5 si mo servidor es un API que ya está funcionando por su cuenta.

Esto por que he probado Angular Universal y he notado no que no tiene las funcionalidades de Angular 5 "normal".

Saludos y muchas gracias por el post.

Responder

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

Hola Pablo:

Angular Universal es una forma de hacer que las aplicaciones web creadas con Angular se rendericen en el servidor en lugar de en el cliente.

Las PWA "viven" en el lado cliente y aunque Angular no tenga nada específico para crearlas, por supuesto que puedes hacerlas, porque como explico en el artículo, crearlas no depende de un framework concreto, y se pueden hacer incluso con HTML5 "puro" (HTML+CSS+JS). El Kit que existe para Angular Universal, simplemente te da algunas cosas ya hechas en una plantillas, pero sería lo mismo que harías tu por tu cuenta. En este caso las páginas se renderizan en el servidor antes de enviarlas al cliente, pero podrías coger el código de lado cliente tal cual y reutilizarlo.

En cuanto a tu caso: si ya tienes una API en el servidor, lo lógico es que hagas la aplicación con Angular 5, en lado cliente, utilizando esa API. Lo de renderizar Angular en el servidor solo te será útil en casos muy concretos en lo que el tiempo de generación de una página concreta sea muy crítico y sea preferible transferirla ya generada desde el servidor a generarla de la manera convencional en el lado cliente o por temas de SEO, algo que en aplicaciones normales no debería preocuparte demasiado (eso preocupa más en webs convencionales que en apps).

Saludos.

Responder

Pablo López
Pablo López

Muchas gracias por tu pronta respuesta, me es muy útil la información justo ahora que estoy por iniciar un nuevo proyecto y quiero poder llevar todas estas prácticas desde ahora.

Te mando un abrazo y saludos.

Responder

Un buen articulo.

Responder

Muy interesante.

Responder

Maria Rosal
Maria Rosal

Hola,

He leido bastantes artículos y aun no me ha quedado claro si cuando haces una PWA puedes subirla al store de IOS?
Al final los usuarios aun están acostumbrados a descargarse las apps y más cuando decides cambiar de una app nativa a apostar por PWA.

Muchas gracias de ante mano.

Responder

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

Hola María:

No. Precisamente la gracia de las PWA es que no tengas que instalar nada ni ir a la tienda. Lo que se suele hacer es incluir un aviso automático (la primera vez que entra el usuario o hasta que lo decida cerrar conscientemente) indicando que lo añada a la página de inicio.

Por ejemplo, aquí te he dejado la notificación que muestra la app de Twitter en cuanto accedes desde el navegador en Android:

https://cl.ly/71f73c5e0033

Al pulsar en la notificación de la parte de abajo se instala automáticamente como una app más y se usa de manera casi indistinguible (depende de lo bien hecha que esté la PWA).

Esto es bueno para los usuarios (ya que no tienen que complicarse: es dar a un botón y listo) y para los desarrolladores (nada de complicarse la vida compilando, pasando los requisitos de Google y Apple, pagando la tarifa anual de las tiendas...) y además se actualiza sola cada vez que entras si hay novedades. Son una gran idea.

Espero habértelo aclarado.

Saludos.

Responder

Maria Rosal
Maria Rosal

Gracias por tu respuesta y perdona que me generan más dudas....
Pero si yo entro en los stores de Twitter me encuentro la app, la estrategia es que siguen manteniendo las webs nativas y van cambiando a PWA??
Graicas.

Responder

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

No, simplemente tienen las dos: la nativa y la PWA. Digamos que una no excluye (en absoluto) a la otra. Son diferentes opciones. Por ejemplo, si tu móvil no es muy potente o no tiene mucho espacio libre de almacenamiento, la PWA te va a ir mucho mejor y no perderás funcionalidades (en el caso de Twitter) ya que incluso puedes recibir notificaciones, etc...

Responder

Maria Rosal
Maria Rosal

Quieres decir que con PWA no puedes enviar notificaciones?? en tu escribo entendí que si... vaya lio llevo!!!!

Responder

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

No, todo lo contrario: acabo de decir que SÍ pueden enviar notificaciones.

Responder

Hola! Cómo puedo encontrar su  curso de APIs de HTML5 ?

Muchas gracias.
Saludos.

Responder

campusMVP
campusMVP

Hola Carolina:

Este curso no está dipsonible para compra independiente. Forma parte de nuestro Máster en Desarrollo Web Front-End (www.campusmvp.es/.../...nes-Web-Front-End_219.aspx) y también forma parte del curso de Especialista en Programación Web con HTML5, CSS3, JavaScript y jQuery (www.campusmvp.es/.../...vaScript-y-jQuery_235.aspx), pero no está disponible para compra de manera individual, lo sentimos.

Saludos.

Responder

Pingbacks and trackbacks (1)+

Agregar comentario

Los datos anteriores se utilizarán exclusivamente para permitirte hacer el comentario y, si lo seleccionas, notificarte de nuevos comentarios en este artículo, pero no se procesarán ni se utilizarán para ningún otro propósito. Lee nuestra política de privacidad.