Progressive web apps (o aplicaciones web progresivas), es un término que se da a una nueva generación de aplicaciones que incrementan su funcionalidad, conforme las capacidades del dispositivo en el que se ejecutan, incrementan, de ahí la palabra progresiva. La siguiente parte del nombre web, hace referencia a que se construyen utilizando estándares de desarrollo web, algunos ya conocidos como HTML, CSS y javaScript; y una nueva generación de APIs de javaScript. La parte final app es porque las Progressive Web Apps se comportan como aplicaciones web nativas, pero usan tecnologías web.
Qué son y un poco de historia.
En términos muy simplistas, son páginas web que se comportan como aplicaciones nativas. Es un oración muy simple, pero también muy profunda. Las apps nativas (iOs, Android por ejemplo), históricamente han tenido una serie de ventajas sobre las páginas web, ¿como cuáles? Almacenamiento local, ejecutarse offline, notificaciones push, performance, acceso a hardware, acceso al homescreen del dispositivo, entre otros.
HTML5
Con el paso del tiempo, la brecha entre las web apps y las apps nativas, se ha ido reduciendo. Hace aproximadamente 6 años, HTML5 comenzó a tomar forma, como el concepto que constituía nuevas etiquetas, CSS3 y nuevas APIs de javaScript, cuyo objetivo era hacer las páginas web, más parecidas a las aplicaciones nativas. Ahí, conocimos a localStorage y webRTC, tuvimos acceso al hardware, desde el GPS, hasta la cámara, pasando claro por el micrófono y los altavoces; también nos presentaron nuevos eventos touch, drag&drop, web workers, web sockets que no eran hardware precisamente, pero que buscaban acercar la experiencia de las interfaces web, a la de las apps nativas.
HTML5 fue un salto necesario para la web, pero no parecía llenar por completo el vacío.
** PD: Puedes aprender estas APis de HTML5 (más de 20) tomando el curso de HTML5 Avanzado: http://codigofacilito.com/courses/html5_avanzado
Apps híbridas
Casi inmediatamente después, el proyecto Cordova trajo más vida al desarrollo web, a partir de Cordova nacieron Phonegap y Ionic, dos frameworks para desarrollo de "apps nativas", utilizando estándares web, ¿el problema? El problema es que las, nuevas, aplicaciones híbridas, no terminaban de cerrar la brecha.
Las aplicaciones híbridas ganaron en el terreno de la instalación, push notifications y acceso al hardware, pero, para muchos, perdieron en performance, UX y acceso offline. Esta generación de aplicaciones se sentía más como un parche, que como una solución. Hubieron proyectos que nacieron como apps híbridas, que eventualmente tuvieron que migrarse a apps nativas escritas en JAVA o en Swift.
Progressive web apps
Una nueva generación de estándares web, quiera completar la brecha, algo que me gusta y entusiasma, es que los estándares y los navegadores, han progresado tanto, que ya no buscamos crear aplicaciones nativas, falsas, con tecnologías web; lo que buscamos ahora es crear aplicaciones web, que por sí mismas, cubran las brechas de experiencia que las aplicaciones nativas tenían de ventaja. Son aplicaciones web, no aplicaciones nativas, pero usar cualquiera de ellas es (o debería ser) indiferente para el usuario.
Qué son
Voy a en listar una serie de APIs que son parte del término Progressive Web Apps, así como para muchos HTML5 era un conjunto de APIs, etiquetas y de novedades en CSS... Progressive Web Apps es un conjunto de nuevos estándares, no uno solo, en palabras más claras, PWA es un concepto, un término.
Service Workers
Puedo recordar claramente dos momentos en que programar me impresionó, muy claros, conocer CSS3 y conocer Service Workers.
Un service worker, es un proxy (que tú controlas) entre el navegador y el servidor. A un service worker le puedes decir que responda de X o Y manera a las peticiones, sin llegar al servidor, puede interceptar las peticiones, delegarlas al servidor, o rechazarlas... lo que quieras.
¿Cuál es el beneficio? Las intenciones de los service workers son 2:
- Acceso offline a la página (yei, sin internet)
- Sitios web que cargan rapidísimo (incluso más rápido que las apps nativas)
Para cumplir los dos objetivos antes mencionados, ServiceWorker hace uso de 2 nuevos API's, fetchy cache. Fetch le permite manejar las peticiones que van de la app web al servidor, mientras que Cache, le permite almacenar archivos en el Cache de tu computadora.
Aquí un extracto del código que vemos sobre ServiceWorkers en el curso de Desarrollo Web Frontend donde aprendemos a crear una vista offline para el sitio que desarrollamos:
self.addEventListener("fetch",function(ev){
ev.respondWith(
caches.match(ev.request)
.then(function(response){
if(response){
console.log("Estoy en el cache y te ahorre una peticion")
return response //Devolviendo del cache
}
return fetch(ev.request)
}).catch(function(err){
if(ev.request.mode == "navigate"){
return caches.match("/offline/view.html")
}
})
)
})
Ahí vemos un extracto del Service Worker que programamos, podemos ver cómo intenta hacer la petición, y si falla (el servidor no pudo responder porque no había internet, por ejemplo), enviamos archivos que previamente guardamos en el cache (ese código no aparece).
Este ejemplo es de cómo mostrar archivos distintos para responder a peticiones fallidas, sin embargo, no es el único caso de uso, las service workers son una herramienta para aplicar un concepto que conocemos como Offline first es decir, primero cargamos cosas localmente (sin internet) y luego cargamos del internet. Este enfoque puede servir, por ejemplo, para cargar el CSS y el JS de tu página, antes de que se conecte a internet, haciendo que tu página cargue mucho más rápido.
Además, aquí tienes un ejemplo más elaborado que desarrollamos en el curso de aplicaciones web progresivas:
En este ejemplo vemos el segundo de los beneficios, un sitio que carga muy rápido incluso con una velocidad (simulada vía la consola de Chrome) de internet lenta.
PushNotifications
Las notificaciones en el frontend, no son nuevas, existen muchas aplicaciones que las usan, desde Inbox, Facebook Messenger, Whatsapp, hasta Google Play Music y más. Estas notificaciones se generan desde javaScript y son muy sencillas de crear, revisa este extracto del curso de HTML5, donde vemos el tema de notificaciones:
var notificacion = window.webkitNotifications.createNotification("","Uso de Notification API", "¡Felicidades! Ya has configurado las notificaciones :)");
notificacion.show();
La novedad, es que las notificaciones se pueden, ahora, recibir y mostrar en el background, sin la necesidad de que tengas abierta la página de la que en ese momento recibes notificaciones. Facebook usa esta técnica, recibe notificaciones en el background.
Un ejemplo muy cómico aquí en CódigoFacilito, pasó con Eduardo, desarrollador y tutor. En varios vídeos aparecían notificaciones de Facebook y la gente le comentaba que cerrar Facebook para hacer los vídeos, la realidad es que no tenía dicha página abierta, Facebook las recibe en el background y las muestra aunque no tengas la página abierta. ¿Suena agresivo? Es la forma en como las notificaciones en móvil funcionan, y ahora las tenemos para web.
Otro ejemplo, es ProductHunt, donde puedes ver startups y productos nuevos, cada día, en la mañana, recibo notificaciones de dichos productos, sin la necesidad de instalar nada en mi computadora, ni abrir o visitar la página.
Agrega la página web a tu HomeScreen del móvil
Este feature ha existido desde hace mucho, se hace mediante el uso de un manifesto que colocas en la carpeta principal de tu página web, el siguiente, es un ejemplo de un Manifesto:
{
"name": "messenger",
"short_name": "messenger",
"description": "Clon de Windows MSN para chatear",
"start_url": "/",
"display": "standalone"
}
Es el manifesto que Polymer agrega por default, y es el que tenemos en nuestro curso para Crear un chat clone de Windows MSN. Este manifesto le indica al dispositivo, cómo debe agregar el icono al home de tu pantalla.
Lo interesante, es que también puedes notificarle al usuario de la posibilidad, mientras está en tu aplicación. Vía Digiday, aquí hay una imagen de la aplicación web progresiva del WashingtonPost:
Aquí podemos ver, cómo la app te avisa de la posibilidad de agregar la página web a tu pantalla principal.
Una parte interesante de esto, es que ahora también puedes agregar una imagen que funcione como SplashScreen, la SplashCreen, es la imagen que ves cuando abres una aplicación, se muestra mientras la aplicación se abre, en una aplicación web progresiva, funciona de la misma manera; cuando el usuario hace touch en el ícono de tu app, se despliega el SplashScreen (que tú defines y diseñas), mientras tu aplicación web se inicia, carga y muetra.
Responsive Design
Responsive Design suena tan 2013. Responsive Design es una técnica con la que tus aplicaciones se adaptan al tamaño de pantalla en que se ejecutan, no hay mucho qué decir, es un concepto bien establecido y conocido.
Algunos conceptos que se aplican en Responsive Design, es el diseño fluido, en lugar de usar tamaños fijos y posiciones absolutas, desarrollamos nuestro layout de tal manera que fluya con la pantalla. Otro tema interesante es el diseño Mobile First, en donde diseñamos el contenido, primero, con la forma en que se mostrará en móviles, y luego incrementamos conforme la pantalla lo hace, este es un enfoque que trabaja a la inversa de como la mayoría de los frontends programan. Siguiente, tenemos a las Media Queries, que son reglas de CSS que se aplican únicamente a ciertos tamaños o tipos de pantalla.
Hay que recordar que Responsive Design no es solo una cuestión de tamaños, también es una cuestión de features. ¿Cómo se ve tu página web en un app de lectura como Pocket? ¿En un lector de feeds como Feedly? ¿Cómo se ve si intento imprimirla?.
Siguiendo con el código, este es el que usamos en el curso de Frontend.
media only screen and (max-width: 500px) {
#responsive-nav ul {
top: 95px;
}
}
Vemos, ahí, el uso de un media query, para agregar un top a #responsive-nav ul, pero solo cuando el ancho de la pantalla es menor a los 500px.
Seguridad
Las APIs modernas, no funcionan en HTTP, solo funcionan en HTTPs. ¿Cuál es la diferencia? La conexión de una página vía https, se hace mediante un canal seguro, donde la información no puede ser comprometida.
Cuando navegas por internet, toda tu información es visible vía la red que conecta tu equipo con los servidores que entregan las páginas web, cuando navegas vía HTTP, tu información se envía en texto plano, eso quiere decir, que de interceptarla, puede ser leída tal y como la enviaste. El otro caso, es HTTPs, las páginas que se conectan vía este protocolo, envían la información encriptada, de modo que si yo la interceptara, solo vería caracteres que no tienen sentido, y que solo el servidor puede desencriptar.
Por mencionar un par, las APIs de ServiceWorker, Geolocalización, LocalStorage, getUserMedia... no funcionan si no se ejecutan en un sitio con HTTPs, la única excepción es localhost, de modo que puedes desarrollar sin HTTPs.
Velocidad
Animaciones, eventos, interacción... las progressive web apps ofrecen una interacción rápida y responsiva, cercana o igual a la experiencia de las aplicaciones nativas. Velocidad significa muchas cosas, un render rápido, animaciones fluidas, responder rápido a los eventos del navegador, transiciones, no recargar la página, etc. etc.
Las herramientas para hacer un sitio que responda rápido, generalmente es tener buenos ingenieros, como desarrollador, es importante empezar a desarrollar con el performance en la cabeza. Es un cambio muy pequeño, pero que puede tener un impacto grande.
Aquí un artículo, en extremo interesante, de parte del equipo de Google: https://developers.google.com/web/fundamentals/performance/rendering/
También quiero mencionar, que las aplicaciones web progresivas, pueden incluso ser más rápidas que las nativas, porque corren en una aplicación que el usuario tiene normalmente abierta... el navegador. Si el navegador está abierto, llevas una ventaja, en contra de apps nativas que normalmente no están abiertas.
Otros conceptos.
Otros conceptos relacionados a las progressive web apps son:
- No dependen de la conexión: Esto no es solo que pueden ser accedidas sin internet, es también (y aún más importante) que puedes acceder con una conexión lenta de internet, a las aplicaciones. ServiceWorker es tu amigo y Offline First es tu habilidad
Actualizadas : Vía actualizaciones en el background y web sockets, las aplicaciones progresivas esperan que el usuario reciba la última información en tiempo real.
Son como apps: Se sienten y se ven como aplicaciones nativas, el usuario no debería ver la diferencia.
Son linkeables: La web está basada en links, las apps están yendo hacía allá con algo que ellos llaman Deep Linking. Esta es una de las ventajas más grandes de la web, y es una de las grandes ventajas de las aplicaciones web progresivas. No necesitas instalar nada, puedes descubrirlas navegando, y pueden linkearse entre sí, utilizando estándares.
Apps web progresivas vs App Nativas
No son lo mismo, y usualmente no se usan para lo mismo. El primer grupo que debemos evangelizar hacia las aplicaciones web progresivas, son todas esas páginas (que son páginas) y que hicieron apps nativas solo para estar en tu teléfono, no ofrecen funcionalidades específicas del hardware y básicamente son páginas web empaquetadas. Había muchas razones para crear aplicaciones nativas para páginas existentes, push notifications, fácil acceso por mencionar algunos, hoy ya no.
La mayor ventaja de hacer una progressive web app, es que si ya tienes una aplicación web hecha, es muy sencillo traer la experiencia de una app nativa. Menciono esto, porque también recomendaría a equipos pequeños de trabajo, optar por desarrollar PWA, en lugar de aplicaciones nativas.
Si estás usando Ionic, Phonegap... continúa, también ahí puedes emplear las técnicas y APIs de las app web progresivas.
Mi opinión sigue siendo, si el core de tu negocio es una app móvil, ve nativo, si no, usa web. Si vas a usar web, desarrolla utilizando las técnicas aquí mencionadas.
Conclusión
El futuro se escribe así, hoy, te invito a que presumas cuando tu aplicación se puede ver offline, a que utilices más el storage local, vía LocalStorage o IndexedDB, que coloques ServiceWorkers en tu app, para poder mostrar mensajes offline, o cargar más rápido.
Integra nuevas prácticas de UI, como Material Design, dale la bienvenida a animaciones, pero no por el hecho de animar, si no, crea animaciones que tengan sentido y que cuenten una historia, que le den información al usuario, MaterialDesign ya tiene muchas reglas, y deberías aprovecharlas.
Te recomiendo, también, nuestro plan premium donde tenemos contenido de ServiceWorker, WebComponents y Firebase, que son herramientas o plataformas que te ayudan a crear aplicaciones web progresivas.
Además, ya lanzamos el curso con el que puedes aprender a crear aplicaciones web progresivas: http://codigofacilito.com/cursos/progressive