Superwebapps: Repensando las Aplicaciones de Escritorio con Progressive Web Apps

Hola a todos. Mi nombre es Nico. Soy un desarrollador front-end de Suiza, y aquí conmigo está MDEdit. MDEdit es una herramienta que convierte Markdown en HTML, y luego proporciona un editor de lo que ves es lo que obtienes que te permite, o que te ayuda, a escribir HTML que luego se convertirá de nuevo en Markdown. En otras palabras, es una aplicación de edición de Markdown o un sitio web de edición de Markdown. Quiero decir, MDEdit está un poco en una crisis de identidad, porque ¿qué es? ¿Es un sitio web? ¿Es una aplicación? ¿Es una herramienta que utiliza HTML, CSS y JavaScript? Pero quiere hacer mucho más. Quiere leer archivos. Quiere escribir archivos. Quiere funcionar sin conexión. Así que es más bien una aplicación web con superpoderes. Hablando de superpoderes, ¿tenemos aquí algún fanático clásico de los cómics de DC? ¿Lo tenemos? Bueno, tal vez podamos ayudar a mi pequeño amigo. Porque ¿qué es? ¿Es un sitio web? ¿Es una aplicación? ¿Es un pájaro? Para decirlo de manera sencilla, es una Súper Aplicación Web, o al menos eso es lo que habrían sido llamadas si me hubieran dado la oportunidad de nombrar esas cosas. Desafortunadamente, o también afortunadamente para todos los demás, Alex Russell fue mucho antes que yo, y en ese entonces trabajaba en Google, y estaba pensando mucho en cómo unir la brecha entre el navegador y las aplicaciones nativas. Y estaba pensando en sitios web a los que se les podían otorgar más y más permisos. Se convertirían progresivamente en aplicaciones. Así que acuñó el término aplicaciones web progresivas. Y tal vez ya hayas escuchado mucho sobre aplicaciones web progresivas en términos de aplicaciones móviles. Sin embargo, la web es única en el sentido de que no está diseñada para un sistema operativo específico o una resolución de pantalla específica, sino que debería funcionar de manera universal. Por lo tanto, me gustaría centrarme en algunas de las capacidades que también permiten a las aplicaciones web de escritorio tener algunos superpoderes. Pero empecemos con lo básico. La pregunta subyacente para las aplicaciones web que se ejecutan tanto en escritorio como en móvil es, ¿qué problemas necesitan resolver para ofrecer una experiencia de usuario verdaderamente comparable? En primer lugar, deben ser rápidas, porque no queremos tener un spinner de carga si haces clic en una aplicación o en un archivo. Debería estar ahí de inmediato. Debe estar integrada, por lo que debería sentirse como parte del sistema operativo, una extensión del sistema operativo. Debe ser confiable, incluso si no tenemos conexión a Internet o tenemos una mala conexión a Internet, deberíamos poder usar la aplicación. Y debe ser atractiva, por lo que deberíamos poder volver a interactuar con nuestros usuarios, por ejemplo, mediante notificaciones push. Para resolver esos problemas, los navegadores tuvieron que introducir dos nuevos conceptos fundamentales, el Manifiesto de la Aplicación Web y el Service Worker. El Manifiesto de la Aplicación Web, lo siento, es básicamente solo un JavaScript, un archivo JSON que contiene información sobre la aplicación. Primero, necesitamos registrar el manifiesto, que básicamente es una línea de HTML que apunta a el archivo, y luego el archivo en sí contiene información como el título, el nombre corto, la descripción, los colores, y eso es todo. Entonces mi navegador, en este caso, Edge, sabe que ahora tenemos una PWA instalable, y ofrece instalarla. Hay más y más propiedades capaces que veremos en esta charla.

Lo segundo más importante es el Service Worker. Primero que nada, mi aplicación es una aplicación JavaScript, por lo que hay mucha lógica de aplicación escrita en JavaScript, lo cual es genial porque realmente me gusta JavaScript. Pero nuevamente, tan pronto como cerramos el sitio, tan pronto como cerramos el navegador, simplemente, JavaScript está muerto. Ya no hay cosas sucediendo dentro de nuestro app.js, por lo que ya no podemos interactuar con él. El Service Worker también es un fragmento de JavaScript, pero vive en un ámbito separado. Se registra entre la aplicación web y el navegador, y allí puede escuchar eventos, interactuar con el sitio, incluso si el navegador está cerrado, por lo que permanece allí para siempre. No está vinculado al ciclo de vida de nuestra aplicación. Para registrar el Service Worker, podemos llamar a esta función navigator.serviceworker.register, que apunta al Service Worker. Tiene algunos parámetros opcionales como el ámbito, por lo que en nuestro caso, nuestro Service Worker controla todo, nuestro sitio y todas las subcarpetas también. También podemos crear un nuevo Service Worker que controle ámbitos específicos dentro de nuestra aplicación, por lo que podríamos tener el Service Worker de Acerca de que solo controle todo dentro de esta carpeta de Acerca de, por ejemplo. Y luego, dentro del Service Worker, es solo JavaScript. Tenemos escuchadores de eventos, por lo que cada vez que alguien visita la página, se dispara este evento de Instalación. Luego, una vez que ocurrió la instalación, tenemos el evento de Activación. Luego, cada solicitud pasa por el Service Worker con el evento de Obtención, y también si alguien intenta alcanzar nuestro Service Worker desde algún servidor, por ejemplo, tenemos el evento de Envío al que podemos escuchar. Hasta ahora, todo bien. Pero volvamos a nuestra súper aplicación web y sus superpoderes. Comencemos con el problema número uno, la Súper Aplicación Web y el sueño de la independencia de la red. Es un hermoso día, el sol brilla, nuestra súper aplicación web intenta solicitar algunos recursos del servidor, hace una solicitud al servidor, regresa con la respuesta, todo está bien. Pero de repente, la conexión a Internet se ha ido. Lo siento, ahí vamos. Diferente. La conexión a Internet se ha ido, y bueno, Donasaurio aparece, muerte segura para todas las aplicaciones web clásicas. No es así para nuestra súper aplicación web, porque tenemos el superpoder del Service Worker. Ahora el Service Worker se encuentra entre el sitio web y la Internet, y también puede interactuar con el almacenamiento de la aplicación. Entonces, incluso si se pierde la conexión a Internet, todavía tenemos una fuente confiable para atender nuestras solicitudes. ¿Cómo podemos usarlo? En este caso, tenemos nuestro SVG, tenemos una imagen de respaldo SVG y queremos mostrar el respaldo SVG cuando falla una solicitud de una imagen SVG. En primer lugar, en el evento de instalación, abrimos la caché, luego colocamos este respaldo SVG en la caché. Luego, una vez que tenemos el evento de obtención, primero verificamos si el recurso solicitado es realmente un SVG. Si ese es el caso, tenemos event.responseWith, que básicamente se hace cargo de la solicitud. Allí podemos pasar la solicitud al servidor.

Pero si falla, si hay que cachear, podemos devolver la imagen que ya está en caché. Otro ejemplo sería cuando tenemos una, digamos, una caché de imágenes en primer plano sin conexión. En ese caso, queremos cachear todas las solicitudes de imágenes. Tomaremos el control de la respuesta. Luego verificaremos si ya tenemos esa solicitud en caché. Si ese es el caso, simplemente lo devolveremos de inmediato. Así que eso es súper rápido. Si no, obtendremos los data del servidor. Luego clonaremos la respuesta. Podemos cachear la respuesta y la devolveremos. Así que la próxima vez que solicitemos la misma URL, se devolverá directamente desde la caché, lo cual es inmediato. Ahora hay una herramienta que nos ayuda con eso, que es Workbox.js. Básicamente es una abstracción sobre el Service Worker y la API de cachés. Básicamente hay complementos para todo tipo de casos de uso. También hay integraciones para todo tipo de sistemas de compilación. Y sí, hace que sea muy fácil usar la caché del Service Worker. La caché del Service Worker es increíble porque nos permite cachear o interceptar directamente las solicitudes de red a un nivel muy bajo. Pero nuevamente, otro problema común es que necesitamos data que tal vez esté almacenado. Necesitamos almacenar data dentro de la lógica de nuestra aplicación. Por ejemplo, podría ser data generado por la aplicación. Podría ser data de una API REST donde queremos tener una forma más estructurada de cachear esas entradas. Y ahí tenemos varias posibilidades. Tenemos el almacenamiento de sesión y local. Ambos son pares clave-valor simples. El almacenamiento de sesión es solo para una sesión. El almacenamiento local persiste durante varias sesiones, pero ambos tienen un tamaño bastante limitado. Solo podemos almacenar alrededor de 5 megabytes. Si tenemos más data para almacenar, podemos usar, por ejemplo, IndexedDB, donde tenemos esta API de navegador de bajo nivel que permite a las aplicaciones web almacenar y manipular grandes cantidades de data estructurados. Incluso podemos hacer consultas e indexación sobre ese data. Y luego tenemos la API del Sistema de Archivos Privado de Origen, que nos permite crear, leer y actualizar archivos en un sistema de archivos privado, lo que significa que forma parte del sistema de archivos del usuario, pero no es visible para el usuario ni para ningún otro origen que no sea nuestra aplicación web.

La otra pregunta, ¿qué tan confiable es el data almacenado para una aplicación web? Tenemos la API de Almacenamiento Persistente. Es una API que nos permite solicitar permiso para almacenar de forma persistente data para una aplicación web. La otra gran pregunta es ¿cuántos data podemos almacenar? Lo bueno es que siempre depende del navegador y del sistema operativo, pero al menos en Chrome y Edge, en Windows, básicamente podemos almacenar tanto data como hayamos almacenado, dejado en nuestro dispositivo. Así que si tenemos 500 gigabytes en nuestro dispositivo, básicamente podemos usar 500 gigabytes de data para nuestra aplicación web. Sí, lo cual nos lleva a nuestro próximo tema en la serie, SuperWebApps Data Dive into the File System ABIS. Siempre ha sido posible leer el blob de un archivo usando el elemento de entrada de archivo, y después de eso, también era posible proporcionar un enlace de descarga al archivo, pero eso es todo. Por lo tanto, no era posible interactuar más con el sistema de archivos. La API de Acceso al Sistema de Archivos intenta cambiar eso. Con esta API, ahora es posible leer archivos o directorios completos en el dispositivo del cliente, y además, también es posible escribir cambios directamente en ese archivo. Así que cada vez que queramos interactuar con un archivo, ahora necesitamos tener un identificador de archivo. Básicamente hay dos formas de obtener el contenido de un archivo. En el primer escenario, no tenemos un identificador de archivo. Aquí usamos este método de selección de archivo abierto, que abre un cuadro de diálogo de selección de archivo y permite al usuario seleccionar uno o más archivos. Después de eso, el usuario ve esta solicitud aquí a la derecha que pide permiso donde debemos confirmar que la aplicación web tiene permiso para manejar un archivo, y un gran aspecto es que esos identificadores, son serializables. Así que podemos almacenarlos, por ejemplo, en IndexedDB. En el segundo escenario, ya tenemos el identificador, tal vez desde IndexedDB, pero los permisos solo se otorgan para una sesión. Entonces, una vez que cerramos la aplicación, necesitamos solicitar permiso nuevamente. En este caso, solo necesito permiso de lectura. Después de eso, nuevamente puedo obtener el archivo y leer el contenido y estamos listos para continuar. Después de eso, también queremos escribir contenido de vuelta al archivo. Primero que nada, necesitamos actualizar nuestros permisos. Ahora necesitamos permiso de lectura-escritura. Luego podemos crear un objeto escribible, escribir contenido en el objeto escribible, cerrar el objeto escribible y eso es todo. Está guardado en nuestro archivo. Así de simple. Luego nuevamente, ¿realmente queremos abrir una aplicación, seleccionar el archivo dentro de la aplicación y luego abrir el archivo? Es posible, pero no muy conveniente. Cuando abrimos un documento de Word, por ejemplo, simplemente hacemos doble clic en el icono. Se abre Word con el documento ya abierto. Entonces, ¿por qué no deberíamos poder hacer lo mismo con las web apps? Lo cual nos lleva a nuestro tercer tema, la revolución del manejo de archivos. La idea de la API de manejo de archivos es que una vez que se instala una aplicación web, podemos usar la aplicación web para abrir archivos directamente.

Incluso podemos utilizar la aplicación web como la aplicación predeterminada para un cierto tipo de archivo. Entonces, cuando el usuario hace doble clic en el archivo, se abrirá en la aplicación web. Y todo esto es posible utilizando esta nueva propiedad de manejo de archivos en el manifiesto. Aquí podemos definir los tipos de archivo que nuestra aplicación puede manejar. En este caso, queremos manejar archivos Markdown junto con una acción que funcione de manera similar a una acción de formulario, básicamente. También significa que podemos utilizar la misma aplicación web para diferentes tipos de archivo. Por ejemplo, también podríamos utilizar la misma aplicación web para archivos de texto, con una acción diferente o también con la misma acción. Dentro de nuestra aplicación, podemos utilizar la API de la cola de lanzamiento para recibir un archivo entrante. Entonces, la API de manejo de archivos activa la acción y la API de la cola de lanzamiento consume el archivo. Y eso es todo. Es una API bastante simple para nosotros, los desarrolladores, pero es extremadamente conveniente para el usuario. Eso fue mucho contenido técnico por ahora, ¿verdad? Volvamos a nuestros superhéroes de DC. ¿Alguien sabe el nombre de este icónico trío? Eso es Trinity. Así que cada vez que Superman tenía un problema que era demasiado grande para él solo, llamaba a Wonder Woman y a Batman para que lo ayudaran. En el mundo web, no tenemos a Trinity, pero tenemos algo aún mejor. Tenemos Project Fugu. Project Fugu es un proyecto interorganizacional, principalmente de Google, Microsoft e Intel, para cerrar la brecha entre aplicaciones nativas y aplicaciones web. Así que abramos el problema número cuatro, la épica batalla en la cocina para domar al Fugu. El nombre del proyecto se basa en el pez Fugu, que se supone que es una delicia. No puedo juzgarlo porque nunca lo he probado, pero también es extremadamente peligroso de preparar. Así que el núcleo del proyecto Fugu es una lista de nuevas APIs que supuestamente acercarán la web a las aplicaciones nativas. Pero también debemos tener cuidado de cómo se implementa y cómo podemos usarlo. Hay bastantes APIs nuevas, por ejemplo, APIs que nos permiten interactuar con dispositivos de hardware. Hay APIs que ya hemos discutido, como el acceso al sistema de archivos y el manejo de archivos. Y hay un montón de nuevas APIs. Y algunas de ellas están en prueba de origen. Algunas de ellas están en desarrollo. Así que debes consultar el rastreador antes de usarlas. Pero hay una API que fue particularmente útil para MD Edit y es la API de acceso a fuentes locales porque nos permite acceder a las fuentes instaladas localmente en el dispositivo del usuario. Como puedes ver aquí en el lado izquierdo, podemos llamar a la función window.queryFonts, que mostrará una solicitud al usuario pidiendo permiso para acceder a las fuentes.

Si se concede, recibirás una matriz de objetos de fuentes. Esto me permite crear un cuadro de selección donde el usuario puede elegir una fuente que establezca una variable de CSS personalizada responsable del markdown o del editor específico.

Por ahora, nuestros héroes han rascado la superficie de muchas nuevas superpotencias, pero abramos el problema número cinco, donde el superhéroe une todos los poderes para algunas demostraciones sobresalientes. En primer lugar, tengo MD edit. Ahí vamos. Lo que tengo aquí en mi sistema local es un archivo Markdown, que puedo abrir con el editor. Y como puedes ver, básicamente es solo información sobre el React Summit.

Lo que puedo hacer entonces es abrirlo en MD edit, el mismo archivo desde el escritorio. Ahí vamos. Y puedo decir, por ejemplo, hola mundo. Y luego puedo guardar el contenido. Sí, quiero hacer eso. Si ahora abro la aplicación, puedes ver que se guarda directamente en nuestro archivo. Bastante genial, bastante conveniente, pero podemos ir aún más lejos. Ahora podemos instalar la aplicación. Tarda unos segundos. Ahí vamos. Y ahora podemos ver que se abre directamente en el, digamos, diseño que especificamos. Ahora puedo cerrarlo. Ahora puedo decir, bueno, vamos aquí. Abrir eso con MD edit. Ahí vamos. Y ahora podemos abrir el archivo directamente con MD edit. Ahora también puedo usar la API de acceso a fuentes para, digamos, cambiar la fuente visívica a, ahí tienes, algo diferente y así sucesivamente. Y por último, pero no menos importante, también puedo decir que siempre quiero usar MD edit para abrir archivos Markdown. Así que cada vez que veas que el icono ya ha cambiado. Y cuando hago doble clic en eso, se abre directamente en MD edit, en nuestra aplicación. Eso es bastante genial. Ahora, además de mis propios experimentos, vamos a cerrar eso, también hay grandes empresas que ya están utilizando esas APIs. Por ejemplo, VS Code, donde tenemos toda la experiencia de Visual Studio Code directamente en el navegador.

Tenemos Clipjam, que es una plataforma completa de edición de video directamente en el navegador. E incluso Adobe Invest, tenemos Photoshop para la web. Entonces, muchas de las APIs que has visto o muchas de las características que proporciona Photoshop también están disponibles en Photoshop web.

Para resumir, la idea de tener una aplicación que se ejecute una vez y luego se ejecute en cualquier lugar, o que se escriba una vez y se ejecute en todas partes, ha sido una gran necesidad para los desarrolladores desde el inicio del desarrollo, yo diría. Durante mucho tiempo, pensamos que tal vez Java sería la solución. Y creo que escribir una vez y ejecutar en cualquier lugar también fue el eslogan de Java en algún momento, hasta que descubrimos que no es bueno para crear interfaces de usuario.

También tenemos Electron, donde tenemos nuestro navegador, o tenemos el motor del navegador junto con la aplicación, lo que también significa que enviaremos todo el motor del navegador con cada aplicación que escribamos. Y tenemos múltiples instancias de, por ejemplo, Chrome instaladas en nuestro dispositivo. Ahora intentamos resolver eso. Pero nuevamente, necesitamos enviar. Así que tenemos todo el desvío a través del proceso de instalación. Y ahora, con las Web Apps Progresivas, tenemos soluciones que son accesibles a través de URL, que están profundamente integradas con el sistema operativo. Funcionan sin conexión y son increíblemente pequeñas en comparación con todas las soluciones multiplataforma.

Con eso, muchas gracias por su atención. Mis diapositivas están detrás de ese código QR. Si tienen alguna pregunta, estaré encantado de responder en el canal de Discord. Bueno, hasta la próxima, espero que lo pasen muy bien. Y nuevamente, muchas gracias por su atención. Adiós.