Más allá del marco de trabajo: Distribuye tu aplicación de escritorio como un profesional

Rate this content
Bookmark

Construir aplicaciones utilizando tecnología web es genial; sin embargo, a veces puedes encontrar limitaciones sin importar qué marco de trabajo elijas. Durante esta masterclass, hablaremos sobre cómo elegir un marco de trabajo, problemas comunes y cómo superarlos.


Tabla de contenidos

- Introducción: La historia entrelazada de la Web y las aplicaciones

- ¡Tantas tecnologías de aplicaciones de escritorio! ¿Cómo elijo una?

- Problemas comunes y cómo pensar en las aplicaciones

- Conclusión

109 min
16 May, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Bienvenido a la masterclass Más allá del marco de trabajo donde discutiremos las aplicaciones de escritorio y su desarrollo. Nos enfocaremos en lo que hace que una aplicación de escritorio sea única, cómo elegir un marco de trabajo y cómo estructurar tu código. La web y las aplicaciones están entrelazadas, con una historia que se remonta a la década de 1940. Al elegir una tecnología, considera las características principales y la compatibilidad con marcos de trabajo existentes como React y Svelte. Construir una aplicación es más complicado que una aplicación de `Hola, mundo`, y los problemas comunes en el desarrollo de aplicaciones incluyen comprender los hilos principales y de renderizado, sincronizar el estado de la aplicación entre ventanas y la separación de responsabilidades. Tauri es una biblioteca de Rust que te permite construir tu propia aplicación de escritorio y tiene como objetivo hacer que la construcción de aplicaciones Tauri sea accesible sin necesidad de aprender Rust. El modelo de hilo principal y de renderizado es importante en el desarrollo de aplicaciones y permite el multihilo en los navegadores web. El estado es propiedad del hilo principal y se sincroniza entre todos los hilos de renderizado. El concepto de una interfaz de usuario con sensación nativa es subjetivo y varía según los sistemas operativos. Empaquetar y distribuir son esenciales para las aplicaciones de escritorio, lo que implica construir, empaquetar, firmar el código y distribuirlo. El objetivo es hacer que la construcción de aplicaciones de escritorio sea tan fácil como implementar un sitio web, y el grupo de trabajo de Tauri se enfoca en mejorar el proceso de construcción, la experiencia del usuario y la distribución de aplicaciones de escritorio.`, `seotitle`: null, `seodescription`: nul

Available in English

1. Introducción al Masterclass Más Allá del Marco

Short description:

Bienvenidos al masterclass Más Allá del Marco donde discutiremos las aplicaciones de escritorio y su desarrollo. Nos enfocaremos en lo que hace que una aplicación de escritorio sea única, cómo elegir un marco de trabajo y cómo estructurar tu código. Soy miembro del Grupo de Trabajo Towery y DevRel en Kript Nebula. Towery es un marco de trabajo para construir aplicaciones de escritorio utilizando tecnología web, y Kript Nebula es una empresa que ayuda a llevar las aplicaciones de escritorio al siguiente nivel. También mantengo bibliotecas y herramientas de código abierto en el ecosistema Vite y en los crates de Rust.

Bienvenidos. Mi masterclass se llama Más Allá del Marco, donde hablaremos sobre las aplicaciones de escritorio, pero no nos enfocaremos en un marco de trabajo específico. Vamos a ir más allá del marco de trabajo. Nos enfocaremos en lo que hace que una aplicación de escritorio sea una aplicación de escritorio, cómo construir una y en qué enfocarnos y no quedarnos atrapados en los detalles. Porque al final del día, un marco de trabajo es solo una herramienta.

Entonces, esta será la agenda para este masterclass. Bueno, primero les contaré un poco sobre la historia de las aplicaciones y la historia de la web, porque siento que eso es algo que se pasa por alto. Luego hablaremos un poco sobre cómo elegir un marco de trabajo, qué cosas tener en cuenta y algunas categorías que hemos encontrado útiles al elegir un marco de trabajo. Por último, hablaremos sobre cómo pensar en las aplicaciones, cómo estructurar tu código, cómo trabajar con aplicaciones de escritorio y algunas cosas que son diferentes a tu desarrollo tradicional de sitios web, tal vez, y cosas a tener en cuenta.

¿Quién soy yo? ¿Quién es el tipo que les está hablando? Soy miembro del Grupo de Trabajo Towery, pero también soy DevRel en Kript Nebula. Y para explicarlo un poco más, Towery, si no estás familiarizado, es un marco de trabajo para construir aplicaciones de escritorio utilizando tecnología web. Y nos enfocamos mucho en binarios pequeños, en aplicaciones seguras y en lo que me gusta llamar elección, porque Towery es un marco de trabajo completo. Eso tendrá más sentido más adelante cuando pasemos a los ejercicios. Y sí, pero también soy devrel en Kript Nebula. Kript Nebula es una empresa, como empresa, que fundamos para llevar las cosas más lejos y ayudarte, potencialmente, a ti y a las empresas a llevar sus aplicaciones de escritorio al siguiente nivel. Y hacemos consultoría, auditoría y también estamos trabajando en herramientas para mejorar la experiencia de las aplicaciones de escritorio utilizando tecnología web. También mantengo un par de bibliotecas y herramientas de código abierto y crates en el ecosistema Vite, por ejemplo, y luego crates de Rust. Porque empecé con JavaScript, lo hice durante mucho tiempo, pero ahora, desde hace aproximadamente un año, empecé con Rust y realmente me gusta. Y si miras en Twitter, eso ha surgido una y otra vez, personas del JavaScript interesadas en Rust. Si eres una de ellas y quieres hablar conmigo sobre los problemas que enfrentas, o no estás seguro de cómo empezar, definitivamente contáctame en Twitter o Mastodon. Los nombres de usuario están en la pantalla en este momento. Genial. Eso es todo sobre mí.

QnA

Preparación para Ejercicios y Preguntas y Respuestas

Short description:

Preparémonos para los ejercicios y veamos las aplicaciones que discutiremos. Las instrucciones y enlaces están disponibles en el sitio web y en el chat. Puedes elegir usar Tauri, Electron o PWA según tus preferencias de lenguaje. Si tienes alguna pregunta, no dudes en preguntar en cualquier momento.

A continuación, preparémonos para los ejercicios. Tenemos algunos ejercicios para que puedas jugar con algunas aplicaciones y ver por ti mismo las cosas de las que voy a hablar. Las instrucciones están en este sitio web, así que voy a poner el mismo enlace en el chat. No necesitas escanear el código QR si no quieres o escribir la URL tú mismo. Allí verás un enlace a... Habrá una tarjeta que dice masterclass, y luego habrá un enlace a los recursos, los cuales son un repositorio Git en GitHub. Puedes revisarlo. Asegúrate de tener los requisitos previos si quieres seguir usando el marco de trabajo Tauri, pero el enlace también debería estar en el repositorio. Todo está contenido en ese único repositorio. Tenemos una opción. Dependiendo del lenguaje que estés buscando, si quieres probar un poco de rust, tenemos Tauri. Si solo quieres quedarte en JavaScript, también puedes seguir usando Electron. Por último, también tenemos PWA como opción. Aplicación Web Progresiva. Creo que eso debería ser bueno para todos. Esas son ramas en ese repositorio. Puedes revisar la rama que desees. Las ramas están nombradas en consecuencia. Si solo estás aquí para leer y seguir, por supuesto también puedes hacerlo. Genial. Oh, eso es una cosa más para mencionar. Todos estamos aquí para pasar un buen rato. Si tienes alguna pregunta, no dudes en hacerla. Guárdalas para el final. No te olvides de ellas. Siéntete libre de hacer preguntas en cualquier momento en el chat y me aseguraré de responderlas si puedo.

La Interconexión de la Web y las Aplicaciones

Short description:

La web y las aplicaciones están entrelazadas, con una historia que se remonta a la década de 1940. Desde el Memex de Vannevar Bush hasta el sistema en línea de Douglas Engelbart y el sistema operativo GUI de Xerox PARC, el concepto de hipertexto y documentos interconectados influyó en el desarrollo de la web. La progresión de las aplicaciones a los sitios web comenzó con la invención de la World Wide Web por Tim Berners-Lee en 1989. La línea entre las aplicaciones nativas y las aplicaciones web se ha vuelto cada vez más borrosa, con proyectos como el uso de aplicaciones web en el iPhone de Apple y el proyecto Fugu de Google que difuminan aún más la línea. Al elegir una tecnología, considera las características principales y la compatibilidad con los marcos de trabajo existentes como React y Svelte.

Genial. Lección de historia. Excelente. Aprendiendo algo nuevo. La web y las aplicaciones, porque esto es algo que siento que a menudo se pasa por alto y algo que la gente realmente no conoce. Eso es muy interesante para mí porque a menudo escucho a la gente decir: oh, construyes una aplicación utilizando tecnología web, pero eso no es nativo. Eso no es una aplicación real. Eso no es adecuado. E investigué un poco más y la web y las aplicaciones están muy entrelazadas.

Así que comenzando en 1945, el trabajo académico que condujo a las computadoras que eran utilizadas por lo que entonces se llamaba trabajadores del conocimiento, lo que ahora llamaríamos personas comunes que usan computadoras, Vannevar Bush, no sé si estoy pronunciando eso correctamente, pero él ideó un sistema llamado Memex, que tenía como objetivo mejorar la mente humana utilizando computadoras. Y esto fue muy teórico. Y luego, simplemente porque en los años 40, la tecnología informática realmente, realmente no estaba advanced lo suficiente como para poner en práctica sus ideas.

Pero en la década de 1960, Douglas Engelbart, tal vez hayas escuchado el nombre, también uno de los pioneros de la tecnología informática. Trabajó en el sistema en línea, que estuvo muy influenciado por lo que propuso Vannevar Bush, y algo que luego influiría en gran medida en el hipertexto. También estaban hablando de enlaces y documentos interconectados, y cosas así eso. Y de esta investigación en la década de 1960, muchas de las personas que trabajaron en ese proyecto con Douglas Engelbart, luego fueron a trabajar en Xerox PARC, donde estaban trabajando en una de las primeras computadoras personales con un sistema operativo GUI.

Y nuevamente, gran parte de la inspiration en el fondo de sus mentes provenía de estos documentos interconectados de trabajadores del conocimiento, argumentando la mente humana. Y esto, ya sabes, para darte un poco de perspectiva, esto fue muy temprano en tiempo, ya sabes, puedes ver aquí, de 1970 a 1980. Gran parte de esto todavía estaba atrapado, ya sabes, en la investigación y en los círculos académicos, pero luego, ya sabes, en 1985, se lanzó Windows 1.0. Entonces, ya sabes, si quieres, en el mundo de las computadoras, la adopción generalizada de sistemas operativos gráficos.

Y luego, en 1987, esto es algo que se habla a menudo, un concepto muy importante o un producto muy importante, no se usa mucho, pero como influencia, el Apple Hypercard fue uno de los primeros, que conozco y pude encontrar, sistemas en los que los usuarios podían programar su propia computadora de una manera gráfica. Y tener esta interfaz programable muy fácil de usar en sus computadoras, usando tarjetas y pilas de tarjetas, una metáfora muy física, pero nuevamente muy influenciada el trabajo, ya sabes, el trabajo teórico sobre hipertexto y sobre, ya sabes, mejorar la mente humana. Pero de ninguna manera relacionado con nada que consideremos la web.

Entonces, esto era como construir aplicaciones pequeñas en tu computadora. Entonces, ya sabes, la aplicación original de bajo código, sin código, si quieres. Y luego, en 1989, aquí es donde finalmente comenzamos a ganar impulso en la web. Tim Berners-Lee inventa la World Wide Web. Y, nuevamente, no es el mismo grupo de personas, pero nuevamente influenciado por, ya sabes, el hipertexto y los documentos interconectados y toda esta noción de llevar una computadora para mejorar la mente humana. Y ahora estamos avanzando hacia el territorio de las páginas web, ¿verdad? Hasta este punto, todo eran aplicaciones y lo que considerarías nativo. Y ahora de repente tenemos sitios web. Por supuesto, al principio muy básicos. Y luego, en 1993, se lanzó Mosaic. Y con esa progresión comenzó lo que, bueno, en realidad, todos los navegadores modernos que tenemos hasta el día de hoy. Y esto, solo, ya sabes, un breve extracto porque no quiero aburrirte. Solo demuestra que desde el principio de la web y las aplicaciones, esto ha estado muy entrelazado. Entonces, la noción de hipertexto e hipervínculos y documentos interconectados ha estado con las computadoras, no solo con la web, sino con las computadoras desde el principio. Muy influenciado por todos los sistemas de interfaz de usuario y GUI que han surgido de la ciencia de la computación en ese momento tan temprano, están muy influenciados por el hipertexto, lo cual es increíble si lo piensas, porque la World Wide Web como concepto, la web en la que trabajamos hasta el día de hoy, llegó mucho después que eso. Siento que esta historia tiene un arco muy agradable, porque si saltamos al día moderno ahora, el anuncio, la historia reciente de Apple de que el iPhone no ejecutaría aplicaciones nativas, sino que ejecutaría web apps. Increíble si lo piensas, pero solo demuestra que la línea, y si estás en Twitter o Reddit o Hacker News, la línea que a las personas les gusta trazar en la arena, que dice, esta aplicación es nativa y esta aplicación no es nativa, esa línea es muy borrosa. Si existe en absoluto. Y esta línea se vuelve aún más borrosa a medida que pasa el tiempo, porque es posible que no hayas escuchado el nombre, pero Google en 2019 anunció lo que llamaron Project Fugu, que es simplemente un esfuerzo de seguimiento para muchas de las API web que hemos obtenido recientemente. Cosas como medios web o interfaz con dispositivos USB, cosas así. Todas estas API realmente difuminan la línea nuevamente entre lo que un sitio web puede hacer y lo que una aplicación puede hacer, el proyecto realmente comenzó a difuminar la línea nuevamente. Si en los primeros años 2000, teníamos una separación muy clara entre lo que son los sitios web y lo que son las aplicaciones nativas, ahora, nuevamente, al igual que en los primeros días, esta línea se está difuminando mucho en este momento. Entonces hay muchas tecnologías para hacer esto, ¿verdad? Y una pregunta que siempre nos hacen es que hay muchas opciones, ¿verdad? ¿Qué hago? ¿Cómo elijo una? Y tengo algunas. Tengo algunas opciones selectas. Hay muchas, muchas más opciones por ahí. Y lo que siempre digo a las personas y lo que siempre les decimos a las personas es que hay algunas categorías en las que debes fijarte. Y la mayoría de estas categorías, si eres un desarrollador web, te sonarán familiares, ¿verdad? Porque al final del día, muchas de las categorías por las que eliges el marco de trabajo de front-end web son muy similares a lo que elegirías un marco de trabajo de aplicaciones de escritorio. Por ejemplo, la primera categoría que siempre les digo a las personas son las características principales, ¿verdad? Como ¿cuáles son las características del marco de trabajo? ¿Qué tipo de soporte tiene? Y eso, por ejemplo, incluye cosas como, hey, tengo mucha experiencia en

Consideraciones sobre los marcos de trabajo y descripción del código

Short description:

Al elegir un marco de trabajo, considera su compatibilidad con tu marco de trabajo de front-end y las API web. La experiencia del desarrollador debe ser tan fácil como desarrollar sitios web, incluyendo el desarrollo local y el soporte de bibliotecas. El empaquetado y la distribución son cruciales para las aplicaciones de escritorio. Los recursos de aprendizaje y las integraciones del sistema operativo también son factores importantes a considerar.

este marco de trabajo de front-end o mi equipo usa React, mi equipo usa Svelte. ¿Este marco de trabajo que estoy a punto de elegir, admite mi marco de trabajo de front-end o qué soporte tiene para las API web, ¿verdad? Mi aplicación, por ejemplo, utiliza notificaciones, ¿está eso admitido? ¿Puedo usarlo? Cosas así, ¿verdad? Esa es una categoría muy, muy básica. La siguiente, y pongo esto al principio de esta lista, porque siento que es mucho más importante de lo que la gente le da crédito, es la experiencia del desarrollador, ¿verdad? Porque todos sabemos que el desarrollo web hoy en día es muy fácil. Y todos nos hemos acostumbrado a que el desarrollo web sea muy fácil, ¿verdad? Puedo iniciar un servidor V, se inicia muy rápido. Oh, disculpen. Lo siento. Puedes configurar un servidor de desarrollo local, se inicia muy rápido, muy agradable de usar. Tenemos un gran ecosistema de, ya sabes, bibliotecas en npm y demás. Entonces, idealmente, el marco de trabajo de escritorio que elijas debería reflejar eso, ¿verdad? El marco de trabajo de escritorio, toda la experiencia debería ser tan fácil como trabajar con un sitio web normal. Por supuesto, eso no siempre es necesariamente el caso, porque estás agregando una capa de complejidad con un marco de trabajo de aplicaciones de escritorio. Pero idealmente, ya sabes, la experiencia del desarrollador debería ser tan fácil como desarrollar sitios web. Y eso incluye, ya sabes, como mencioné, el desarrollo local, ¿qué tan rápido se inicia? ¿Se siente bien en mi máquina? ¿Se integra con todas las herramientas que ya se usan, pero también la grabación debería estar habilitada? Espero. Genial. Lo siento. Interrumpido. Pero luego, como mencioné con NPM, ¿admite mis bibliotecas? Ya sabes, ningún sitio web, ninguna aplicación se desarrolla completamente desde cero. Entonces, ¿se admite mi biblioteca? ¿Puedo incorporarla fácilmente? ¿Es una buena experiencia? Y luego, por último, lo que diferencia mucho a las aplicaciones de escritorio de los sitios web, ya sabes, es el empaquetado y la distribución, ¿verdad? Porque con los sitios web, lo que haces es encontrar un servidor web, un host web. A menudo en la actualidad, ¿verdad?, puedes conectar tu repositorio de Github al servicio y se implementará para ti. Pero con las aplicaciones de escritorio, necesitas pasar por ese paso de empaquetar tu aplicación, agruparla, ponerla en la tienda de aplicaciones. Firmar el código, y eso, ya sabes, lo veremos con más detalle, pero todo eso es parte de la experiencia del desarrollador, y para mí eso es muy importante. Del mismo modo, los recursos de aprendizaje son muy importantes, ¿verdad? Lo más probable es que no hayas nacido como un experto en ninguno de estos marcos de trabajo, ¿verdad? Entonces, ¿cuál es la forma de aprenderlo? Ya sabes, ¿hay buena documentación, hay muchos videos en YouTube u otras plataformas para aprender esto si eres una persona más visual. ¿Hay publicaciones de blog? Ya sabes, ¿hay una forma de poder aprenderlo? Y luego la pregunta es, ¿hay un foro donde puedas hacer preguntas? O incluso formación formal de alguna manera, ¿verdad? Y luego, algo que también siento como hablante no nativo de inglés que a menudo se pasa por alto es, ¿todos estos recursos también están disponibles en mi idioma? Ya sabes, ¿es algo que puedo aprender muy fácilmente? Especialmente si soy y no quiero lidiar con la sobrecarga de tener que interpretarlo en inglés. Los recursos de aprendizaje son muy importantes como categoría. Y por último, esto es muy específico de las aplicaciones de escritorio, es probable que estés construyendo aplicaciones de escritorio porque quieres ir más allá de lo que la web puede ofrecer, ¿verdad? Quieres tener una integración más estrecha con el sistema operativo. Quieres tener acceso a los recursos completos que la computadora te ofrece sin pasar por la indirección del sandbox que construye el navegador. Y luego se vuelve muy importante mirar, ¿qué integraciones del sistema operativo necesito? ¿Las admite mi marco de trabajo? Cosas como crear ventanas, muy básico. La mayoría de ellos pueden hacer eso. Pero también cosas más complicadas como notificaciones o un sistema de archivos. Y también, por supuesto, qué sistemas operativos son compatibles. ¿Cuál es el soporte en Linux, por ejemplo? Porque, por mucho que me encante Linux, casi cada distribución cuenta como su propio mini sistema operativo. Entonces, ¿cuál es el soporte del sistema operativo, ya sabes? ¿Se admite el sistema operativo que necesito, el que me importa, o el que les importa a mis usuarios, ¿verdad? Esas son las cuatro categorías que hemos identificado como muy, muy importantes al considerar qué marco de trabajo elegir, qué buscar, y hay, por supuesto, ya sabes, más y luego se vuelve más sutil, pero como una introducción rápida, esas son las más importantes a tener en cuenta. Y con eso, la parte aburrida ha terminado por ahora, vamos a pasar al código. ¿De acuerdo? Entonces, la forma en que funciona y déjame salir, sí, así que, espero que puedas ver esto. Lo que tengo en funcionamiento ahora son tres aplicaciones que dicen, ¡Hola JS Nation! Y esas son las tres aplicaciones, ya sabes, las tres formas en que puedes, bueno, no las únicas tres formas, por supuesto, pero ya sabes, los tres tipos de ejemplos que incluí, las tres tecnologías. Y te daré una descripción rápida de cada una de estas aplicaciones de Hola Mundo, para mostrarte y también hablar sobre, ya sabes, qué es diferente, qué es lo mismo, para darte una idea porque la mayoría de ellas, muy diferentes. Spoiler alert, estas son muy, muy, muy similares. ¿Dije diferentes? Entonces me equivoqué al hablar. En mi cabeza, pensé que dije diferentes, pero no es lo que quiero decir. Son muy similares. Genial. Entonces, déjame abrir mi VSCode. Oh no, antes de hacer eso. Voy a abrir el sitio web. Entonces, si haces clic en el enlace que está en el chat, esto te llevará a este sitio web y también puedes ganar un Xwing. Esto es también para la conferencia JS Nation adecuada. Pero si, ya sabes, quieres adelantarte, siéntete libre. Pero lo que estamos buscando es esta especie de cuadro y haz clic en los activos del taller. Esto te llevará a este repositorio aquí. Y nuevamente, como dije, tres ramas,

Explorando el Hola Mundo de PWA

Short description:

Comenzaremos con el Hola Mundo de PWA, que es la aplicación web progresiva más simple. Las aplicaciones web progresivas son sitios web que el navegador te permite instalar. Consisten en un archivo HTML y un archivo manifest.json que describe la aplicación. El archivo index.html principal contiene el código HTML y se requiere un service worker para que la aplicación esté disponible sin conexión. El script del service worker se encarga de almacenar en caché los recursos y habilitar la sincronización en segundo plano. La etiqueta de script se utiliza para cargar el service worker, que se registra para garantizar su funcionalidad. El service worker en sí es simple y almacena en caché los recursos web en la primera carga. Se espera que las aplicaciones de escritorio funcionen sin conexión, brindando una experiencia fluida para los usuarios independientemente de su conexión a Internet.

tarry, electron, PWA. Y los revisaremos uno por uno, comenzando con PWA. Así que si quieres seguir, clona el repositorio e instala las dependencias. Necesitarás Node.js para esto. Espero que lo tengas instalado. Si no, también podemos enviar un enlace en el chat o buscar en Google Node.js.

Um, permíteme abrir VS Code. Bien, genial. Aquí estamos. Entonces, la forma en que tengo estructurado este repositorio es que tenemos esta carpeta con puntos de control. Y cada punto de control representa un momento específico de nuestra aplicación. ¿De acuerdo? Entonces, a medida que avanzamos en esta masterclass, te diré, um, bien. Te diré en qué punto estamos, punto de control uno, punto de control dos, punto de control tres. Y puedes saltar adelante si quieres. Y más tarde, si quieres retroceder, puedes viajar en el tiempo. Y puedes usar estos puntos de control como puntos de partida para tu propia exploración y tu propio. Eso será importante más adelante. Entonces, genial. Comencemos con el Hola Mundo de PWA. ¿De acuerdo? Y porque realmente es el más simple. Y eso se debe a que las aplicaciones web progresivas son simplemente sitios web, ¿verdad? Sitios web que el navegador te permite instalar. Y como cualquier sitio web, es un archivo HTML. No del todo. También hay un archivo manifest.json. Y este archivo manifest.json describe tu aplicación. Puedes darle un nombre, un nombre corto y establecer algunas otras cosas que luego se reflejarán en esta aplicación. Por ejemplo, aquí establecí un color de tema y se tomó como el color de la barra de título. Pero lo que realmente nos importa es este archivo index.html principal. Y puedes ver, muy simple. Tenemos una hoja de estilo incluida al principio para que todo se vea bien. Por supuesto, también podrías tener esto como un archivo separado. Elegí incluirlo para tener un archivo html independiente y ordenado. Y luego solo tenemos nuestro html. Hola, JS Nation, ¿verdad? Lo único que necesitarás para que una aplicación web progresiva funcione es lo que se llama un service worker. Si no estás familiarizado con eso, un service worker es una especie de script JavaScript independiente que se ejecutará en segundo plano de tu navegador. Y eso es responsable de asegurarse de que tu aplicación esté disponible sin conexión, ¿verdad? También puede hacer algunas otras cosas, pero este service worker es lo que impulsa tu aplicación en segundo plano. Y puede hacer mucho más que simplemente almacenar en caché tus recursos y hacerlos disponibles sin conexión. También puede realizar sincronizaciones en segundo plano. Por ejemplo, puedes configurarlo para que cada dos horas busque nuevos datos de un servidor o algo así. Y esta etiqueta de script que ves aquí, todo este código es necesario para cargar el service worker. Lo leeremos desde un archivo y luego lo registraremos. Y eso se encarga de eso. El service worker en sí también es muy simple. No lo modificaremos en absoluto. No volveremos a tocar esto. Y esto simplemente almacenará en caché todos nuestros recursos web en la primera carga si aún no están en caché. Y una de las cosas que lo diferencia de un sitio web tradicional es que las aplicaciones de escritorio suelen funcionar sin conexión. Entonces, lo que un usuario espera de una aplicación de escritorio es que simplemente pueda abrir la aplicación. Si estoy en algún lugar de Alemania rural, donde la señal de celular y el internet móvil no son muy buenos, espero que mi aplicación se inicie

Ejecutando la Aplicación y Distribuyendo Apps de Electron

Short description:

Un service worker es esencial para ejecutar la aplicación. Para ejecutarlo, se incluye un servidor HTTP como una dependencia de desarrollo. Este punto de control se puede ejecutar utilizando el comando PNPM. Las PWAs se pueden instalar como aplicaciones y funcionan sin conexión. En Electron, el hilo principal controla la aplicación y puede crear una ventana con HTML. La función 'create window' crea una nueva ventana del navegador y carga el archivo index.html. Las aplicaciones de Electron se pueden empaquetar y distribuir como binarios independientes.

tan rápido y funcionen tan bien como cuando estoy en casa. Por lo tanto, un service worker es muy esencial para eso. Pero eso es todo. Lo que puedes hacer para ejecutar esto tú mismo es que incluí como dependencia de desarrollo un servidor HTTP y puedes ejecutarlo utilizando el comando que está aquí en el archivo readme. Siendo este el punto de control uno, lo ejecutamos usando este comando PNPM. Personalmente, prefiero PNPM como gestor de paquetes. Este repositorio también funciona con NPM y con Yarn. Cualquiera que sea tu preferencia en el departamento de gestor de paquetes, también debería funcionar. Simplemente haz clic en 'Start' y luego abre este enlace y esto se abrirá como cualquier otro sitio web con la diferencia importante de que... Ok, espera. Permíteme desinstalar esto de nuevo. Desinstalar. Sí. Oh, de nuevo. Entonces, una PWA es simplemente un sitio web, ¿verdad? Como cualquier otro sitio web con la diferencia importante de que el service worker y la web, como este archivo manifest.json que hemos configurado, hacen que aquí en Chrome, por ejemplo, me solicite o me permita instalar este sitio web como una aplicación. Y esto es realmente genial porque los usuarios que descubran tu cosa a través de la web, verán esto y notarán, `Oh, sabes, también está disponible como una versión de aplicación`. Y luego simplemente pueden hacer clic en instalar y boom, ahora es una aplicación que funciona sin conexión. Por supuesto, la parte sin conexión no puedo demostrártela en este momento porque entonces no me estarías viendo. Pero esto, ya sabes, ahora está disponible sin conexión y funciona como una aplicación independiente.

Pasemos al ejemplo de Electron porque el ejemplo de Electron también es muy similar. Entonces, si estás siguiendo con Electron, navega hasta los puntos de control, y luego la primera carpeta y verás, nuevamente, tenemos un archivo index.html. Y este es aún más simple. Es solo la hoja de estilo y, ya sabes, el html que dice, hola, JS Nation. Y Electron tiene algo muy similar a un service worker, que en el mundo de Electron se llama el hilo principal. Y a diferencia del service worker en el mundo web, donde el service worker es opcional, ¿verdad? Puedes optar por usar el service worker. La forma en que esto funciona es que tu sitio web se cargará primero. Tu sitio web iniciará el service worker. Y luego las cosas funcionarán sin conexión. En el mundo de Electron, esto es exactamente lo contrario, ¿verdad? Entonces tienes el hilo principal que se inicia primero, y el hilo principal realmente está en control de tu aplicación, ¿verdad? El hilo principal, esa es tu aplicación, y el hilo principal puede crear una ventana con tu HTML dentro de ella. Así que es de alguna manera al revés. Y este hilo principal está ejecutando este archivo main.JavaScript, archivo main.js. Y como puedes ver, lo que hace este archivo es que esperamos hasta que la aplicación esté lista, ¿verdad? Permíteme aumentar el tamaño de fuente para que puedas leerlo. ¿Está bien así? Espero que sí. Si no, avísame. Entonces lo que hacemos es esperar hasta que la aplicación esté lista. Y luego creamos una ventana usando esta función aquí. Y este es un código específico de macOS que básicamente replica este comportamiento en macOS donde, una vez que cierras una ventana, la aplicación no se cierra inmediatamente como en Windows, sino que permanece abierta. Y luego, una vez que haces clic en el icono nuevamente, se volverá a abrir una ventana. Estas líneas aquí son muy específicas de macOS. Solo para que lo sepas, la parte sustancial de este archivo es la función 'create window'. Y esto creará una nueva ventana del navegador, con un ancho y alto predefinidos. Y luego le indicamos a la ventana principal que cargue nuestro archivo index.html. Así que como dije, esto funciona de manera un poco diferente, donde nuestro hilo principal carga el html y no el html carga el service worker, el hilo principal, por así decirlo. Y sí, si puedes, nuevamente, ejecútalo usando el comando 'Start', así que permíteme abrir este terminal un poco más. Si ejecutas 'Start' en esta carpeta o utilizando esta sintaxis de filtro, oh, se abrió en el monitor equivocado, pero aquí estamos. Se abrió una aplicación nativa, nuevamente, que dice, hola, JS Nation. Y esta aplicación, a diferencia de, y esta es una diferencia, esto es una diferencia con lo que hemos visto anteriormente. Esta aplicación, luego podrías empaquetarla y distribuirla como cualquier otra aplicación. El problema con las PWAs, o no es un problema, es una diferencia. La diferencia con las PWAs es que siempre debes descubrirlas a través de tu navegador, mientras que con Electron, puedes distribuirlas como binarios independientes que funcionan independientemente de cualquier navegador o algo así. Cerramos esto.

Desarrollo de Aplicaciones con Tauri

Short description:

Si estás siguiendo con Tauri, notarás que la estructura es algo diferente. Tauri es una caja de herramientas de Rust que te permite construir tu propia aplicación de escritorio, dándote control sobre el binario de Rust. Los binarios de Tauri son más pequeños y seguros, ya que los archivos JavaScript se incluyen en la aplicación en tiempo de compilación. El archivo main.js es equivalente al archivo main.js de Electron, creando el hilo principal y ejecutando la aplicación. El archivo tauri.conf.json es similar a manifest.json en las PWAs, pero con más opciones para aplicaciones de escritorio. El grupo de trabajo de Tauri tiene como objetivo hacer que la construcción de aplicaciones de Tauri sea accesible sin necesidad de aprender Rust.

Si vuelvo a abrir esto, como pudiste ver, si cierro esta ventana, la aplicación no desaparece, sino que se queda en segundo plano. Eso es exactamente lo que hizo este código. Cerrémoslo de una vez por todas y pasemos a la versión de Tauri. Aquí estamos, la versión de Tauri. ¿Tengo cambios sin confirmar? Oh, está bien, está bien. Solo cambié el nombre de la aplicación. Lo siento. No hay problema. Si estás siguiendo con Tauri, navega hasta la primera carpeta y notarás que esto se ve algo diferente, ¿verdad? Aquí está mi archivo HTML. Y el archivo HTML está en la carpeta source. Entonces, nuevamente, hoja de estilos HTML, ya conocemos esto, ¿verdad? Es lo mismo. Entonces, una cosa que ya aprendimos, todos estos utilizan básicamente la misma capa web, ¿verdad? No hay diferencia en la capa web como esperábamos, ¿verdad? Porque se trata de construir aplicaciones utilizando tecnología web. La parte de tecnología web de esto no cambia. Es muy similar, ya sabes, lo mismo. Pero, la diferencia con las aplicaciones de Tauri es la carpeta Tauri de origen. Y aquí es donde necesito explicar un poco, porque no asumo que estés familiarizado con Tauri en absoluto. La forma en que funciona Tauri, a diferencia de Electron, donde Electron se distribuye como un solo binario, ¿verdad? Ese es el binario de Electron y le dices al binario de Electron que ejecute tu JavaScript. Muy similar a cómo le dices a Node.js que ejecute tu JavaScript, ¿verdad? Pero la forma en que funciona Tauri es que Tauri es solo una caja de herramientas de Rust. Y es una caja de herramientas de Rust que puedes incluir en tu proyecto de Rust y luego construir tu propia aplicación de escritorio con eso, ¿verdad? Puedes decirle a la aplicación de escritorio que cargue el archivo, puedes hacer lo que quieras. Pero lo importante es que aún tienes el control del binario de Rust, ¿verdad? Dado que el binario de Rust se compila en tu máquina, realmente puedes elegir qué partes del framework necesitas, qué partes necesitas y luego también puedes agregar partes opcionales para ampliar la funcionalidad. Y todo eso sucede en tiempo de compilación. Entonces realmente solo obtienes lo que necesitas, porque está compilado, ¿verdad? No es solo un binario estático, sino que está compilado en un binario. Y eso te brinda algunas ventajas, y eso es en parte por qué comenzamos el proyecto en primer lugar. Las ventajas son que, dado que solo obtienes lo que realmente necesitas, los binarios de Tauri son mucho, mucho, mucho más pequeños y también más seguros, porque no leemos ningún archivo JavaScript del disco ni nada por el estilo. Los archivos JavaScript se incluyen en tu aplicación en tiempo de compilación. Eso es lo que podemos hacer, ya que es algo compilado. Lo que acabo de abrir, el archivo main.js, es básicamente nuestro equivalente del archivo main.js. Entonces, en Electron, tenías el archivo main.js, que creaba tu hilo principal y luego abría una nueva ventana, cargaba tu HTML y hacía todo eso. Y esto es esencialmente lo mismo. Puedes ver que tenemos una función principal aquí porque Rust necesita eso para ejecutarse. Y lo primero que hacemos es crear nuestra aplicación de Tauri. Y luego, en esta línea, ejecutamos nuestra aplicación. Eso es todo.

Otro archivo muy importante en un proyecto de Tauri es el archivo tauri.conf.json. Y esto, nuevamente, es muy similar a lo que vimos con las PWAs, ¿verdad? Donde teníamos el archivo manifest.json, donde describíamos nuestra aplicación, donde establecíamos un nombre y algunas otras cosas. Y el archivo tauri.conf.json realmente es lo mismo. Solo que con más opciones y orientado a Tauri, ¿verdad? Aquí, nuevamente, podemos dar un nombre especial a nuestra aplicación, podemos establecer la versión de la misma. Y podemos establecer muchas más opciones. Y esto va en contra del punto que estaba haciendo, donde probablemente estás buscando un framework de aplicaciones de escritorio porque quieres ir más allá de lo que el navegador puede ofrecerte, ¿verdad? Entonces esto es muy similar a tu archivo manifest.json de las PWAs, pero va más allá de lo que el navegador puede ofrecerte. Y este archivo se leerá en tiempo de compilación y Tauri tomará, ya sabes, las decisiones correctas para ti en el binario final en función de las opciones que establezcas aquí. Entonces, eso es algo en lo que el grupo de trabajo de Tauri ha invertido mucho tiempo. Hemos visto que aprender Rust es un desafío. Aprender Rust no es fácil. Y, ya sabes, si tienes una gran idea para una aplicación, probablemente quieras terminarla y sacarla lo más rápido posible. No tienes tiempo para aprender Rust, ya sabes. Entonces tratamos de asegurarnos, y creo que lo logramos muy bien ahora, de que no necesites ningún Rust.

Configuración de Aplicaciones y Enfoque en Electron

Short description:

Puedes configurar tu aplicación utilizando un archivo JSON y luego usar JavaScript para todo lo demás. Las aplicaciones de Tauri producen un solo binario que se puede distribuir de forma independiente. ¿Algún pregunta hasta ahora? ¿Estás listo para continuar? Me enfocaré en la variante de electron para los ejercicios.

para construir aplicaciones de Tauri. Esto fue algo así como uno de los puntos principales que teníamos en mente, que deberías poder configurar tu aplicación utilizando este archivo JSON y luego hacer cualquier otra cosa utilizando JavaScript si no quieres tocar ningún Rust. Y eso es algo, siento que es muy importante.

Entonces sí, con eso, podemos comenzar a usar pnpm, podemos iniciar nuestra aplicación de Tauri y lo que acaba de hacer es compilar nuestra aplicación y ahora la ejecutó. ¡Y ta-da boom! Tenemos nuestra aplicación y está en ejecución. Y nuevamente, similar a electron, pero diferente a las PWAs, así que diferencias y similitudes, ¿verdad? Una aplicación de Tauri producirá un solo binario al final que puedes distribuir de forma independiente sin necesidad de navegadores ni nada parecido.

Entonces, cerremos esto y volvamos a nuestras diapositivas. ¡Genial! ¿Algún pregunta hasta ahora? ¿Tuviste problemas con los ejemplos de Hola Mundo? ¿Algo no se inició, no se compiló? ¿O estamos bien? ¿Te sientes listo para continuar? Tal vez podemos obtener un poco de retroalimentación en el chat, para que no te sientas rezagado. Vale, silencio en el chat, todo bien. Muy bien. Genial. Así que me enfocaré principalmente en la variante de electron de esto, ¿verdad? También mostraré un poco de Tauri. Pero como asumí que estás más familiarizado con la variante de electron, es más fácil de entender. La usaré para mostrar los ejercicios y trabajar en ellos.

Problemas Comunes en el Desarrollo de Aplicaciones

Short description:

Construir una aplicación es más complicado que una aplicación de hola mundo. Esta sección se enfoca en problemas comunes y te enseña cómo pensar en las aplicaciones teniendo en cuenta las diferencias en el desarrollo web. Puedes aplicar tus habilidades existentes al desarrollo de aplicaciones de escritorio.

en ellos. Creo que tiene sentido. Genial. Ahora tenemos una aplicación de hola mundo en funcionamiento. Pero ¿y ahora qué? ¿Verdad? Esto es algo que veo mucho y que sentí mucho cuando comencé mi camino. Es que muchas de las frameworks y gran parte de la documentación y muchos tutoriales siempre se centran en, `Oye, así es como te pones en marcha. Así es como comienzas. Así es como configuras. Así es como configuras tu aplicación. Esto es un hola mundo. Y luego sigues ese tutorial, ¿verdad? Sigues esa guía y ya está. Tienes un hola mundo en funcionamiento, pero luego el anfitrión siempre dice, `Genial. Ahora estás preparado para construir aplicaciones. Diviértete, sal y haz cosas`. Pero siempre me quedaba ahí y pensaba, sí, pero todavía no sé realmente cómo abordar esto, ¿verdad? Como construir una aplicación es mucho más complicado. Como construir una aplicación real es mucho más complicado que construir una aplicación de hola mundo. Entonces, ¿por dónde empiezo? ¿Qué hago? ¿Qué cosas debo tener en cuenta? ¿Cómo pienso en las aplicaciones? Y no se me ocurrió un nombre mejor para esto que problemas comunes, pero esta sección es, ya sabes, y esto es en lo que se enfocarán los ejercicios. Te enseñarán un poco sobre cómo pensar en las aplicaciones, ¿verdad? Cómo pensar en las aplicaciones de una manera en la que puedas ver dónde están las cosas, nuevamente, ya sabes, dónde las cosas son diferentes al desarrollo web a lo que estás acostumbrado o, ya sabes, son iguales al desarrollo web a lo que estás acostumbrado. Entonces puedes tomar tus habilidades existentes, tus conocimientos existentes y extrapolarlos al desarrollo de aplicaciones de escritorio.

Comprendiendo los Hilos Principal y de Renderizado

Short description:

El modelo de hilo principal y de renderizado es importante en el desarrollo de aplicaciones. Permite la ejecución en múltiples hilos en los navegadores web, mejorando la estabilidad y el rendimiento. En esta sección, exploraremos una aplicación de demostración que calcula números de Fibonacci y muestra las limitaciones de la ejecución de JavaScript de un solo hilo. La aplicación se congela durante el cálculo, lo que impide la interacción del usuario. Esto resalta la necesidad de procesamiento en segundo plano y algoritmos eficientes al manejar tareas computacionalmente intensivas.

Lo más importante, y siento que esto es como la base de cualquier desarrollo de aplicaciones, y se está volviendo cada vez más importante en la web también, ya sabes, como dije, los proveedores de navegadores están constantemente aumentando la borrosidad de la línea entre lo que es una aplicación nativa y lo que es un sitio web, pero lo principal en lo que debes pensar cuando trabajas en aplicaciones es el hilo principal y el hilo de renderizado, y eso es un modelo que fue introducido primero, creo que por Chrome, y eso es el multihilo en tu navegador web, ¿verdad?, y la idea es que tienes un hilo que controla tu aplicación, ese es el que inicia las ventanas, el que interactúa con el sistema operativo, y luego ese hilo principal genera una serie de hilos de renderizado y de utilidad para dibujar cosas en la pantalla, ¿verdad? Entonces, en Chromium o Chrome, un hilo de renderizado sería equivalente a una pestaña o una ventana, ¿verdad?, así que el contexto de cada sitio web se ejecutaría en su propio hilo de renderizado, ¿verdad? Y eso tiene la ventaja de aprovechar las máquinas multinúcleo que todos usamos ahora, pero también aumenta la estabilidad de tu aplicación, ¿verdad? Entonces, si, por ejemplo, en el caso de Chrome, un sitio web tiene un error, no afecta a todo el navegador, solo afecta a ese hilo, ¿verdad? Lo mismo ocurre con tu aplicación de escritorio. Si una ventana tiene un problema o experimenta problemas, si se bloquea, no afecta a toda la aplicación, solo afecta a esa ventana, y puedes recuperarte y seguir adelante y tal vez, ya sabes, manejar el error y luego mostrar un mensaje de error al usuario o algo así. Entonces, el modelo de hilos es importante por esa razón, pero también es importante por un par de razones más, y, ya sabes, ahora veremos por qué y aquí es donde volveremos a algunos ejercicios. Así que ahora estamos en el punto de control 2. Así que pasemos a eso.

Llama a este, llama a aquel. Y antes de sumergirnos en el código real, permíteme decirte qué hace la aplicación de demostración en la que estamos trabajando ahora mismo. Y teníamos una pequeña y bonita aplicación de hola mundo, pero en realidad no hace nada y no te enfrentas a ninguna limitación con eso porque solo estás mostrando un H1, ¿verdad? Así que pensé en algo muy simple que hiciera un poco más que solo hola mundo, pero que aún demostrara mi punto, ¿verdad? Y se me ocurrió, okay, hagamos una aplicación simple que simplemente calcule números de Fibonacci. ¿De acuerdo? Los números de Fibonacci, esa serie de números donde, ya sabes, cada número depende de los dos números anteriores. Y eso es interesante porque hay una forma de expresar esto usando recursión, que no es muy eficiente. Y ese es el punto, ¿verdad? Así que esta función aquí es la versión menos eficiente para implementar el algoritmo de Fibonacci. Y eso es para mostrarte un problema de rendimiento más adelante. Y ahora, si el hecho de que esta sea la versión menos eficiente de este algoritmo te molesta, si eso te motiva, si eso te inspira, si eso te despierta algo, si eso te hace querer refactorizar esto, hay algunas variantes más eficientes. Pero quería centrarme en esta aplicación como una demostración simple. Y lo que hace esta aplicación es que puedo ingresar un número y me dará los primeros n números de la secuencia de Fibonacci, dependiendo del número que ingresé. Así que 0, 1, 1, 2, 3, 5, 8. Puedo aumentar esto, puedo ir a 10, puedo ir a 25, y puedes ver que los números se vuelven realmente grandes muy rápido. Y si aumentas mucho este número, digamos 40, notarás algo interesante. Así que hice clic en 40, y ahora no puedo... Okay, lo tengo. Hagamos 50, ya sabes, hagamos 50, calcula... Y así, puedes ver que mientras se está calculando, ya no puedo interactuar con la página. Todavía puedo moverla, pero pasar el cursor sobre este botón no hace nada. El desplazamiento todavía funciona, porque no depende de ningún elemento HTML, pero no puedo hacer clic en este campo de entrada, no puedo cambiarlo. Esta aplicación, en todos los sentidos, está completamente congelada ahora mismo. No puedo hacer nada con esta aplicación en este momento. Y eso es porque este cálculo se realiza en un solo hilo, ¿verdad? Así que, esto es un término con el que probablemente estés familiarizado. Si no, déjame explicártelo rápidamente. JavaScript, de forma predeterminada, se ejecuta en un solo hilo, lo que significa que solo habrá una instrucción ejecutándose a la vez. Solo habrá una cosa sucediendo a la vez, aunque tu máquina, tu computadora, pueda ejecutar algo de código al mismo tiempo con los múltiples núcleos que tiene. Puede hacer varias cosas al mismo tiempo. Y lo peor es que con esta implementación que hemos elegido aquí, nunca volverá al hilo principal hasta que haya terminado. En realidad, ha terminado de calcular todos los 51 números de Fibonacci. Y eso es malo, porque en este mundo, donde solo tenemos un solo hilo para hacer cualquier cosa, este hilo también es responsable de calcular el color de fondo de este botón. Permitirme interactuar con este elemento de entrada, renderizar estos dos botones que tenía aquí anteriormente, donde podía incrementar y decrementar el número. Es responsable de hacer esto interactivo. Todo esto ahora está congelado porque en lugar de manejar cualquier entrada del usuario en este momento, lo que estamos haciendo es calcular números increíblemente grandes y lo estamos haciendo de manera muy ineficiente. No en segundo plano, sino en primer plano en lugar de manejar la entrada del usuario, estamos calculando números. Y eso está causando un problema. Y puedes ver que, aunque todavía puedo cambiar el tamaño, no puedo hacer nada más. Y aún sigue, ¿verdad? Esto todavía está sucediendo. Y sí, los números de Fibonacci y calcular eso pueden ser un ejemplo un poco forzado, un poco estúpido, podrías decir. Pero esto también podría ser, ya sabes, decodificar un video, o codificar un video, o hacer cualquier cosa que requiera un procesamiento pesado. Y sí, déjame cerrarlo para que se detenga de verdad.

Sincronización del Estado de la Aplicación entre Ventanas

Short description:

En la tercera versión de la aplicación, se agrega un botón de nueva ventana para simular la funcionalidad de abrir múltiples instancias de la aplicación. Sin embargo, el estado de la aplicación no se sincroniza entre ventanas, lo cual puede ser problemático en escenarios del mundo real. Esto enfatiza la importancia de considerar los hilos al desarrollar una aplicación.

Y de manera similar, ya sabes, si ahora navegamos al tercer punto de control, y también nos movemos al tercer punto de control, lo que esta, ya sabes, tercera versión de la aplicación agregó es un botón al final aquí. Así que aquí en el HTML, agregué un nuevo botón llamado botón de nueva ventana, y ese botón simplemente, ya sabes, inicia una nueva ventana que muestra el mismo contenido, ¿verdad?, como crear una segunda ventana de esta aplicación o una tercera o una cuarta. Y esto, ya sabes, se asemeja a lo que podrías encontrar en cualquier aplicación del mundo real, ¿verdad?, porque lo más probable es que tu aplicación no esté limitada a una sola ventana. Y si lo está, es posible que aún desees poder abrir múltiples instancias de ella, ya sabes, para tener una vista lado a lado o algo así. Y notaremos algo más. Y eso es, ya sabes, si calculamos los números de Fibonacci aquí y ahora abrimos una nueva ventana, esto ya no está sincronizado, ¿verdad? Ahora está desincronizado. Esto no refleja el estado de la aplicación en una ventana en esta ventana. Si hago, ya sabes, si calculo 10 aquí e incluso si, ya sabes, voy a ver y recargo, esto no está sincronizado. Esto no se lleva a las otras ventanas, lo cual es una lástima. Ya sabes, en este ejemplo, ya sabes, un poco artificial, lo siento, en este ejemplo artificial, esto puede parecer un poco inútil. Pero, digamos, ya sabes, nuevamente estás trabajando en una aplicación que es como una aplicación de estación de trabajo, ¿verdad?, entonces sería muy útil si tienes una ventana de configuración, ¿verdad?, y cambias algún estado en esa ventana de configuración, que luego se refleje en la ventana principal, ¿verdad? Esa es toda la idea de la configuración, así. Si vuelvo a las diapositivas, esto es como la segunda gran razón por la que realmente deberías pensar en los hilos, de manera consciente, cuando estás trabajando en la aplicación.

Separación de Responsabilidades y Refactorización

Short description:

Cada hilo en el sistema debe ser responsable de algo diferente. El hilo principal controla la aplicación, mientras que el hilo de renderizado se encarga de renderizar y recibir la entrada del usuario. El estado es propiedad del hilo principal y se sincroniza entre todos los hilos de renderizado. Piensa en los hilos de renderizado y principal como cliente-servidor, donde el servidor es dueño del estado y el cliente se encarga de renderizar y recibir la entrada. En el punto de control 3, refactorizaremos el código para evitar que la aplicación se congele en el hilo principal. Tómate un minuto para pensar cómo podemos aprovechar múltiples hilos. Demostraré la solución utilizando la versión de la aplicación de Tauri.

¿verdad? Y permíteme saltar esto. Y eso es como lo que, ya sabes, este término técnico llamado separación de responsabilidades entra en juego, ¿verdad? Y eso es, tengo todos estos tipos de hilos en mi sistema. Y cada hilo, ya sabes, debe ser responsable de algo diferente. Y, o debe ser responsable de su propia tarea. Y debería estar especializado en hacer lo que hace. Y si volvemos a este dibujo, ¿verdad?, tenemos el hilo principal. Y tenemos los hilos de renderizado. Y para cada hilo de renderizado, como podrías tener muchos, ¿verdad? Entonces cada hilo de renderizado es esencialmente uno muy liviano con el hilo principal, como sugiere el nombre, siendo el principal. Y realmente, ya sabes, quiero enfatizar esto y lo enfatizaremos aún más con, ya sabes, los ejercicios ahora. Pero el hilo principal, eso es, ya sabes, lo que controla tu aplicación, ¿verdad? Entonces el hilo de renderizado, como sugiere el nombre, se encarga de renderizar y recibir la entrada del usuario. Es decir, ya sabes, escribo algo, lo muestra en la pantalla. Ingreso alguna entrada y hago clic en enviar y me da una especie de respuesta. Y luego, ya sabes, hay algún estado en mi aplicación, el estado se renderiza y eso es responsabilidad del hilo de renderizado. Pero, importante, no es dueño del estado, ¿verdad? El estado es propiedad del hilo principal. Se mantiene en el hilo principal. Debería, de todos modos, debería mantenerse en el hilo principal donde luego podría, ya sabes, en primer lugar, protegerse de usuarios maliciosos que interactúan con tu aplicación, pero también se sincroniza entre todos los hilos de renderizado, todas las ventanas.

Y, ya sabes, el otro punto es, ya sabes esto, piensa en los hilos de renderizado y principal, no como hilos de renderizado y principal, sino piensa en ellos como cliente-servidor, ¿verdad? Piensa en ellos como páginas web y tu servidor. La página web no es dueña del estado, ¿verdad? Si tengo un servidor donde un usuario puede iniciar sesión, mantengo, ya sabes, los detalles del usuario y todos los documentos que ha creado o lo que sea, los mantengo en el servidor, ¿verdad? El servidor es el que es dueño del estado y el cliente solo se encarga de renderizar eso al usuario, mostrarlo de una manera agradable y también recibir la entrada del usuario para luego manipular ese estado en el servidor. Y así es realmente como deberías pensar en el hilo de renderizado versus el hilo principal, ¿verdad? Entonces tu hilo principal es el que se encarga de trabajar, uh... Lo siento, no, no, no. El hilo principal es el que se encarga del estado y de interactuar con el sistema operativo, de hacer las cosas privilegiadas. Y el hilo de renderizado es para renderizar. Y con ese punto, pasemos al punto de control 3 y aquí quiero que me sigas si quieres. Esta es la mejor oportunidad para que realmente juegues ahora. Y lo que quiero que hagas es, ¿cómo podemos refactorizar este código? ¿Cómo podemos refactorizar la aplicación del punto de control 3? ¿Cómo podemos refactorizarla para que la lógica del hilo principal no se congele cuando hacemos clic en el botón? Este es el primer problema que abordaremos. Y tal vez puedas pensar en esto por un segundo por ti mismo. Y luego también te mostraré cómo lo hice yo. Y la forma en que lo hice también será la que se encuentra en el punto de control 4. Entonces, si quieres adelantarte o simplemente quieres saber cómo terminará esto, también puedes hacerlo. Pero te animo a que te tomes un minuto. Piensa en esto Te animo a que te tomes un minuto. Piensa en esto, ¿cómo harías para que esto no suceda en el hilo principal? ¿Cómo podemos aprovechar el hecho de que tenemos múltiples hilos en ejecución? ¿Cómo podemos aprovechar eso a nuestro favor? Voy a hacer una pausa aquí por un segundo. Quiero hacer eso. Juega con el código si quieres. Y voy a abrir la versión de Tauri de esto. Mientras tanto, es un poco más fácil en mi opinión para demostrar. De acuerdo, solo para mostrarte, ahora si hago clic en esto en la aplicación de Tauri, se congela de la misma manera. Ahora no puedo hacer clic, no puedo crear una nueva ventana, no puedo hacer nada. Esto está completamente congelado. Entonces, ¿cómo podemos mover esto fuera del hilo principal? Cierra esto. Ábrelo de nuevo. ¡Boom, okay! Genial. Bien. Solo una pregunta rápida. ¿Estás bien si sigo adelante? Quiero, ya sabes, quiero dejarte suficiente tiempo para que juegues con esto a tu propio ritmo, pero también quiero mostrar esto ahora,

Moviendo la Función Fibonacci al Hilo Principal

Short description:

En el caso de Tauri, el concepto de hilo principal y hilo de renderizado es más pronunciado. Queremos desbloquear el hilo de renderizado para que pueda procesar la entrada del usuario. Movemos la función Fibonacci del hilo de renderizado al hilo principal, adaptando la sintaxis de JavaScript a Rust.

o presumiendo mi solución. Si nadie está pidiendo que me detenga, entonces te mostraré cómo lo hice. Genial. Sí. Así que en el caso de Tauri, siento que en Tauri este concepto de hilo principal y hilo de renderizado es mucho más pronunciado. Es mucho más presente. Así que lo mostraré en una aplicación de Tauri. No te preocupes. Esto implicará un poco de rust, pero no mucho. No te preocupes. Lo explicaré. Primero lo primero, ¿verdad? Tenemos nuestro hilo principal y nuestro hilo de renderizado. Queremos desbloquear el hilo de renderizado, ¿verdad? Para que pueda seguir procesando la entrada del usuario. Y siento que de esta manera aquí también es muy fácil visualizarlo, ¿verdad? Porque tenemos el archivo index.html que representa en código, ¿verdad? Que representa nuestro hilo de renderizado. Luego tenemos el archivo main.rs, que, en términos de código fuente, representa nuestro hilo principal. Y lo que hacemos básicamente, ¿verdad? Lo que hacemos es tomar esta función, tomar la función Fibonacci y, ya sabes, sacarla de nuestro hilo de renderizado y llevarla a nuestro hilo principal. Y, por supuesto, deshacernos de esto. Por supuesto, la sintaxis de JavaScript no es válida en Rust. Entonces lo que tenemos que hacer es, ya sabes, la palabra clave de la función es diferente, pero luego

Reescribiendo la Función JavaScript en Rust

Short description:

Acabamos de reescribir una función JavaScript en Rust, y esto será como cien veces más rápido. Esto puede ser exagerado, pero ahora será mágicamente más rápido, lo cual es increíble si lo pensamos, ¿verdad? Fue realmente fácil, ¿no?

tenemos que darle un tipo a esto y lo haremos un entero sin tamaño con 64 bytes de precisión. Así que un entero relativamente grande, ¿verdad? Porque sabemos que los números de Fibonacci se vuelven realmente grandes. Y esta función toma un entero grande y devuelve un entero grande, ¿verdad? Y esta sintaxis final para crear un final grande como en JavaScript no existe en Rust, así que nos deshacemos de eso. Nos deshacemos de esto. Y las declaraciones de retorno en Rust pueden ser implícitas. Así que si lo pensamos, esto crea un bloque y esto crea un bloque y cualquier tipo de es la última declaración de ese bloque se devuelve inmediatamente, de forma implícita. Así que es similar a la documentación en línea, ¡ganamos! La declaración de retorno al final devolverá ese valor de la función. Pero como estas son las últimas expresiones, perdón, déjame subir esto. Como es la última expresión, la última expresión se devolverá incluso si omites la palabra clave de retorno. Solo porque Rust puede entenderlo automáticamente. Así que para limpiar esto un poco, es opcional, pero deshagámonos del retorno y boom, acabamos de tomar la función JavaScript y reescribirla en Rust. ¡Yay, nuestra primera reescritura en Rust de nuestra career. Tal vez. No sé si no lo eres. Puede que seas un desarrollador muy experimentado en Rust, en cuyo caso, hola, qué bueno tenerte aquí. Pero si es la primera vez que ves código en Rust, es así de fácil, ¿verdad? Esto es todo. Acabamos de reescribir una función JavaScript en Rust, y esto será como cien veces más rápido. En realidad no lo he medido. Esto puede ser exagerado, pero ahora será mágicamente más rápido, lo cual es increíble si lo pensamos, fue realmente fácil, ¿no? Y una cosa que también queremos quitarnos de encima es

Refactorizando el Cálculo de Fibonacci

Short description:

Llamamos a la función Fibonacci para los elementos hasta el número ingresado. Los números resultantes se agregan a un array y se representan utilizando replace children. Queremos deshacernos del bucle bloqueante y devolver un array de números. Creamos una nueva función en Rust llamada calcular, que toma un parámetro límite y devuelve un array de números. Tauri permite que las funciones de Rust estén disponibles en el frontend de JavaScript. Usamos la función invoke en Tauri para llamar a la funcionalidad de Rust en el hilo principal. Por último, refactorizamos el código de creación de HTML para usar el array de números.

Configurando un array y luego llamándolo varias veces. Disculpen si me adelanto, la forma en que lo hicimos, por cierto, me di cuenta de que me adelanté. La forma en que lo hicimos es que llamamos a la función Fibonacci, para todos los elementos hasta el número que ingresamos. Así que si queremos obtener los primeros seis elementos de la secuencia de Fibonacci, llamamos a la función Fibonacci seis veces con 0, 1, 2, 3, 4, 5. Y luego, cualquiera que sea el número resultante de la función Fibonacci, lo tomamos como el contenido de texto de un elemento de lista que creamos, lo agregamos a un array de ahora nodos DOM de HTML, ¿verdad? Y finalmente los representamos utilizando replace children. Y eso hará que todos nuestros elementos de lista aparezcan en este nodo padre de HTML. Disculpen, me di cuenta de que me adelanté. Pero también queremos deshacernos de este bucle, ¿verdad? Porque también este bucle está bloqueando nuestro hilo de representación, ¿verdad? Este bucle también está haciendo que tengamos que llamar esto varias veces. Entonces, ¿qué sería ideal? Si pudiéramos obtener simplemente un array de números, ¿verdad? Así que saquemos esto también. Oh, copiémoslo. Y llevémoslo a nuestro hilo principal. Creemos una nueva función llamada calcular porque soy increíblemente, ya saben, poco creativo. Que toma un parámetro llamado límite. Nuevamente, hagámoslo un número y devuelve un vec de números. Y en el mundo de Rust, un vec es simplemente un array enJavaScript, ¿verdad? Así que una palabra diferente para lo mismo. Y refactoricemos este bucle for en un bucle for de Rust. Entonces, lo que hace esto, si analizamos esta sintaxis muy detallada, básicamente inicializa i en 0. Así que desde 0 hasta cualquier número que esté en límite, ejecutaremos este bucle y Rust tiene una forma muy elegante de hacer esto. Entonces, la forma en que lo hacemos en Rust es diciendo, desde cero hasta límite, límite, y luego vamos aquí y decimos para i en cero hasta el límite. Y creamos unas llaves, y ahora este bucle hará lo mismo que aquí abajo. Y, comentemos esto. No estamos representando HTML directamente, ¿verdad? Pero lo que hacemos es crear un nuevo array. Llamémoslo out. Y si eres una persona de Rust, ahora me odiarás por llamarlo array. Pero esencialmente, creamos un nuevo array. Y lo que hacemos es agregar la salida del número Fibonacci. Así de i, lo agregamos al array. Y por último, tomamos ese array y lo devolvemos . ¡Boom! Así de simple. Ahora, Rust, perdón, ahora Tauri tiene una cosa especial que hace que tus funciones de Rust estén disponibles en el frontend de JavaScript, ¿verdad? Y lo que hacemos para habilitar eso es agregar esto, perdón, agregar este trozo especial de sintaxis en la parte superior de nuestra función de Rust. Y esto se encargará de toda la especie de magia de enlace. Esto lo hará disponible en el frontend de JavaScript. Y por último, solo tenemos que decirle a la gente, tenemos que decirle a Tauri que realmente queremos, ya saben, realmente exponer esto al frontend de JavaScript. Y lo hacemos agregándolo a esta línea aquí. Y con eso, ahora tenemos nuestro código de Rust listo. Así que podemos, ya saben, volvamos a JavaScript y realmente hagamos uso de las cosas que acabamos de hacer. Así que comentemos esto. Oh, perdón. Comentemos esto y usemos una función de Tauri llamada invoke. Así que ahora, lo hemos expuesto, ¿verdad? Al JavaScript, pero ahora necesitamos alguna forma de llamar esto desde JavaScript, ¿verdad? Y la forma en que esto funciona en Tauri es importar esta propiedad en el objeto global llamada, oh, perdón, invoke. Correcto, y como su nombre lo indica, invoke te permite invocar la funcionalidad de Rust en el hilo principal. En los hilos de fondo, ya saben. Así que, ya saben, hagamos, como no puedo escribir y hablar. Usemos esto, ¿verdad? Así que, los valores esperados son iguales a esperar invoke y luego tenemos que darle el nombre de la función que definimos aquí como la función a invocar y le damos el límite. Subamos esto. Le damos el límite como argumento. Hagamos esta función asíncrona. ¡Boom! Eso es todo. Por último, refactoricemos todo este código de creación de HTML

Moviendo la Carga de Trabajo y Sincronización de Hilos

Short description:

Movimos la carga de trabajo fuera del hilo de representación y desbloqueamos la interfaz de usuario convirtiendo un array de números en un array de nodos DOM. El lenguaje Rust se destaca en el manejo de tareas computacionalmente intensivas, como el cálculo de números. Abordamos el problema de la sincronización de hilos creando una estructura en Rust para almacenar el array de valores. Esto nos permitió mover el estado de nuestra aplicación del hilo de representación al hilo principal, lo que resulta en ventanas sincronizadas. Aunque la aplicación de demostración requiere recargar para actualizarse, es posible implementar actualizaciones en tiempo real emitiendo eventos desde el hilo principal al hilo de representación.

para que tomemos este array. Ahora es un array de números. Tomemos este array de números y convirtámoslo en un array de nodos DOM. La forma en que lo hacemos es mapear este array, mapear, oh, perdón. Y luego hacemos esto, hacemos esto, el to string, vean, reemplazamos, ya saben, reemplazamos el código JavaScript para llamar a esto ahora. Y por último, simplemente devolvemos n, porque JavaScript no tiene la característica agradable de Rust donde podemos omitir esta línea.

Genial. Por último, representémoslo. Y eso es todo. Este es todo el código, ya saben, necesario para mover esta carga de trabajo fuera del hilo de representación y desbloquear nuestra interfaz de usuario. Así que, volvamos a ejecutar esto. Veamos si cometí algún error grave. ¿Esto sigue funcionando? Boom. Muy bien. Y ahora, ya saben, probemos esto correctamente. Ejecutemos esto y digamos, 40. Y pueden ver, en primer lugar, esto fue realmente rápido. De hecho, tan rápido que no puedo realmente mostrarles esto. Ok, tal vez, ¿puedo inspeccionar los elementos? Sí, genial. Bien. Ya saben, todavía puedo, esto es un poco difícil de mostrar, pero todavía puedo interactuar con este elemento aquí, aunque esté, ya saben, ejecutando y calculando un montón de números en segundo plano. Y eso es realmente en lo que Rust es muy bueno, ¿verdad? Calcular muchos números. Y por eso, también, elegí demostrar esto con Towers. Pero con eso, sigamos... no, no volvamos a las diapositivas. Abordemos lo siguiente. Y no voy a... en esto, no voy a, ya saben, hacer todo el proceso y codificar esto con ustedes también. Pero déjenme hablarles de cómo abordamos el segundo problema. El segundo problema era que ahora tenemos una aplicación genial, ya saben, que se mantiene receptiva, que utiliza los hilos que tenemos, que utiliza esta paradigma de hilo principal versus hilo de representación, pero si creo una nueva ventana, esto aún no está sincronizado, ¿verdad? Entonces, ¿cómo sincronizamos nuestros hilos? ¿Cómo estructuramos nuestra aplicación para sacar el estado de este hilo y llevarlo al hilo principal para que pueda estar sincronizado? Y en Tauri eso es igual de simple, y permítanme ir directamente al número cinco.

Ok, lo que hacemos esencialmente es, ¿recuerdan nuestra función Fibonacci? Sí, lo que hicimos esencialmente es crear una estructura y la estructura es como un objeto en Rust, ¿verdad? Y este objeto contendrá nuestro array de valores. Así que ahora, movimos el array de valores de JavaScript a Rust. Así que lo movimos del hilo de representación a nuestro hilo principal, a nuestro hilo de Rust. Y de manera similar, ya saben, Calculate, tuvimos que hacer un poco más para, ya saben, bloquear nuestro acceso a ese objeto porque es Rust. No se preocupen por eso. Lo que quiero que entiendan de esto es que ahora movimos este valor, como movimos este valor, movimos el estado de nuestra aplicación que este estado es muy simple, ¿verdad? Este estado es solo un objeto, solo un array de números. Movimos este array de números para que ya no viva en el hilo de representación . Ya saben, no vive en una copia separada del estado en cada hilo de representación, sino que tenemos uno que vive en nuestro hilo principal. Y puedo mostrarles qué efecto tiene o cuál es el efecto de eso ejecutando el punto de control 5, ¿verdad? Esperen un segundo. Ok, ahora tenemos una ventana y digamos, no tan loco como 67 números Fibonacci, pero digamos 20. Calcular, boom, muy rápido. Pero ahora abrimos una nueva ventana. Oh, vean eso. Sí, obtuvo los números Fibonacci del hilo principal y los mostró de inmediato. Bien. Y si ahora, ya saben, digamos 10, ahora actualizaste esta lista y pueden ver que esto no se actualizó, pero si recargamos se actualiza. Y eso es porque simplifiqué esta demostración porque no quería complicarla más de lo que ya está. Ahora podrían agregar fácilmente también actualizaciones en tiempo real. ¿Verdad? Podrían emitir eventos desde el hilo principal al hilo de representación para decirle, oye, ya saben, el estado acaba de actualizarse. Pero en este caso,

Gestión de Estado y Seguridad en Aplicaciones de Escritorio

Short description:

El hilo de representación es la primera línea de defensa contra actores maliciosos. El hilo principal es responsable de gestionar el estado e interactuar con el sistema operativo. El hilo de representación puede solicitar acciones al hilo principal, que valida y sanitiza las solicitudes. Si un front-end comprometido intenta una solicitud maliciosa, el hilo principal puede evitar que llegue al sistema operativo y tomar las acciones apropiadas. La construcción de aplicaciones de escritorio es similar a la construcción de aplicaciones cliente-servidor, requiriendo una reutilización de conocimientos. El concepto de una interfaz de usuario nativa es subjetivo y varía según los sistemas operativos. No hay una distinción clara entre una interfaz de usuario nativa y una no nativa.

de alguna manera, necesitamos recargar para obtener esa información. Pero el punto es que este estado ya no vive en el hilo de representación. Ahora, este estado se ha trasladado a un hilo diferente, al hilo principal que se encarga de gestionar el estado. Y hay una razón muy importante por la que querrías eso, y es la seguridad. Y esto es algo que me importa mucho. La seguridad en las aplicaciones es algo que a menudo se pasa por alto, especialmente con la tecnología web, a la que estamos bastante acostumbrados, ¿verdad? Los navegadores web hoy en día son muy buenos para aislar nuestros sitios. E incluso si, ya sabes, alguien crea un sitio web malicioso, las posibilidades de que ese sitio malicioso infecte seriamente mi máquina y, ya sabes, borre todos mis archivos, los encripte y me chantajee por ello, es como el valor de una pequeña empresa en bitcoins. Eso es muy pequeño. Pero con las aplicaciones de escritorio, estas frameworks te brindan mucho acceso a la máquina, porque eso es lo que quieres, ¿verdad? Realmente quieres poder interactuar con la máquina con tu aplicación de escritorio. Pero con todo ese poder también viene, por supuesto, un mayor riesgo, ¿verdad? Si logro explotar tu aplicación de escritorio, puedo causar mucho más daño de lo que podría hacer con un sitio web. Y aquí es donde, ya sabes, vuelve a entrar en juego la forma de pensar en las aplicaciones utilizando este hilo principal y el hilo de representación, porque el hilo de representación siempre debe verse como no privilegiado, ¿verdad? Este es tu primera línea de defensa contra cualquier actor malicioso. Mientras que el hilo de representación, ahí es donde está tu tesoro preciado, se encuentra en el hilo principal y está protegido, al igual que con un servidor cliente donde se encuentra tu importante datos que se mantiene en esto, ¿verdad? No estás enviando ningún secreto al navegador, al cliente. Y en esta configuración, quiero que pienses en esto nuevamente, ya sabes, como servir a los clientes, el hilo de representación puede pedirle al hilo principal que realice acciones en su nombre, ¿verdad? Porque el hilo de representación a menudo está muy aislado, al igual que un sitio web. Y así, cualquier cosa que el hilo de representación quiera hacer con el sistema operativo, como leer archivos, notificaciones, compartir pantalla, sonido, lo que sea, ¿verdad? Y en todas esas situaciones, el hilo de representación tiene que pedirle al hilo principal que lo haga en nombre del hilo de representación. Y podemos ver esto de una manera divertida. Intento visualizar esto cuando les cuento cómo lo hice, y eso es usando personas, usando estigmas en este caso. Porque es muy similar a cómo asegurarías cualquier cosa en el mundo real, ¿verdad? Si tengo un banco, no se me permite entrar directamente en la bóveda y sacar el dinero que quiero. Tengo que pedirle a la persona en el mostrador, oye, ¿me puedes dar $10 o lo que sea? Y así, en esta analogía, el hilo de representación podría decir, oye, hilo principal, ¿puedes abrir este archivo por mí? Y luego el hilo principal puede inspeccionar esa solicitud, mirar al hilo de representación, validar los argumentos y luego leer el archivo del sistema operativo. Luego, el sistema operativo devuelve el archivo y le entregamos ese archivo al front-end. Y ahora, podemos tomar este archivo y representarlo, podemos hacer lo que sea con él, ¿verdad? Pero ¿qué sucede si un usuario malintencionado compromete nuestro front-end, ¿verdad? Nuevamente, debido a las capas de seguridad, el hilo de representación es nuestra primera línea de defensa. Y ¿qué sucede si esa primera línea de defensa se ve comprometida? Bueno, en el caso de un front-end comprometido, solicitaremos un archivo y en este caso, un actor malicioso quiere leer las contraseñas de su máquina. Entonces le dice al hilo principal, oye, ¿puedes leer este archivo? Y el hilo principal inspeccionará esa solicitud, inspeccionará el front-end y determinará, no, no voy a darte todas las contraseñas de la máquina, eso no es asunto tuyo, no es para lo que estás aquí. Si el front-end no comprometido, por ejemplo, solo debe representar los números de Fibonacci, ¿qué sentido tiene que lea las contraseñas? Eso no tiene ningún sentido. Entonces podemos ver que en este caso, en el mejor caso, en el mejor caso de seguridad, una solicitud de un front-end comprometido ni siquiera llega al sistema operativo. En ese caso, lo que haría el hilo principal si determina que esa solicitud no solo es inválida sino también maliciosa, podría terminar el hilo de representación, podría eliminar todos los archivos, podría mostrar un mensaje de error al usuario y decirle, parece que tu aplicación se ha infectado. Y eso es muy importante porque a medida que te adentras en capas más privilegiadas, un usuario malintencionado puede hacer mucho más daño. Y para reiterar ese punto, el hilo de representación se trata como no privilegiado, se trata como malicioso. Y el hilo principal es el que está en control de los recursos, el que está en control de interactuar con el sistema operativo. Y debe validar y sanitizar cualquier solicitud que le llegue. Pero, y eso también es muy importante. Nuevamente, el tema de las diferencias, pero también de las similitudes, ya sabes todo esto, ¿verdad? Es la misma forma en que construimos aplicaciones servidor y cliente, ¿verdad? El servidor siempre debe validar y sanitizar cualquier solicitud. Ya sabes todo esto y esta es la parte importante. Pero construir aplicaciones de escritorio es mucho, y eso es muy importante para mí, es muy parecido a construir aplicaciones cliente-servidor. Solo tienes que reutilizar tus conocimientos, ¿verdad? Y repensar todos esos bloques de construcción que tienes en tu cabeza sobre lo que hace un servidor y lo que hace un sitio web. Toma estos bloques de construcción y debes reorganizarlos un poco y boom, ya sabes cómo construir una aplicación de escritorio. Así que eso es muy importante para cualquier aplicación de escritorio. Una de las otras cosas en las que la gente a menudo dice, eso no es realmente nativo, eso no es, todavía es un sitio web, yada, yada, yada, es la interfaz de usuario con sensación nativa. Y eso es ya sabes, volviendo a la lección de historia que tuvimos al comienzo de la charla. ¿Qué, ya sabes, qué se entiende por sensación nativa? Y esa es una buena pregunta porque no lo sé, y así, nadie lo sabe. Y eso es lo importante. Como que es un área complicada y muy difícil y eso es porque, ya sabes, la interfaz de usuario es mucho de elecciones, ¿verdad? Y es diferente en cada sistema operativo. Es diferente según el frontend de Linux que uses. Y tampoco hay una distinción clara de qué es una interfaz de usuario nativa y qué no lo es. Por ejemplo, y eso es, ya sabes, el dato curioso que siempre me gusta contar aquí es que la aplicación de configuración de macOS, ¿verdad? Si estás en macOS, estás familiarizado con ella. Si no lo estás,

Nativo vs. Web y Máquinas Virtuales

Short description:

Muchas de las páginas y widgets en la aplicación no son nativos, sino webviews. La línea entre nativo y web es difusa, pero se puede percibir. Configurar máquinas virtuales es una excelente manera de probar tu aplicación en diferentes sistemas operativos.

Tal vez también estés familiarizado con ello. La aplicación de configuración. Muchas de las páginas en esa aplicación y muchos de los widgets que ves en realidad no son nativos. Son solo webviews. Son, en cierto modo, sitios web incrustados y eso es increíble, ¿verdad? Porque, ya sabes, si no te lo hubiera dicho, nunca lo habrías notado. Y eso se remonta a la lección de historia, ¿verdad? La línea es muy difusa. Y es muy difícil definir qué es nativo y qué no lo es. Pero lo sentirás. Y por eso digo que es complicado, ¿verdad? Es difícil, en cierto modo. Supongo que la mayoría de ustedes son desarrolladores y, ciertamente, yo como desarrollador. Me gusta la certeza. Definitivamente, me gusta cuando las cosas están claras. Pero con la interfaz de usuario y especialmente con la sensación nativa, sea lo que sea, las cosas no están nada claras. Pero un consejo que me gusta darte, y es algo que te animaría a investigar realmente. Y ya hice un video en mi canal de YouTube, y planeo hacer muchos más, es configurar máquinas virtuales. Las máquinas virtuales son una herramienta excelente, porque puedes tener todos los sistemas operativos en los que estás interesado en tu máquina local, ¿verdad? Porque, si quisiera probar mi aplicación en Windows, en Linux, en un par de distribuciones de Linux, pero también tal vez en OpenBSD, necesitaría tener esta pila, este gran montón de computadoras portátiles y cambiar entre ellas. Nadie tiene tiempo para eso. Así que las máquinas virtuales son una gran herramienta. Úsalas. Esa es mi gran recomendación.

Diseño de UI, Empaquetado y Distribución

Short description:

El diseño de UI es una profesión compleja y contratar a un diseñador es crucial para crear una sensación nativa en tu aplicación. Sin embargo, la industria aún carece de una solución definitiva para el diseño de UI. Si tienes ideas para simplificar el proceso, considera construir una biblioteca o compartir tus pensamientos. El empaquetado y la distribución son esenciales para las aplicaciones de escritorio, involucrando la construcción, el empaquetado, la firma de código y la distribución. La firma de código aumenta la confianza del usuario pero puede ser tediosa y costosa. Por último, la distribución es clave para que tu aplicación llegue a los usuarios y les permita interactuar con ella.

en este campo. Voy a omitir el ejemplo y pasar a esta diapositiva, ¿de acuerdo? El segundo consejo que tengo en cuanto a la UI, y estoy mirando a todos aquí que siempre se sienten atraídos por la misma enfermedad de los desarrolladores web con la que ciertamente yo comencé, donde pensaba: `Oh sí, soy un desarrollador web, también sé CSS. Puedo simplemente diseñar esto, puedo codificarlo, puedo implementar la funcionalidad, puedo hacer que funcione, puedo construir una aplicación completa yo mismo`, pero, ya sabes, resulta que el diseño, especialmente el diseño de la UI, es una profesión por una razón. La gente estudia eso por una razón, porque es realmente complicado, porque es realmente difícil, ¿verdad? Y por eso, si te tomas en serio tu aplicación, y probablemente no necesite decírtelo, pero contrata a un diseñador, especialmente si estás tratando de lograr una UI específica del sistema operativo y las interacciones, y quieres que se sienta lo más nativa posible, contrata a un diseñador, contrata a alguien que realmente sepa lo que está haciendo. Pero nuevamente, este es un problema sin resolver, ¿verdad? Esto es algo que nosotros como industria aún no tenemos una solución definitiva. Entonces, si tienes una gran idea para simplificar eso, porque cada vez que ves algo que es un problema sin resolver, cada vez que ves algo así, eso es una oportunidad, ¿verdad? Podemos mejorar como industria. Podemos construir herramientas que faciliten esto. Entonces, si tienes una idea, si tienes un pensamiento en mente, si conoces una forma en que podríamos simplificar el proceso de construir UIs, y quieres hacerle un favor a la industria, considera construir una biblioteca. Ciertamente, habla a la gente sobre tu idea porque esto, nuevamente, es un problema sin resolver. Esto es algo en lo que nosotros, como industria, todavía tenemos que mejorar, lo cual también es muy emocionante. Y por último, y esta es otra gran cosa en las aplicaciones de escritorio, el empaquetado y la distribución. ¿Qué es el empaquetado y la distribución? ¿Qué es eso? Y el empaquetado y la distribución, eso es realmente donde las aplicaciones son diferentes de los sitios web porque los sitios web se implementan a través de HTTP. Se cargan en vivo, por así decirlo, mientras que las aplicaciones se distribuyen de antemano en una variedad de formatos de empaquetado diferentes. En Android, se usaría APK, si estás familiarizado con eso. En macOS, se usaría .app o .dmg. En Windows, es MSI. Cosas así. Para preparar tu aplicación que era un sitio web y un binario, para preparar eso para su distribución en tu sitio web o en la tienda de aplicaciones, generalmente se requiere un proceso de cuatro pasos.

Ese proceso de cuatro pasos consiste en la construcción, que es el proceso de tomar tu HTML, tu JavaScript, tu CSS, pero en el caso de, por ejemplo, Tauri, también tu código Rust, compilar todo eso, transpilarlo, ejecutar un paquete, como, estás tomando eso, creando archivos a partir de eso en un formato en el que ahora es ejecutable. Ya no es código fuente más. Es algo en lo que puedes hacer doble clic y se ejecutará. Y dependiendo de tu framework, ese paso podría ser opcional. Ese paso podría llevar más tiempo. Ese paso podría no existir en absoluto. Porque con las PWAs, por ejemplo, no hay ningún paso de construcción en absoluto, a menos que uses un framework de front-end que requiera un paso de construcción como Svelte o Vue o lo que sea. Pero con Tauri, por ejemplo, nuevamente, diferencias y similitudes. Con Tauri, esto es muy pronunciado porque el paso de construcción, ahí es donde ocurre la magia. Pero genial, ahora tienes tu ejecutable, ¿y ahora qué? El segundo paso, eso es el empaquetado. Y el empaquetado, muy similar al paso anterior de construcción, pero el empaquetado ahora toma tu ejecutable y un montón de metadatos, y cosas como iconos, por ejemplo, y los empaqueta en uno de los muchos, muchos formatos de aplicaciones posibles, ¿verdad? Este es el paso donde a partir de un EXE en Windows, creas un MSI, o en macOS, a partir de un ejecutable ELF, lo conviertes en una aplicación con un icono. Y ahora, esto ya se siente mucho, mucho más como una aplicación real que cualquier ejecutable regular. Paso muy importante. Aquí también estableces la descripción de tu aplicación y cosas así. El tercer paso, a menudo pasado por alto, pero si realmente te adentras en los detalles, a menudo es el paso más doloroso, y eso es la firma de código. Y esto es requerido en macOS, por lo que macOS no instalará, si por supuesto hay como soluciones para desarrolladores, pero en el caso común, no instalará tu aplicación si no está firmada. Y es requerido-ish en Windows, si estás familiarizado con esta advertencia, esta aplicación podría contener malware porque no se pudo, no se pudo haber verificado y no es de un desarrollador autenticado. Esta advertencia en Windows, también desaparece si firmas tu aplicación. Entonces, este paso, ya sabes, es realmente importante si quieres aumentar la confianza con tus usuarios, lo cual, ya sabes, para aplicaciones de código abierto, no es tan importante. Además, firmar el código a menudo cuesta dinero. En macOS, tienes que registrarte en el programa para desarrolladores. En Windows, tienes que comprar este certificado. Y esto es un poco, este paso, ya sabes, es un poco molesto. Este paso es un poco tedioso, engorroso, pero en esencia, lo que hace es asegurarse de que los usuarios de la aplicación que descargan proviene del desarrollador que ellos pretendían, ¿verdad? Usando eso, realmente demuestras que tú eres quien construyó esta aplicación. Que este binario que un usuario descarga realmente proviene de ti y no de una parte malintencionada. Entonces, realmente, ya sabes, es realmente importante. Ahora estoy hablando de que proviene de ti versus alguien más. Último paso, distribución. Ahora tienes tu aplicación construida, empaquetada y con código firmado. ¿Cómo llevas esto a tus usuarios? Porque eso es lo que realmente cuenta, ¿verdad? Llevar esto al mundo, llegar

Construcción y Distribución de Aplicaciones de Escritorio

Short description:

Durante esta masterclass, hemos aprendido sobre la arquitectura cliente-servidor, la arquitectura de hilo principal y de renderizado, y cómo aplicar este conocimiento para construir aplicaciones de escritorio. El objetivo es hacer que construir aplicaciones de escritorio sea tan fácil como implementar un sitio web. El grupo de trabajo de Tauri se enfoca en mejorar el proceso de construcción, la experiencia del usuario y la distribución de aplicaciones de escritorio. Ofrecen servicios de consultoría y auditoría, así como oportunidades de empleo. Si tienes alguna pregunta o necesitas ayuda, puedes comunicarte con ellos a través de varios canales.

esto a las personas para que interactúen, interactúen, lo usen. Y para eso, ya sabes, puedes usar muchas técnicas diferentes y, ya sabes, servicios. Lo que uso mucho y lo que la mayoría de las personas usan y también te recomendaría que uses es GitHub releases. Pero también hay, por supuesto, servicios como AWS y todos estos pasos anteriores de construcción y empaquetado y firma de código. Estas son cosas que también puedes automatizar en CI. Así que no tienes que pensar constantemente en ellas como desarrollador individual. Y eso es más o menos el paso cuatro, ya sabes, CI y distribución y llevar tu aplicación al mundo. Además, ya sabes, en tu paso de CI, luego lo enviarías a las tiendas de aplicaciones de Apple o Android, la tienda de Windows, cosas así. Genial. Entonces, ¿qué hemos aprendido durante nuestra, durante esta masterclass hasta ahora, y eso está bien. Ya sabes, lo que realmente quiero que te lleves, especialmente es muy importante, esta arquitectura cliente y servidor, ¿verdad? Esta arquitectura de hilo principal y de renderizado. Esto ya lo sabes y puedes aplicar este conocimiento, especialmente con un enfoque en, ya sabes, el rendimiento y la seguridad. Puedes usar este conocimiento para construir aplicaciones de escritorio, ¿verdad? Usa el multi-hilo, úsalo a tu favor. Y nuevamente, piensa en esto como si estuvieras construyendo aplicaciones cliente y servidor. Y sí, ya sabes cómo construir una aplicación de escritorio... cómo construir la aplicación de escritorio. Y eso, para mí, es muy emocionante y muy empoderador. Ya sabes, los frameworks de aplicaciones de escritorio basados en tecnología web realmente democratizan el acceso a la construcción de aplicaciones de escritorio, y eso es genial. Y otra cosa que quiero mencionar, que mencioné al principio de mi charla, los últimos, ya sabes, pocos pasos de empaquetado y cosas así, nosotros como grupo de trabajo de Tauri hemos pensado mucho en esto y hemos invertido mucho tiempo y energía en, ya sabes, tratar de hacer que el proceso de construcción sea más agradable, tratar de hacer que la experiencia del usuario sea más agradable y, ya sabes, lo que, en cierto modo, nuestro último esfuerzo en esta dirección es en realidad crear una empresa. Y esta empresa, ya sabes, lo mencioné al principio, ya sabes, la categoría intermedia en la que quería enfocarme es la distribución, y esto es en lo que estamos trabajando ahora, hacer lo que acabo de mencionar con la firma y la distribución y la construcción de empaquetado y CI, hacer esto muy fácil. Porque al principio, como mencioné, realmente creo que construir aplicaciones de escritorio debería ser tan fácil como implementar un sitio web, y estamos trabajando en eso. Aún no hemos llegado allí, ya sabes, puedes seguirnos si quieres estar al tanto. Pero eso es en lo que está nuestro corazón, y ahí es donde, ya sabes, creemos que mejorar la experiencia de las aplicaciones de escritorio, y las aplicaciones en general ahora, es en lo que invertimos nuestro tiempo para hacer que esa área sea realmente buena. Y además, ya sabes, si algo fue interesante durante las últimas, ¿cuántas horas han sido?, ya sabes, si te gustó, si te inspiraste, si también quieres construir una aplicación ahora, y necesitas ayuda, ya sabes, similar a lo que mencioné, también ofrecemos servicios de consultoría, hacemos auditorías. Entonces, si tú o tu empresa están buscando construir una aplicación, podemos enseñarte, podemos ayudarte, podemos asegurarnos de que tu código sea bueno, cosas así. Y por último, también debo mencionar que estamos contratando, así que si quieres trabajar con nosotros en esto, ya sabes, en mejorar aplicaciones, llevar aplicaciones de escritorio geniales y pequeñas y de alto rendimiento a las personas, ponte en contacto, ya sabes, haz clic en el enlace, envíanos un mensaje en Twitter. Y con eso, muchas gracias. Oh sí, y Lorenz también mencionó en el chat, si quieres participar en nuestro sorteo, también puedes hacerlo. Deberíamos decirle a más personas al respecto. Genial, bueno, con eso, no hemos llegado a las dos horas, estamos muy cerca, y diría que ahora abro esto para preguntas, así que cualquier pregunta, cualquier cosa. También, por supuesto, siempre puedes unirte al servidor de Discord, o enviarme un mensaje, o mencionar a CrabNebula en Twitter o cualquier cosa, si tienes alguna pregunta en otro momento. Si no, muchas gracias por estar aquí y diría que esto es todo. Gracias, gracias por asistir, gracias por escuchar.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JSNation 2022JSNation 2022
22 min
Tauri Foundations and Futures
Tauri is a rust-based, security-first, open-source application construction framework built on the philosophy of shipping better projects without compromising on our climate goals. This talk will introduce key components and benchmarks of the stable release of the fully-audited framework. Further it will discuss its future as a means of not only delivering desktop and mobile apps, but also its mission of backfitting servo in order to make a fully fledged all-platform webview provider. Finally, we will present our award for "2022's most secure modern web-framework" in the context of webview-based Tauri apps.
Node Congress 2024Node Congress 2024
7 min
Observability Matters: Enhancing Performance of our Node Application with OpenTelemetry
Have you ever considered that when we encounter terms like observability and reliability, our initial instinct is usually to attribute them solely to SRE concerns? Yet, upon closer examination, one may realize that actually implementing observability is, in essence, more aligned with the domain of developers. After all, developers are the ones who directly implement the actual logic into our existing codebase, and who better to understand and debug their code than the developers themselves? Through this session, we will emphasize on understanding the importance of observability specifically from a developer's perspective. Let's explore some best practices that help us effectively debug the performance of our Node application and how the inclusion of open source frameworks like OpenTelemetry could be beneficial to us.