Deno Desktop

Artículo original ↗ Discusión en Hacker News ↗

Resumen de Deno Desktop

  • Ofrece una forma de crear aplicaciones de escritorio con Deno usando tecnologías web (HTML/CSS/JS/TS).
  • Admite múltiples backends: WebView del sistema (predeterminado en el diseño), Chromium integrado mediante CEF y un backend de bajo nivel “raw” orientado a renderizado personalizado (por ejemplo, WebGPU).
  • Se integra con las funciones existentes de Deno: compilación a binarios únicos, compilación cruzada, compatibilidad con Node, actualizaciones automáticas y el ecosistema npm.

Comparaciones con Electron, Tauri y otros

  • Se presenta como “como Tauri, pero también puede ser como Electron”:
    • Backend WebView para binarios pequeños usando el motor del sistema.
    • Backend CEF opcional para un renderizado coherente y moderno entre plataformas.
  • Comparado con Electron: configuración más sencilla, posibilidad de bundles más pequeños, enfoque TS-first, API de Deno en lugar de Node y herramientas integradas.
  • Comparado con Tauri: Tauri tiene un backend basado en Rust y solo WebView del sistema (CEF está en camino), mientras que Deno Desktop está basado en JS/TS y ya incluye CEF.
  • Otras alternativas mencionadas: Wails (Go), Dioxus/Blitz (Rust, motor personalizado), Sciter, Java/Qt/GTK, enfoques basados en WASM (Jumpjet).

Tamaño del binario, rendimiento y WebViews frente a CEF

  • Algunos usuarios informan de una compilación “hello world” de ~440 MB en Windows debido a CEF; una decepción dadas las expectativas de aplicaciones de menos de 20 MB.
  • Los mantenedores indican que WebView + compresión puede llegar a ~15 MB, pero el comportamiento por defecto/backend resulta confuso por ahora y hace falta corregir la documentación.
  • WebViews del sistema:
    • Pros: binarios más pequeños, reutilizan el motor del navegador existente.
    • Contras: errores específicos de plataforma y antigüedad (especialmente WebKitGTK en Linux, Safari/WebView más antiguos en macOS).
  • CEF:
    • Pros: renderizado y APIs predecibles y siempre actualizados en todos los sistemas operativos.
    • Contras: binarios grandes; dudas sobre el tiempo de ejecución/ versionado compartidos y sobre si realmente evita la duplicación de “un navegador por aplicación” al estilo Electron.

Interfaz nativa vs interfaz web y consistencia de UX

  • Largo y acalorado debate sobre si la “chapuza de UI web” es aceptable frente a los toolkits nativos.
  • Argumentos a favor de las UIs web:
    • Consistencia multiplataforma entre sistemas operativos.
    • Gran familiaridad de los desarrolladores con HTML/CSS/JS.
    • Los toolkits nativos están fragmentados, son inconsistentes o dolorosos (cambios frecuentes en toolkits de Windows, GTK frente a Qt, problemas con SwiftUI, diversidad en Linux).
  • Argumentos a favor de las UIs nativas:
    • La coherencia a nivel de sistema operativo y sus patrones mejora la usabilidad, la descubribilidad y la accesibilidad.
    • Muchas aplicaciones web/electron ignoran las convenciones de la plataforma, generan “sopa de píxeles” y tienen una a11y débil.
    • Algunos dicen que los usuarios sí se quejan del comportamiento inconsistente, aunque no usen el término “interfaz nativa”.
  • Sensación general de que los propios sistemas operativos han perdido coherencia, lo que debilita el argumento de “debe parecer nativo” para muchos desarrolladores.

Seguridad, permisos y modelo IPC

  • Preguntas sobre cómo se aplica el sistema de permisos de Deno a los binarios de escritorio compilados.
    • La documentación actual: las aplicaciones de escritorio todavía no ofrecen solicitudes de permisos en tiempo de ejecución; los permisos se fijan en tiempo de compilación.
    • A algunos les preocupa que las solicitudes de permisos sean engañosas si no controlas el runtime incluido.
  • Sugerencias: ejecutar las aplicaciones descargadas mediante un Deno local de confianza (deno run) o en contenedores/VM si te importa hacer cumplir los permisos.
  • IPC/arquitectura:
    • El backend y la UI se ejecutan en el mismo proceso (CEF) o en un grupo de procesos estrechamente coordinado (WebView), usando enlaces C ABI en el proceso en lugar de IPC basado en sockets.
    • Esto se percibe como de menor sobrecarga que el IPC tradicional estilo Electron; las implicaciones de seguridad se debaten, pero no se resuelven en el hilo.

Compatibilidad de plataformas, herramientas y casos de uso

  • Actualmente solo en canary (Deno v2.9); algunos usuarios encontraron errores tempranos (ventanas en blanco) y se les pidió que abrieran incidencias.
  • La compatibilidad con móvil (iOS/Android) está “planeada/en investigación”, pero no está disponible; la documentación insinúa soporte futuro.
  • Casos de uso debatidos: herramientas internas, aplicaciones tipo kiosk, empaquetar juegos web para Steam/escritorio, distribuir CLIs basadas en Deno con GUI opcional.
  • Algunos están entusiasmados con Deno en general (TS-first, herramientas integradas, compilación, compatibilidad con Node); otros están cansados de “otra forma más de distribuir aplicaciones de escritorio de JavaScript infladas”.