Deno Desktop: empaquetar proyectos de Deno como apps de escritorio

 (docs.deno.com)
1 puntos por GN⁺ 5 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Permite empaquetar proyectos de Deno hechos con apps web y código TypeScript como binarios de aplicaciones de escritorio redistribuibles para cada plataforma
  • El resultado incluye en conjunto el código de la aplicación, el runtime de Deno y el motor de renderizado web; llegó en Deno v2.9.0, pero todavía no es una versión estable
  • El backend WebView predeterminado usa el webview integrado del sistema operativo para apuntar a binarios pequeños, y si se necesita consistencia de renderizado se puede elegir el backend Chromium (CEF)
  • Detecta proyectos de Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start y Vite SSR, y ejecuta el servidor según el modo release o el modo de desarrollo --hmr
  • La comunicación entre el código Deno y el webview usa canales en proceso en lugar de IPC basado en sockets, y también cubre compilación cruzada y actualizaciones automáticas basadas en bsdiff

Rol y estado actual de deno desktop

  • deno desktop convierte proyectos de Deno en aplicaciones de escritorio autocontenidas
    • La entrada puede ir desde un solo archivo TypeScript hasta una app de Next.js
    • La salida es un binario redistribuible para cada plataforma
    • El binario incluye el código de la aplicación, el runtime de Deno y el motor de renderizado web
  • Esta función está incluida en Deno v2.9.0, pero todavía no es una versión estable
    • Para probarla ahora, hay que instalar un build canary con deno upgrade canary
    • Los comandos, claves de configuración y la API de TypeScript pueden cambiar antes de que se estabilice

Elección de backend y ejecución de proyectos web

  • Adopta un enfoque de usar tecnologías web como toolkit de UI de escritorio mientras reduce los trade-offs de las herramientas de apps de escritorio basadas en stacks web existentes
    • Herramientas como Electron, Tauri y Electrobun pueden tener trade-offs como binarios grandes, falta de soporte en algunas plataformas, ausencia del ecosistema JavaScript, falta de actualizaciones integradas o ausencia de integración con frameworks
  • El backend WebView predeterminado usa el webview del sistema operativo para apuntar a binarios pequeños
    • Se puede usar el ecosistema npm mediante la capa de compatibilidad con Node de Deno
    • Si se necesita el mismo renderizado en macOS, Windows y Linux, se puede elegir el backend CEF, que incluye Chromium empaquetado
  • La detección automática de frameworks permite ejecutar proyectos web existentes en escritorio sin cambios de código
    • Los objetivos incluyen Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start y Vite SSR
    • En modo release ejecuta el servidor de producción
    • En --hmr ejecuta el servidor de desarrollo con hot reload

Comunicación en runtime, compilación y actualizaciones

  • Para la comunicación entre backend y UI usa canales en proceso
    • Los valores se codifican al cruzar el límite de invocación
    • No hay viajes de ida y vuelta entre procesos entre el código Deno y el webview
  • Se puede hacer compilación cruzada para macOS, Windows y Linux desde una sola máquina
    • El backend no se construye localmente, sino que se descarga cuando hace falta
  • Las actualizaciones automáticas usan una actualización diferencial binaria integrada con manifiesto latest.json y parches bsdiff
    • El runtime se encarga del polling, la aplicación y el rollback ante ejecuciones fallidas

Ejemplo simple y estructura de la documentación

  • Una app de escritorio de un solo archivo se puede crear haciendo un main.ts que devuelva una respuesta HTML con Deno.serve() y ejecutando deno desktop main.ts
Deno.serve(() =>
  new Response("Hello, desktop

", {
    headers: { "content-type": "text/html" },
  })
);

deno desktop main.ts
  • El binario compilado abre una ventana que apunta a un servidor HTTP local enlazado al handler de Deno.serve()
    • En macOS/Linux se ejecuta con ./main
    • En Windows se ejecuta con .\\main.exe
  • Deno.serve() se enlaza automáticamente a la dirección a la que navega el webview, así que no hace falta pasar puerto ni nombre de host
  • La documentación relacionada se divide en configuración, backends, serving HTTP, frameworks, gestión de ventanas, bindings, menús, bandeja y dock, cuadros de diálogo, notificaciones, HMR, DevTools, actualizaciones automáticas, reporte de errores, despliegue, comparaciones y referencia de CLI
    • Deno.BrowserWindow está relacionado con ciclo de vida de ventanas, múltiples ventanas y eventos
    • Deno.autoUpdate() está relacionado con manifiestos, bsdiff y rollback
    • bindings.() es la forma de binding para llamar código Deno desde el webview

Lecturas relacionadas

1 comentarios

 
GN⁺ 5 시간 전
Comentarios en Hacker News

  • Parece que Deno Desktop definió ese punto de equilibrio de forma bastante opinionada: “base pequeña, compatibilidad con Node completa”
    Probé deno desktop index.ts con el Hello World de 5 líneas del artículo, y en Windows 10 el resultado fue de 442MB
    Me sorprendió porque esperaba que fuera más pequeño que un build de Electron, pero salió mucho más grande; libcef.dll pesaba 247MB y deno-test.dll, que contenía el Hello World, 78MB
    Me pregunto si hice algo mal

    • Recuerdo que incluso un Hello World de Electron, incluyendo el runtime del navegador/Chromium, rondaba los 100~150MB
      Así que esperaba que reutilizando algo como el webview del SO pudiera salir una solución de menos de 20MB, pero que pase de 400MB se siente un poco engañoso
      Puede que haya configurado algo mal, así que me pregunto si además de deno desktop test.ts había que hacer algo más

  • Me pareció interesante la parte de “en vez de que cada app empaquete su propio CEF, administrar un runtime compartido de CEF podría reducir el tamaño binario por app a unos pocos MB, y está en la hoja de ruta”
    No conozco bien CEF, así que me da curiosidad cómo se manejaría el versionado
    Si cada app requiere una versión distinta de CEF, ¿al final se vuelve al modelo tipo Electron en el que cada app carga con su propio navegador, o incluso en esos casos sigue habiendo ventajas de un runtime compartido?
    https://docs.deno.com/runtime/desktop/comparison/

    • CEF significa Chromium Embedded Framework
      https://github.com/chromiumembedded/cef
    • Como referencia, CEF también se usó en Riot y en el cliente de League of Legends
      El resultado no fue muy bueno, aunque no sé si eso fue problema de CEF en sí o de otros componentes o procesos
      https://www.riotgames.com/en/news/architecture-league-client...
    • Dudo que la ventaja sea tan grande
      En escritorio, prácticamente todas las apps de Electron usan versiones distintas de Chromium, y muchas mantienen versiones viejas por el riesgo de que algo se rompa al actualizar
    • Los desarrolladores web están acostumbrados a que el entorno objetivo se actualice constantemente, así que parece posible que exista la opción de sumarse o no a un modelo tipo “simplemente dame lo más reciente que tengas”
    • Preferiría que usaran una webview del sistema en vez de descargar y administrar un navegador embebido
      En Windows sería algo como WebView2

  • Deno me sigue impresionando
    Hace bastante que no empiezo un proyecto nuevo sin Deno, y ya terminé apoyando por completo el ecosistema de Deno por encima de Node.js
    No sé con qué frecuencia usaría esta función, pero está muy bien tener la opción

  • Es un trabajo impresionante
    Parece bastante interesante para hacer apps de escritorio con vibe coding
    Herramientas como Lovable, Bolt y v0 ya usan TypeScript por defecto al crear apps web, así que esto les queda muy bien
    Para apps de escritorio pequeñas he estado usando Go/Wails en vez de empaquetar Chromium y Node, y aunque Electron también cumplía bien su función, ese bundle enorme siempre me generó un rechazo claro

  • Tenía curiosidad por cómo se integra con el sistema de permisos de Deno, una de sus mayores fortalezas
    Especialmente importante cuando dejas que agentes se paseen libremente por tu dispositivo
    La documentación de referencia del CLI dice que “los permisos otorgados en compilación quedan incrustados en el binario compilado”
    Estaría bueno que eso se expusiera para que el usuario pueda saber y decidir qué permisos otorgar
    https://docs.deno.com/runtime/reference/cli/desktop/#runtime...

    • Estamos hablando de ejecutar un binario recibido de un desarrollador
      Si ahí muestras el prompt de permisos de Deno, creo que podría ser incluso confuso, porque no hay garantía de integridad sobre esos permisos
    • Una de las cosas que todavía le faltan a Deno Desktop son permisos en tiempo de ejecución para apps de escritorio
      Sería aplicar el sistema de permisos de Deno al sandboxing de escritorio, mostrando prompts para cada acceso al sistema de archivos o a la red

  • Es una función inteligente para lanzar
    Creo que realmente entraría en consideración al decidir qué plataforma usar

    • De acuerdo
      Si tiene instalación pequeña y es multiplataforma, parece una alternativa decente a Electron o Tauri

  • No me parece muy adecuada la expresión de que “las tecnologías web son el toolkit de UI más conocido del mundo”.
    La razón por la que las apps de Electron reciben tantas críticas es casi la opuesta a un toolkit de UI.
    Muchas veces no siguen bien los patrones de UI del SO anfitrión.
    Las tecnologías web son solo tecnologías web; pueden renderizar un botón, pero ni siquiera un botón sin estilos tiene garantía de verse como uno nativo del SO, y además cambia según el navegador.

    • La gente no usa Electron por eso.
      El objetivo nunca fue simplemente tener un “toolkit de UI” o “seguir los patrones de UI del SO anfitrión”.
      Chromium incluye una cantidad enorme de funciones, y Electron aprovecha toda esa utilidad, lo cual es una ventaja.
      Por ejemplo, si has trabajado con video, sabes que poder usar dentro de una app de escritorio toda la capacidad de un navegador moderno cambia por completo el panorama.
      No solo la reproducción de video, también el transcodificado posible con la web moderna y WebCodecs: implementar eso directamente sería un trabajo enorme, y más aún para una app de escritorio que deba funcionar en Windows/macOS/Linux.
      Tengo una app hecha con Electron en unas decenas de horas; de otra forma probablemente habría tomado decenas de días, y aun usando IA habría sido difícil si no fueras especialista en video.
    • No entiendo por qué dicen que esa expresión es mala.
      Nunca se afirmó que fuera una UI “nativa”.
      La UI nativa de Linux siempre me ha parecido bastante fea, y siempre sentí que era mucho mejor usar un layout HTML+CSS bien cuidado.
      En mi experiencia, a Electron lo critican sobre todo por ser pesado y lento, y que no sea nativo es más bien algo adicional que la gente menciona.
      Desde hace mucho he querido crear una integración directa con el navegador usando HTML+CSS para el layout, pero sin necesitar un runtime de JavaScript.
      No sé qué tan ligero sea Servo, pero ojalá algún día una idea así se vuelva realidad.
    • Cada vez que uso Zed en Linux, macOS y Windows me sorprende lo estable y rápido que es el framework GPUI.
      Como usuario, me deja muy satisfecho, y aunque todavía le faltan funciones básicas como accesibilidad, creo que pronto las implementarán.
      Desde la perspectiva del desarrollador, fuera de Rust no tengo muy claro cuál sería la barrera de entrada, y al mismo tiempo Rust es justamente uno de sus diferenciadores.
    • Que la UI se vea nativa ya perdió fuerza como argumento en contra hace mucho tiempo.
      Es una discusión de hace como 25 años, y desde que incluso Microsoft dejó de prestarle atención, a casi nadie le importa demasiado.
    • Parece que ves como desventaja el hecho de no seguir los patrones de UI del SO anfitrión, pero para mí esa es una de las principales ventajas de Electron.
      No quiero que mi app se vea distinta entre distintos SO.
      No tengo recursos para probar en todos los dispositivos, y que una pantalla probada en un sistema se vea exactamente igual en otro es una ventaja enorme.

  • Me alegra que aparezca un competidor en esta área.
    En especial, me gusta que Deno actualmente pueda ejecutar TypeScript real directamente, en vez de limitarse a quitar tipos como hace la implementación actual de Node.
    Aun así, parece que esto le va a quitar bastante mercado a Tauri.
    Ahora, ¿por qué habría que usar Tauri?
    En la mayoría de las conexiones a internet, un aumento de 150 MB en el tamaño del bundle solo implica entre 1 y 10 segundos extra de descarga, y a cambio obtienes un motor de renderizado confiable.

    • Deno también, por defecto, solo elimina las anotaciones de tipo cuando ejecuta código TypeScript.
      Si quieres verificación de tipos, tienes que ejecutar deno run --check o usar el subcomando separado deno check.
      Durante el desarrollo normalmente el IDE ya hace automáticamente la verificación de tipos y el linting, así que no suele ser un gran problema.
    • Tauri no te encierra en un ecosistema de JavaScript específico.
      De hecho, ni siquiera hace falta usar JavaScript.
      Y ya hemos visto cómo varias startups de frameworks para desarrolladores, como Astro, Nuxt, UV, Bun y Vite, terminan siendo adquiridas.
      Si se trata de software que debe mantenerse y recibir soporte durante años, esa tendencia no inspira mucha confianza.
    • Uso Tauri cuando el “backend” no es JavaScript.
    • No termino de entender eso de obtener un “motor de renderizado confiable”.
      ¿Deno Desktop y Tauri no usan ambos la webview del sistema?
    • Siguiendo esa lógica, sería lo mismo que decir que hay que usar Electron.
      Entonces, ¿por qué usar esto y no Electron?

  • De todo el material que publicó Deno, la sección de comparación fue lo que más me gustó.
    En la última línea dice que el soporte para iOS/Android en Electron es “no” y en Deno “not yet”; si realmente logran eso, sería muchísimo más grande.

  • Parece realmente bueno para distribuir juegos web como apps de Steam o apps para compras en línea.
    Pienso probarlo.