Deno Desktop

Artigo original ↗ Discussão no Hacker News ↗

Visão geral do Deno Desktop

  • Oferece uma forma de criar aplicativos desktop com Deno usando tecnologias web (HTML/CSS/JS/TS).
  • Suporta múltiplos backends: WebView do sistema (padrão no design), Chromium empacotado via CEF e um backend de baixo nível “raw” voltado para renderização personalizada (por exemplo, WebGPU).
  • Integra-se aos recursos já existentes do Deno: compilação para binários únicos, cross-compilation, compatibilidade com Node, autoatualizações e o ecossistema npm.

Comparações com Electron, Tauri e outros

  • Posicionado como “parecido com Tauri, mas também pode ser parecido com Electron”:
    • Backend WebView para binários pequenos usando o engine do sistema.
    • Backend CEF opcional para renderização consistente e moderna em várias plataformas.
  • Comparado ao Electron: configuração mais fácil, potencial para bundles menores, TS-first, API do Deno em vez de Node e ferramentas integradas.
  • Comparado ao Tauri: Tauri é baseado em Rust no backend e usa apenas WebView do sistema (CEF a caminho), enquanto o Deno Desktop é baseado em JS/TS e já vem com CEF.
  • Outras alternativas mencionadas: Wails (Go), Dioxus/Blitz (Rust, engine customizado), Sciter, Java/Qt/GTK, abordagens baseadas em WASM (Jumpjet).

Tamanho do binário, desempenho e WebViews versus CEF

  • Alguns usuários relatam uma build de “hello world” em ~440 MB no Windows devido ao CEF; frustração diante da expectativa de apps com menos de 20 MB.
  • Os mantenedores indicam que WebView + compressão pode chegar a ~15 MB, mas o comportamento padrão/do backend está atualmente confuso e a documentação precisa ser corrigida.
  • WebViews do sistema:
    • Prós: binários menores, reutilizam o engine de navegador existente.
    • Contras: bugs específicos da plataforma e antiguidade (especialmente WebKitGTK no Linux, Safari/WebView mais antigo no macOS).
  • CEF:
    • Prós: renderização e APIs previsíveis e sempre atualizadas em todos os sistemas operacionais.
    • Contras: binários grandes; dúvidas sobre runtime/versão compartilhados e se isso realmente evita a duplicação de “browser por app” do Electron.

UI nativa versus UI web e consistência de UX

  • Debate longo e acalorado sobre se “web UI slop” é aceitável em comparação com toolkits nativos.
  • Argumentos a favor de UIs web:
    • Consistência entre plataformas e sistemas operacionais.
    • Enorme familiaridade dos desenvolvedores com HTML/CSS/JS.
    • Toolkits nativos são fragmentados, inconsistentes ou dolorosos (churn de toolkits no Windows, GTK vs Qt, problemas com SwiftUI, diversidade no Linux).
  • Argumentos a favor de UIs nativas:
    • Consistência e padrões em nível de sistema operacional ajudam na usabilidade, descobribilidade e acessibilidade.
    • Muitos apps web/electron ignoram convenções da plataforma, produzem “sopa de pixels” e têm acessibilidade fraca.
    • Alguns dizem que os usuários de fato reclamam de comportamento inconsistente, mesmo sem usar o termo “UI nativa”.
  • Sensação geral de que os próprios sistemas operacionais se tornaram menos consistentes, o que enfraquece para muitos desenvolvedores o argumento de “precisa parecer nativo”.

Segurança, permissões e modelo de IPC

  • Há dúvidas sobre como o sistema de permissões do Deno se aplica a binários desktop compilados.
    • Documentação atual: apps desktop ainda não oferecem prompts de permissão em runtime; as permissões são incorporadas no momento da compilação.
    • Alguns se preocupam que prompts de permissão seriam enganosos se você não controla o runtime empacotado.
  • Sugestões: executar apps baixados com um Deno local confiável (deno run) ou em contêineres/VMs se você se importa em impor permissões.
  • IPC/arquitetura:
    • Backend e UI rodam no mesmo processo (CEF) ou em um grupo de processos rigidamente coordenado (WebView), usando bindings C ABI em processo em vez de IPC baseado em sockets.
    • Isso é visto como tendo menos overhead do que o IPC tradicional no estilo Electron; as implicações de segurança são debatidas, mas não resolvidas no tópico.

Suporte de plataforma, ferramentas e casos de uso

  • Atualmente somente canary (Deno v2.9); alguns usuários encontraram bugs iniciais (janelas em branco) e foram orientados a abrir issues.
  • Suporte a mobile (iOS/Android) é “planejado/em investigação”, mas ainda não está disponível; a documentação sugere suporte futuro.
  • Casos de uso discutidos: ferramentas internas, apps de quiosque, empacotar jogos web para Steam/desktop, distribuir CLIs baseadas em Deno com GUIs opcionais.
  • Alguns estão entusiasmados com o Deno em geral (TS-first, ferramentas integradas, compilação, compatibilidade com Node); outros estão cansados de “mais uma forma de distribuir aplicativos desktop JavaScript inchados”.