Las capacidades disponibles para sitios web y aplicaciones han cambiado mucho desde los primeros días de las páginas estáticas. Incluso en los últimos tiempos hemos visto muchos avances significativos: animaciones nativas, diseños flexibles simples (finalmente), gráficos 3D reales y transmisión de video, por nombrar algunos. Pero todavía hay más por hacer, especialmente si la web es para competir efectivamente con las plataformas nativas.

Los escritores de especificaciones y los ingenieros de navegación han estado analizando las características que hacen que las plataformas nativas y sus aplicaciones sean tan populares, viendo cómo se combina la web y trabajando arduamente para llenar cualquier agujero en las capacidades de la plataforma web. Básicamente, se reduce a un puñado de características fatales, algunas de las cuales son bastante simples de implementar, otras no tanto. La siguiente no es una lista exhaustiva, pero cubre las áreas principales.

Las aplicaciones nativas son:

Instalable: Tener la aplicación disponible en el dispositivo e integrada con el sistema operativo subyacente se siente bien, incluso mejor si tiene unos pequeños iconos de aplicación tocables en la pantalla de inicio y las aplicaciones se abren en pantalla completa o en su propio cromo. Son las cosas simples, ¿verdad?

Descubrible: a los nerds web no nos gustan las tiendas de aplicaciones cerradas, pero no podemos negar que mejoran la experiencia de encontrar aplicaciones, aunque algunos argumentan que incluso las mejores tiendas de aplicaciones cerradas están fallando debido a la sobrepoblación.

Sin conexión: la conectividad web se siente omnipresente en muchas partes del mundo, pero no se puede confiar en el 100% de las veces. Es molesto no poder usar una aplicación simplemente porque no está conectado, y ya no tiene que ser así.

Involucrarse: una vez que tienes un usuario para usar tu aplicación, la mitad de la batalla ha terminado. ¿Pero cómo los mantienes comprometidos y encima de las últimas actualizaciones? Los desarrolladores nativos de aplicaciones disfrutaron durante mucho tiempo de la disponibilidad de notificaciones push para actualizar usuarios.

Speedy: el código nativo tiene mejor rendimiento que el código web, o eso dicen algunos. Pero como leerá más adelante, la brecha se está cerrando rápidamente.
Sin embargo, la web también tiene algunos beneficios particulares. Es:

Vinculable: es posible vincular a una aplicación web en una URL determinada.

Receptivo: con herramientas como consultas de medios, puede crear diseños de aplicaciones complejos que funcionen en una variedad de factores de forma (orientación, resolución, tamaño de pantalla, etc.). De hecho, el modelo de diseño de sitio web predeterminado de la web es intrínsecamente receptivo, lo que lo hace especialmente útil para el manejo de texto.

Centrado en datos: con HTML para proporcionar semántica y estructura, la web es excelente en el manejo de datos.

Progresivo: puede escribir aplicaciones web que ofrezcan a los navegadores modernos la última bondad brillante, a la vez que proporcionan una experiencia aceptable en los navegadores heredados.

Seguro: la web proporciona capacidades para que las aplicaciones sean seguras, con su modelo de seguridad de origen único y HTTPS. Crear aplicaciones web seguras se ha vuelto aún más fácil gracias a iniciativas como Let’s Encrypt .

Pokedex.org de Nolan Lawson proporciona un gran ejemplo de una aplicación web progresiva que también es una gran cantidad de diversión. Pokedex.org de Nolan Lawson proporciona un gran ejemplo de una aplicación web progresiva que también es una gran cantidad de diversión.
Queremos crear una web que permita el tipo de características geniales que se encuentran en las aplicaciones nativas, pero no a expensas de las cosas básicas que ya hace realmente bien. Este movimiento se denomina aplicaciones web progresivas y está siendo defendido por organizaciones como Mozilla y Google.

Más adelante veremos las nuevas tecnologías que permiten tales avances, pero primero hablemos un poco sobre otros enfoques para ayudar a la Web a alcanzar a los nativos.

Nota: Lo interesante es que las plataformas de aplicaciones nativas también están trabajando para cerrar la brecha con la web desde la otra dirección. Por ejemplo, con artilugios Rube Goldberg-esque que permiten la vinculación profunda.

Lo que vino antes

Las aplicaciones con capacidades nativas no son un concepto completamente nuevo. Para empezar, han aparecido muchos formatos de aplicaciones «web» empaquetadas en varios lugares, por ejemplo, aplicaciones de Chrome, que permiten instalar paquetes verificados en un dispositivo para que se puedan usar sin conexión y tengan permiso para acceder al hardware del dispositivo y similares. .

Hemos tenido las llamadas herramientas de «aplicaciones híbridas» durante un tiempo, por ejemplo, Cordova y Electron. Estos permiten a los desarrolladores escribir aplicaciones utilizando tecnologías web, y luego traducirlas a aplicaciones nativas que se ejecutarán en iOS, Android, etc. Herramientas como esta son muy populares, pero requieren varias versiones de una aplicación para ser creadas y distribuidas, y hay algunas limitaciones en la funcionalidad que tales aplicaciones pueden admitir. No del todo ‘escribir una vez, implementar en cualquier lugar’ como lo conocemos.

También es importante el movimiento fuera de línea. Los defensores han experimentado y han promovido la idea de crear aplicaciones web que se ejecutarán sin conexión de forma predeterminada, y luego se conectan a la red para recibir actualizaciones solo si están disponibles.

Y antes de continuar, vale la pena mencionar el movimiento de aplicaciones de una sola página. En esta, una sola página HTML actúa como el contenedor de la aplicación y carga las diferentes vistas dinámicamente mediante XHR (o similar), con el objetivo de hacer que las aplicaciones web sean más ágiles y más receptivas. Este es el tipo de modelo de aplicación compatible con frameworks populares como Ember.js y AngularJS y, junto con offline-first, forma la base de una gran parte de las aplicaciones web progresivas.

 

Instalación y descubrimiento

La primera área de aplicaciones web progresivas que veremos es la instalación y la capacidad de descubrimiento. Esto es posible utilizando el manifiesto de la aplicación web, que es un archivo JSON que contiene información sobre la aplicación web, como iconos, nombre y modo de visualización para usar al abrir la aplicación:

{
«name»: «My sample app»,
«short_name»: «My app»,
«start_url»: «./?utm_source=web_app_manifest»,
«display»: «standalone»,
«icons»: [{
«src»: «images/touch/homescreen48.png»,
«sizes»: «48×48»,
«type»: «image/png»
}]
…
Esto se puede utilizar para integrar la aplicación más con el sistema operativo subyacente (icono en la pantalla de inicio, se abre a pantalla completa en lugar de en la aplicación del navegador, etc.) y además proporciona una mejor visibilidad en las listas de aplicaciones; por ejemplo, aparecerá en la búsqueda resultados del motor.

Esta información ya es utilizada por Opera y Chrome en dispositivos móviles para la integración de plataformas, con el soporte de Firefox a continuación.

Desconectado

El problema fuera de línea de la web ha persistido durante un tiempo increíblemente largo, teniendo en cuenta lo simple que parece ser a primera vista. El problema es que implementar un conjunto de tecnología fuera de línea efectivo no es nada sencillo. Almacenar los datos de una aplicación fuera de línea no es un gran problema: los navegadores modernos tienen APIs como IndexedDB desde hace un tiempo, y el almacenamiento web es compatible con IE8.

El almacenamiento de activos, por otro lado, es un juego de pelota diferente. Por un tiempo, parecía que AppCache iba a resolver este problema, pero no fue así. Se asumió demasiado sobre la forma en que se configuraría una aplicación, y el desarrollador no tenía suficiente control sobre lo que estaba sucediendo.

Avance rápido hasta ahora, y tenemos trabajadores de servicio; una nueva tecnología disponible en Firefox, Chrome y Opera que permite a los desarrolladores escribir aplicaciones fuera de línea en la misma línea que AppCache, además de muchas otras. Es una API de nivel mucho más bajo, y por lo tanto la sintaxis es mucho más complicada, pero les da a los desarrolladores mucha más potencia sobre cómo quieren que funcionen las interacciones de Service Worker.

La aplicación de sintonizador cromático de Harald Kirschner es un buen ejemplo progresivo que funciona bien en el escritorio o en un dispositivo móvil

Un trabajador de servicio toma la forma de un fragmento de JavaScript escrito en un archivo separado y ejecutándose en un hilo de trabajo especial. Actúa como un servidor proxy, ubicado entre la red y su aplicación (y el navegador). Cuando se realiza una solicitud de un activo, el trabajador del servicio puede interceptarlo y personalizar la respuesta antes de que se envíe de vuelta al navegador para ser utilizado.

Para usar un trabajador del servicio, primero debe registrarlo ejecutando el navegador navigator.service.register () en el hilo principal.

navigator.serviceWorker.register(‘sw.js’)
.then(function(reg) {
// Do something to initialise app
});

Luego instale la aplicación usando un detector de eventos de instalación en el hilo de Trabajador de servicio. Esto a menudo implica el almacenamiento de todos los activos esenciales de la aplicación utilizando la API de caché (que, por cierto, se puede utilizar de forma independiente de los trabajadores de servicio):

this.addEventListener(‘install’, function(event) {
event.waitUntil(
caches.open(‘v1’).then(function(cache) {
return cache.addAll([
‘/sw-test/’,
‘/sw-test/index.html’,
‘/sw-test/style.css’,
‘/sw-test/app.js’
]);
})
);
});

A continuación, use un detector de eventos fetch en el trabajador del servicio para activar el código siempre que se produzca una solicitud. Esto permite a los desarrolladores personalizar la respuesta resultante. Por lo tanto, un desarrollador podría almacenar en caché cada solicitud de archivos que no cambian demasiado (como el shell UI) en el paso de instalación y luego servir las versiones almacenadas sin conexión en la memoria caché cuando se soliciten, en lugar de la versión de red. Bingo, aplicaciones fuera de línea!

this.addEventListener(‘fetch’, function(event) {
var response;
event.respondWith(caches.match(event.request).catch(
// write code to handle case where the requested file
// isn’t already stored offline in the cache
);
});
Vale la pena señalar que los trabajadores del servicio solo trabajarán a través de una conexión HTTPS.

El diagrama de arriba ilustra el ciclo de vida de una instalación de Service Worker

Reintegración del usuario

Las plataformas nativas siempre han confiado en la mensajería instantánea: la capacidad de enviar un mensaje del servidor al cliente para decirle a un usuario que algo ha cambiado, o que algo nuevo está disponible, incluso cuando la aplicación no está abierta. ¿Tal vez una aplicación de noticias quiere compartir las últimas noticias con el usuario? ¿O quizás tu Pokémon está aburrido y quiere algo de atención? Bueno, gracias a la Push API web, ahora también tenemos esta capacidad para aplicaciones web.

Para usar web push, un trabajador de servicio debe estar instalado y activo en la (s) página (s) de su aplicación, tal como se explicó anteriormente. Entonces, nos suscribimos al servicio push. Esto se puede hacer utilizando ServiceWorkerRegistration.pushManager.subscribe () , como se muestra a continuación:

navigator.serviceWorker.ready.then(function(reg) {
reg.pushManager.subscribe({userVisibleOnly: true})
.then(function(subscription) {
// Update UI, etc. in light of subscription
// Update status to subscribe current user on server
var endpoint = subscription.endpoint;
var key = subscription.getKey(‘p256dh’);
updateStatus(endpoint,key,’subscribe’);
})
});

Este método devuelve una promesa que se resuelve con un objeto de suscripción. Este objeto tiene una propiedad de punto final (que contiene una URL única que apunta a un servidor de inserción) y un método getKey () , que se puede utilizar para generar una clave pública con fines de cifrado. Tendrá que acceder a ambos y luego enviar los resultados al servidor de su aplicación.

Para enviar un mensaje de inserción en el servidor, realice una solicitud a la URL del punto final. Esto hace que el servidor de inserción envíe un mensaje al trabajador de servicio de la aplicación. Si desea enviar datos junto con el mensaje de inserción, debe cifrarse con la clave. Los datos de mensajes push actualmente solo funcionan en Firefox, pero los navegadores basados ​​en Blink no deberían estar muy atrás.

El trabajador de servicio escucha un mensaje de inserción utilizando un controlador de eventos push. Una vez que se activa un evento de inserción, puede acceder a los datos del mensaje utilizando la propiedad de datos del objeto de evento. Luego, puede responder al mensaje como quiera, por ejemplo, activando una notificación o enviando un mensaje de canal al hilo principal para actualizar su aplicación de alguna manera.

self.addEventListener(‘push’, function(e) {
var obj = e.data.json();

// Respond to the push message in some way
// e.g. a notification or channel message
});

Nota: la mayor parte de la familia de tecnologías de Service Workers (Push y demás) disfrutan de un soporte razonable en Chrome y Firefox, y otros navegadores las consideran cuidadosamente. Los datos push solo funcionan en Firefox en el momento de la escritura.

Esta aplicación de Mozilla proporciona información de progreso sobre la implementación de API web modernas en navegadores

Actuación

El rendimiento ha sido durante mucho tiempo un punto delicado entre las aplicaciones web y las aplicaciones nativas, y los desarrolladores nativos descartan las capacidades de rendimiento de la web. Pero la brecha es significativamente más estrecha en la actualidad, con motores de JavaScript mucho más rápidos en los navegadores y un código rápido en el navegador para ejecutar cosas como animaciones y gráficos 3D, que pueden aprovechar cada vez más la potencia de la GPU disponible.

Además, ahora somos capaces de transpilar código nativo (como C ++) a través de JavaScript, usando tecnologías como Emscripten. Cuando decimos JavaScript aquí, estamos hablando de asm.js, un subconjunto altamente optimizable de JavaScript que puede aprovechar las técnicas de compilación de AOT para ofrecer un rendimiento casi nativo. Esto ha demostrado ser tan popular que no sólo es compatible con Firefox, sino también con Chrome y Edge, y asm.js / web se ha agregado como objetivo de publicación para los populares motores 3D Unity y Unreal.

Y la próxima generación está en camino: varios proveedores de navegadores están colaborando en la especificación e implementación de WebAssembly, que hará algo similar a Emscripten, pero de una forma más rápida, más estándar y más eficiente.

Utilizará un formato llamado wasm, en lugar de asm.js. Dado que tendrá una especificación concreta, deberíamos poder confiar en que los compiladores envíen un wasm válido y los navegadores luego ejecuten ese resultado de forma consistente, independientemente de qué compilador lo haya creado. Mira este espacio.

Conclusión

Como puede ver, la web continúa evolucionando, con algunas nuevas tecnologías emocionantes diseñadas para abordar algunas de las deficiencias restantes que tradicionalmente ha sufrido nuestra plataforma amada, así como con un rendimiento aún mejor. Esto permitirá que las aplicaciones web se mantengan orgullosas al lado de las aplicaciones nativas, sin perder de vista lo que hizo que la web sea ideal para empezar.

[orbital_cluster categories=»6″ order=»DESC» orderby=»rand» postperpage=»100″]