Aplicaciones de Escritorio Más Simples Con Deno

Ahora hablaré sobre la creación de aplicaciones de escritorio con Deno. Esto, como se mencionó hace cinco minutos, acaba de aterrizar. Sí, quiero decir, vamos a entrar en ello. Entonces, primero, sí, soy Leo. Trabajo en Deno, principalmente en la experiencia del desarrollador, APIs web, mantengo JSR si lo usas, y recientemente, también soy delegado de T39.

Entonces, construiste una buena aplicación web. Tienes un producto. Quieres que tu cosa sea un sitio web. Pero de repente la gente pregunta, oye, ¿puedo obtenerlo como una aplicación de escritorio? Y luego tienes que configurar Electron. Electron, aunque es muy poderoso, es mucho para configurar. No es fácil. Quiero decir, tienes una decisión entre, bueno, puedes elegir entre tres cosas diferentes. O bien obtienes una interfaz de usuario consistente, pequeña y rápida, o obtienes un ecosistema de JS.

Y dado que somos JS Nation, supongo que la mayoría de las personas aquí querrán poder usar MPM, los frameworks, la compatibilidad con node, todo lo que te resulta familiar. El problema es que hoy en día, la mayoría de las cosas, te quedas con dos. No puedes obtener los tres. Pero las compensaciones suelen ser con Electron, es un paquete masivo. Estás incluyendo todo Chromium. Eso no es pequeño. Pero si usas Tari y Deoxys, obtienes binarios muy pequeños porque usan la vista web del sistema pero debido a que es vista web, es inconsistente, y no obtienes el ecosistema de JS lo cual es bastante una desventaja.

Todos ellos son un segundo proyecto, una segunda cadena de herramientas. Tienes que pensar en esto por separado. Es como aplicaciones separadas. No puedes simplemente usar tu aplicación web normal como tus aplicaciones de escritorio. Pero, ¿y si pudieras simplemente hacer eso? Muy, muy simplemente. No necesitas hacer ningún cambio. No necesitas descargar una cadena de herramientas separada, a menos que no estés usando Deno, pero esa es una cadena de herramientas adicional, supongo. Pero es solo un comando, y es deno-desktop.

Literalmente solo tienes que llamar a deno-desktop y convertirá tu aplicación en una aplicación de escritorio. Esta es nuestra primera vista pública. Hubo un tweet hace unos días de Ryan, pero ahora hemos decidido que realmente vamos a seguir con esto. Esto se está lanzando como una característica experimental, por lo que hay muchos cambios disruptivos. Muy buggy hasta cierto punto todavía. Eso es de esperarse.

De todos modos, lo lanzamos como una característica experimental. Queremos que lo pruebes y nos des tu opinión. Así que deno-desktop, puedes apuntar a cualquiera de tus frameworks que estés usando. Si estás usando Next.js, puedes simplemente usar eso. Solo tienes que llamar a deno-desktop. Simplemente obtienes una aplicación de escritorio, como un exe.app, solo un ejecutable en Linux, o incluso un distribuible como .msi o DMG. Puedes obtener cualquiera de estos sin ninguna configuración en absoluto. Simplemente funcionará.

O si no tienes uno de estos frameworks, puedes simplemente usar un servidor HTTP. Es bastante sencillo. Simplemente creas tu aplicación Express, o deno-serve, sí. Fetch por defecto, tu aplicación Express, o si tienes tu framework separado que no está listado y genera un servidor HTTP, puedes simplemente usar eso. Simplemente entiende HTTP.

Así que sí, por ejemplo, aquí, simplemente tenemos deno-desktop, este archivo main TS, que es solo una aplicación Express, y obtienes una aplicación de escritorio muy terrible, porque no hay estilo, es solo HTML con H1. Obviamente, querrías hacer más que eso. Si configuras el título, por ejemplo, también tomará el título, y muchas más cosas.

Así que intentemos construir una. Esto puede salir mal. Podría muy probablemente salir mal. Pero sí, así que estamos en un directorio vacío, tengo un directorio de respaldo allí por si acaso que realmente salga completamente mal. Pero usemos MPX, create next app. Solo mi app, claro, usamos los valores predeterminados. Y con suerte la red colabora, mientras vamos al respaldo. Por favor. Está bien.

Muy bien. Y obtenemos una aplicación Next.js bastante estándar, como cualquiera ha visto, así que puedo des-CD en mi app, y es solo lo estándar. Vamos a convertirla en una aplicación de escritorio. Tengo un binario separado aquí, que con suerte, déjame probar esto, ya que parece estar cortado de la pantalla. Debería haber comprobado esto de antemano. Mi error. ¿Puedo redimensionar esto? No, no puedo.

Déjame solo mostrar eso. Tengo Arduino, que es solo local que uso. De todos modos, es Arduino desktop. Me desplazaré hacia abajo en un segundo para ti. Y voy a pasar la bandera dash A, porque Next.js pide muchos permisos, y no voy a pasar cada uno de los que quieren. Y eso es prácticamente todo.

Así que comenzará a construirlo. Tomará un momento. Y simplemente lo empaquetará todo. Y creará un binario. Y obtenemos una aplicación. Así que si yo... Así que ahí está myapp.app. Puedo simplemente llamar a abrir en ella. Y la primera vez tomará un momento para lanzarse. Y se lanzó en el otro... Se lanzó. Ahí es donde los dioses de la demo deciden no cooperar. Lánzalo de nuevo. Confía en mí, probé esto de antemano, y estaba funcionando completamente bien. Lo prometo. Siempre es el caso. Oh, vamos, ahora.

¿En serio? Está bien. Eso no es como estaba planeado. Pero quiero decir, tengo una aplicación demo diferente que mostraré en un momento más tarde. Pero imagina que esto funcionó. ¡Sí! Está bien. Podemos intentar otra cosa.

Así que el escritorio también tiene una bandera HMR. Así que puedes compilar con HMR, y con suerte tal vez esa funcione. Y obtienes una aplicación de escritorio que puedes simplemente modificar en vivo. Va a tardar un poco más en compilar esta. Solo porque configura toda la infraestructura HMR. Pero parece que lo está haciendo.

Y comenzó la aplicación. Y la veo en mi otra pantalla. Dale un segundo. Configurando... Next.js se está compilando. Muy muy rápido. Está bien. Así que imagina que esto funcionó. Nuevamente, demostraré esto con una aplicación separada que es realmente funcional. Pero sí, esto debería haber funcionado. Estaba funcionando hace diez minutos. Así que debería haber hecho una grabación. Eso es culpa mía. Pero sí.

Así que conceptualmente hablando, esto se habría convertido en una aplicación de escritorio que puedes modificar sobre la marcha, y con la típica recarga de módulos en caliente, puedes construir tu aplicación de escritorio. Pero una aplicación de escritorio no es solo poder usar el navegador que viene con ella, y tener tu aplicación web allí. También se trata de poder usar el sistema operativo nativo. Como si quisieras modificar la ventana, como un título personalizado, redimensionar algunos eventos. Quieres modificar la bandeja. Quieres poder modificar la ventana, quieres modificar la bandeja o el dock e interactuar con eso, o todos estos diferentes tipos de eventos, y también, como, diálogos nativos, todo tipo de cosas que usas para hacer una aplicación de escritorio.

Y tenemos, como, aquí hay un poco de un ejemplo. Puedes simplemente crear una ventana del navegador, añadir un binding. Así que los bindings te permiten llamar funciones desde el lado de Deno en el navegador, y así puedes simplemente configurar una función para hacer lo que necesites que el navegador no tiene acceso. Y luego este confirm, por ejemplo, simplemente crea un popup nativo. Ahora, estas son cosas que actualmente soportamos, pero vamos a soportar más. Diálogos nativos, notificaciones, bandeja del sistema, para que puedas interactuar completamente con la bandeja del sistema.

Todo está soportado en la mayoría de los sistemas operativos, así que funciona en Linux y Windows. Hay algunas limitaciones en Linux que todavía estamos resolviendo. Nuevamente, muy experimental. El dock o la barra de tareas, menús, así que eso, y también las ventanas, eventos de entrada, y, nuevamente, estamos añadiendo más cosas. Esto es solo, como, la primera pasada que implementamos. Sí. Los bindings no son IPC como en Electron o Tauri, donde básicamente el backend habla a través de una serialización de procesos cruzados, socket, y serializadores. En realidad estamos en el mismo proceso, así que esto da algunos beneficios que podemos transferir datos entre el navegador y, ya sabes, muy eficientemente, muy rápido, y soportamos, como, bajo el capó hasta donde recuerdo, Electron solo soporta cadenas y hace su propia serialización.

Puedes mover un tipo de JavaScript de un lado a otro. Con algunas limitaciones, pero se puede hacer más en comparación con Electron. Sí, sin sockets, sin copias entre procesos, así que es muy eficiente.

Ahora, el ciclo de desarrollo. Nuevamente, HMR, simplemente editas, guardas y lo ves instantáneamente. Simplemente funciona. Y eso funciona puramente con, correcto, eso funciona principalmente bien con los frameworks, pero también funciona muy bien con cualquier, como, aplicación independiente, que no es parte de los frameworks que mostré anteriormente. Simplemente funcionará.

Así que, sí, las aplicaciones de framework simplemente funcionan, aplicaciones simples. Dino observa el proceso, y simplemente hace cualquiera de las recargas. No necesitas tener herramientas separadas. Dino simplemente hace todo esto por ti. Y sí, el tiempo de ejecución y las ventanas permanecen activas. No tienes que ver constantemente un reinicio. Con Electron, esto es un poco lento. Así que intentamos hacer esto mucho más agradable.

Pero un motor no es suficiente. Con Electron, estás limitado a WebView, con Chromium. Con tower, estás limitado a WebView. ¿Qué pasa si quieres elegir? La gente debería tener el poder de decidir lo que quiere mientras mantiene la tecnología que están usando. Hicimos posible simplemente poder usar ya sea el WebView, que es el predeterminado, o puedes usar Chromium. Todo esto se hace a través de una simple bandera. No cambia. No hace que tu tiempo de compilación sea más lento al construir la aplicación. Simplemente funciona. Simplemente elegimos las cosas correctas para ti, y simplemente hace que funcione.

Así que sí, Ceph obviamente te da más consistencia, pero te da un binario masivo. Un binario de ejemplo era como de 300 megabytes. Todavía estamos tratando de optimizarlo un poco. Y WebView es muy pequeño, como 100 megabytes. Para referencia, el binario de Dino en sí es como, creo que hoy en día es como 80 megabytes. Quizás un poco más, quizás un poco menos, no estoy completamente seguro. Pero sí, siempre depende. Así que en cualquier máquina en la que estés, si estás en un Mac, potencialmente verás cosas diferentes de las que ves en una máquina con Windows, solo porque en Mac, usaría Safari. En Windows, era Chrome bajo el capó. O también puedes simplemente no usar un motor.

Si no quieres renderizar una ventana de navegador, no tienes que hacerlo. Tenemos un backend muy ligero, que es el backend crudo, que básicamente solo te permite gestionar ventanas, obtener todos los eventos, etcétera, así de simple. No obtienes una ventana de navegador, pero obtienes una ventana que puedes usar WebGPU en. Así que si quieres renderizar tal vez usando algo como Three JS en una ventana, puedes hacerlo bastante simplemente. Sí, obviamente no obtienes DOM, ni Chromium, nada, solo una ventana de GPU directamente. Y es el binario más pequeño, obviamente, porque no tenemos que incluir un navegador completo. Sí, así que si quieres, de nuevo, simplemente crear una ventana, obtener el dispositivo GPU, obtener la superficie subyacente de Windows en la que quieres renderizar, y configurar como la superficie de Windows es básicamente como Canvas. Usa exactamente la misma API. Así que si estás familiarizado con Canvas, simplemente reutiliza eso. Y así es como también lo hace compatible con algo como Three JS u otros sistemas que usan Canvas.

Y sí, simplemente lo configuras y luego haces la magia que quieras hacer y lo muestras en la ventana. Y simplemente funcionará. Ahora, esto es como todo bonito, pero ¿qué pasa con querer depurar tu código? Así que usualmente, tendrías un proceso separado, como una depuración separada para el proceso de Deno o el proceso de Node o lo que sea, pero también una depuración separada para la ventana del navegador real, lo cual, sí, estás malabareando los depuradores. Es un poco molesto. ¿Qué pasa si puedes tener ambos en uno?

Así que con dash dash inspect, simplemente obtendrás una ventana de depuración singular, que te muestra ambas salidas de ambos procesos. Puedes modificar, puedes interactuar con ellos, puedes añadir puntos de interrupción, puedes hacer todo lo que estás acostumbrado a hacer con un depurador. Simplemente puedes hacerlo tanto para la ventana del navegador como para el proceso de Deno, todo en una vista. No tienes que complicarte. Y sí, simplemente puedes seleccionarlo a través de un menú desplegable en la esquina.

Está el renderizador, que es la ventana, como la ventana de Chromium, o el proceso de Deno. Ahora, esta función solo funciona con el backend de Ceph, no con el backend de Chrome, ni con el backend de WebView. No podemos transformar de manera confiable el protocolo del inspector de Safari en el viable para V8. Ese es un aspecto técnico en el que no estoy dispuesto a profundizar en la traducción de protocolos. Así que ahora quieres enviar esta aplicación. ¿Cómo haces esto? La distribución siempre es complicada, pero proporcionamos diferentes salidas.

Soportamos .app, .exe y .appimage para los diferentes navegadores como base por defecto. Y también puedes obtener .dmg en Mac OS, pero también estamos añadiendo los archivos .msi y .deb y .rpm para Linux y Windows respectivamente. Y podríamos añadir algunos más, pero estos son la base para realmente soportar casi la mayoría de los casos de uso. Estos estarán disponibles muy pronto, como en los próximos días además.

Y quieres construir para cada plataforma en una sola máquina, porque puedes simplemente compilar cruzado, porque de lo contrario esto se vuelve muy complicado. Así que puedes compilar cruzado para cualquier máquina que quieras apuntar. Y soportamos los casos de uso más comunes, así que Mac OS, Linux, Windows, tanto en ARM como no ARM, excepto Windows en ARM que aún no es una cosa para nosotros. Pero todo lo demás simplemente funciona. Y no necesitas ejecutar CI en diferentes máquinas y hacerlo funcionar y compilar en todas. Simplemente funcionará.

Hay una pequeña limitación del tab anterior, y es que .dmg solo es posible hacerlo en Mac OS. Es una herramienta específica de Mac OS. Así que eso es un poco difícil de evitar. Ahora, quieres actualizar. Así que tenemos un auto-updater. Y esta es la API. Y sí, simplemente, cuando tu actualización esté lista, puedes simplemente aplicar la actualización y revertir atrás. Básicamente puedes definir el comportamiento que quieres hacer. Pero se envía con diferencias binarias. No se envía el binario completo. Así que si solo haces un pequeño cambio, como 4kb, no envías una aplicación completa de 200 o 400 megabytes de nuevo.

Solo descargas la diferencia. Esto se hace a través de diferencias binarias, lo cual es muy agradable y muy conveniente para los usuarios, especialmente cuando la red es muy terrible, o están en una conferencia donde usualmente no es la mejor. Así que sí, se aplica al próximo lanzamiento que el usuario relance la aplicación. Tienes el callback de actualización lista, por lo que técnicamente puedes forzar un relanzamiento y simplemente aplicarlo inmediatamente. O si la actualización falla, simplemente hay un rollback.

Ahora, sí. Luego también hay una versión de dnote.desktop para obtener la última versión de la aplicación que estás construyendo. La mayoría de estas cosas son configurables a través del archivo de configuración. Es DNO, por lo que está utilizando todos los permisos y sandboxing que DNO proporciona. Por defecto, estamos en sandbox, por lo que tu aplicación de escritorio no puede acceder repentinamente al sistema de archivos del usuario o etcétera. Obviamente es más interesante para el usuario final, y no para ti. Probablemente estás tratando de recopilar la mayor cantidad de datos de calamidad del usuario como sea posible, seamos honestos. Así que probablemente solo ejecutes esto con Dash all.

Pero esta es una opción. Así que ya que lo tenemos, ¿por qué no usarlo? Entonces, ¿dónde aterriza? Nuevamente, Electron es la forma principal de hacer esto actualmente, pero no tiene HMR, no tiene la detección automática del framework, y no tiene el sistema de permisos. Todo lo demás funciona. Luego nuevamente, actualizaciones, vas a enviar un binario completo nuevamente, no es ideal. Tory es muy agradable, pequeño y conveniente, pero entonces empiezas a usar Rust. La mayoría de las personas no quieren lidiar con otro lenguaje de programación o Rust. La mayoría de las personas aquí están familiarizadas con JavaScript y quieren quedarse con JavaScript.

Así que intentamos hacer lo mejor de ambos mundos, y no tener que tocar otros lenguajes. Ahora, esto es solo un primer vistazo. Hoy, es muy experimental. Está solo en una rama. Bueno, de hecho, debería haber aterrizado, con suerte, hace unos minutos, justo antes de esta charla. Sí, funciona en todos los sistemas operativos. Nuevamente, hay algunas limitaciones dependiendo del sistema operativo en el que estés, pero estamos tratando de resolver esto. Sí, es solo un toolkit listo para escritorio. Puedes simplemente llamar a todas estas cosas. No tienes solo un resumen. Esto es todo lo que tienes que hacer. Ahora, puedes probar esto ya. Puedes usar Deno upgrade PR, el número de PR 33441, o puedes esperar hasta esta noche, y estará en Deno 2.8.3, creo.

Habrá un lanzamiento. Sé que ya estoy un poco pasado de tiempo, pero voy a mostrar rápidamente una demo rápida de una aplicación real funcionando, porque no pude mostrar eso antes. Así que en realidad tengo una aplicación de ejemplo que hice hace unos días, que es un cliente de Matrix. Para aquellos que no lo saben, es como una plataforma de chat, similar a Discord o lo que sea. Tengo otra ventana aquí que es mi cliente principal que uso yo mismo, y luego esta es la aplicación real, y puedo enviar un mensaje aquí, y esto está funcionando a través del flag dash dash HMR también, así que puedo modificar el código en un momento y mostrarte eso.

Pero si envío un mensaje, tomará un momento y verás que recibo una notificación en la parte inferior, y actualmente tengo las notificaciones desactivadas durante la charla, pero tengo una notificación que llegó. Veamos si puedo mostrar esto aquí. Déjame intentar. ¿Qué pasa si desactivo eso y envío otro mensaje? Aparece en mi laptop. Me gustaría poder mostrarte eso, pero las notificaciones funcionan. En esta aplicación demo, también tenemos un menú personalizado. Puedes iniciar una nueva sala, cosas así, o también tenemos este menú. Así que si envío de nuevo, una aplicación de prueba más, un mensaje de prueba, y voy aquí, tengo el panel pequeño con eso, y puedo hacer lo que quiera. Es solo otra ventana del navegador. Sí, esto es Deno desktop, y, como noté, vamos a impulsar esto, y Deno es compatible con Node. Pasamos más del 75 por ciento de las pruebas de Node.js.

No necesitas estar en el ecosistema de Deno para usar esto. Puedes simplemente usar esto desde tu aplicación actual de Node.js. Así que por favor, pruébalo. APLAUSOS ¿Puede Deno integrarse con el sistema de diseño nativo del OS, como botones, diálogos, campos de entrada, como Mac OS, Liquid UI o Windows UI? Actualmente no, pero lo hemos estado discutiendo. Es un mundo diferente de dolor para implementar, y actualmente, nuestro sistema está basado en navegadores, y el único back-end no es nada. Pero estamos considerando, de hecho, ya hay un proyecto que hace esto que es NativeScript, y primero comencemos compitiendo con Electron. No quiero competir con múltiples proyectos al mismo tiempo. Eso es un gran lío, pero tal vez en el futuro.

Genial. Me encanta lo fluido que parece construir para navegadores, así que eso es genial. Siguiente pregunta de Jan. Según la salida de Deno desktop, el tamaño del comando de la aplicación vacía de Next.js es alrededor de 395 megabytes. ¿Cuánto más pequeño es el paquete de producción, y es eso diferente de Electron en ese aspecto? Sí, así que el paquete es algo que todavía estamos optimizando. Ahora mismo, lo que viste, incluía todo el directorio de Node modules, así que básicamente incluyendo todo lo que probablemente nunca tocarás. Tenemos un parche para eso listo. Simplemente no es parte de allí todavía. Y podrás simplemente empaquetar, y luego usar eso. O, quiero decir, también puedes simplemente ejecutar tu propio paso de empaquetado y no usar la detección del framework, y simplemente llamar a Deno desktop en tu directorio siempre que haya un servidor HTTP que esté ejecutándose en él. Simplemente funcionará. Pero también podríamos agregar solo para el directorio estático, simplemente poder llamar a Deno desktop en eso, y simplemente puedes usarlo. Muy genial. Así que próximamente.

Sí. ¿Deno soportará barras de menú superiores y barras laterales nativas? Barras de menú superiores y barras laterales nativas. No estoy seguro de qué implica eso. Si te refieres con barras de menú superiores, como la barra de navegación superior que mostré durante la demo? Quiero decir, sí. Con barras laterales nativas, no estoy muy seguro de a qué te refieres con eso. Bueno, podrás hablar con Leo después en la sección de inmersión profunda, así que ve con esa pregunta para él. Pero pasaré a otra.

Bueno, actualmente no. Eso es algo que cambiará porque básicamente, estás en el lado de Deno. No tenemos un navegador. Así que Deno va a implementar estas APIs para el sistema de escritorio. No va a ser como una ejecución normal de Deno, como tener APIs de audio, eso está fuera del alcance para Deno en sí, pero para el sistema de escritorio, tiene sentido. Así que, actualmente, no. Las limitaciones son solo, sí, no tienes un navegador. Solo tienes una ventana nativa y lo que sea que las APIs de Deno proporcionen. Genial.

Bien, y alguien ha dicho, Leo, esto se ve increíble. ¿Cuándo podemos ejecutar las aplicaciones en Android slash OS X? De hecho, esto es algo que estamos considerando. Podemos realmente compilar esto para iOS y Android. Es solo que necesitamos experimentar más con esto, pero es algo que estamos investigando y parece viable. Increíble. ¿Soporta las ventanas sin bordes? Sí, el constructor de ventanas tiene muchas opciones. Puedes modificar la ventana, puedes hacerla sin bordes, puedes ocultar la barra superior y no hacerla sin bordes, pero aún tener los controles, ocultar los controles. Es como Electron, relativamente similar en términos de lo que puedes cambiar. Tal vez algunas cosas aún falten, pero todavía estamos expandiéndolo. Nuevamente, esto es experimental. Necesitamos que la gente lo pruebe. Muy genial.

Empieza a experimentar. ¿Cómo se compara la aplicación nativa con un PWA? No estoy muy seguro. Oh, ya veo. Quiero decir, un PWA, por mucho que a la gente le gusten, nunca despegaron realmente. Quiero decir, los PWAs en el escritorio, siento que no son tan comunes o populares. La mayoría de la gente tal vez lo use en iPhone, pero incluso entonces, la mayoría de la gente no usa un PWA al final del día. Bien, interesante.

Alguien ha comentado diciendo que la aplicación funciona y se lanzó. El título mostró My App. ¿Qué hay del soporte de keychain y los usuarios que intentan migrar de Electron a Deno, la migración de keychain? No estoy muy seguro de lo que quieres decir con eso. Si te refieres al keychain, como acceder al keychain del sistema, no tenemos una API para eso todavía, pero ese es uno de los próximos pasos que estamos agregando. Deno ya tiene esto bajo el capó, así que esto es relativamente simple para nosotros de agregar. Bien, genial.

Solo es cuestión de exponerlo. Increíble. ¿Y qué motor de renderizado está usando y qué características de CSS son compatibles? Bueno, el motor de renderizado depende de qué backend elijas. Así que si eliges el backend de Chromium o Ceph, obtienes lo que sea que Chrome soporte. Si usas WebView, entonces buena suerte averiguando lo que puedes porque lo que sea que tu sistema esté ejecutando, eso es lo que obtendrás. Así que si estás en Mac OS, entonces lo que sea que Safari soporte, buena suerte. Gracias. Tengo una última pregunta.

Si pudiera pedir a las personas que están saliendo y entrando que guarden silencio mientras escuchamos la respuesta final de Leo, que es sobre el uso de la opción sin motor. Entonces, si usas la opción sin motor con Deno Desktop, ¿significa que la consistencia de la UI no está garantizada? Supongo que la UI entre los diferentes... Quiero decir, sin motor sería el backend de WebGPU. Digamos el backend crudo, ese no tiene un motor de navegador en absoluto en el backend. Así que hay, sí. Quiero decir, no es inconsistente. Simplemente no está ahí. Solo lo usas para, como, si quieres hacer un juego, eso es lo que usarías, ese backend crudo o WebGPU, porque solo quieres poder de cómputo puro de GPU y no como un navegador. Bien, genial. Así que todo depende completamente del contexto de lo que estás construyendo. Sí. Súper útil. Muchas gracias, Leo. ¿Podemos dar un aplauso más para Leo? Gracias.