- É possível empacotar projetos Deno feitos com apps web e código TypeScript em binários de aplicativos de desktop redistribuíveis para cada plataforma
- A saída inclui junto o código da aplicação, o runtime Deno e o motor de renderização web; entrou no Deno v2.9.0, mas ainda não é um lançamento estável
- O backend WebView padrão usa o webview embutido no sistema operacional para priorizar binários pequenos, e, se for necessária consistência de renderização, é possível escolher o backend Chromium (CEF)
- Detecta projetos Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start e Vite SSR, executando o servidor de acordo com o modo de release e o modo de desenvolvimento
--hmr
- A comunicação entre o código Deno e o webview usa canais in-process em vez de IPC baseado em sockets, e o escopo também inclui cross-compilation e atualizações automáticas baseadas em bsdiff
Papel e estado atual do deno desktop
deno desktop transforma projetos Deno em aplicações de desktop self-contained
- A entrada pode variar de um único arquivo TypeScript até um app Next.js
- A saída é um binário redistribuível específico para cada plataforma
- O binário inclui o código da aplicação, o runtime Deno e o motor de renderização web
- Esse recurso está incluído no Deno v2.9.0, mas ainda não é um lançamento estável
- Para testar agora, é preciso instalar o build
canary com deno upgrade canary
- Comandos, chaves de configuração e a API TypeScript podem mudar antes da estabilização
Escolha de backend e execução de projetos web
- A proposta é usar tecnologias web como toolkit de UI para desktop, reduzindo os trade-offs de ferramentas de apps desktop baseadas na stack web existente
- Ferramentas como Electron, Tauri e Electrobun podem ter trade-offs como binários grandes, lacunas de suporte entre plataformas, ausência do ecossistema JavaScript, falta de atualizações embutidas e ausência de integração com frameworks
- O backend WebView padrão usa o webview do sistema operacional para priorizar binários pequenos
- O ecossistema npm pode ser usado por meio da camada de compatibilidade com Node do Deno
- Se for preciso ter a mesma renderização em macOS, Windows e Linux, é possível escolher o backend CEF, com Chromium empacotado
- A detecção automática de frameworks permite executar projetos web existentes no desktop sem alterações no código
- Os alvos incluem Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start e Vite SSR
- No modo release, ele executa o servidor de produção
- Em
--hmr, ele executa o servidor de desenvolvimento com hot reload
Comunicação de runtime, build e atualizações
- A comunicação entre backend e UI usa canais in-process
- Os valores são codificados ao atravessar a fronteira de chamada
- Não há ida e volta entre processos entre o código Deno e o webview
- É possível fazer cross-compilation para macOS, Windows e Linux a partir de uma única máquina
- O backend não é compilado localmente; ele é baixado quando necessário
- A atualização automática usa um mecanismo embutido de atualização diferencial binária com manifesto
latest.json e patches bsdiff
- O runtime cuida de polling, aplicação e rollback em caso de execução com falha
Exemplo simples e organização da documentação
- Um app de desktop de arquivo único pode ser criado fazendo um
main.ts que retorna uma resposta HTML com Deno.serve() e executando deno desktop main.ts
Deno.serve(() =>
new Response("Hello, desktop
", {
headers: { "content-type": "text/html" },
})
);
deno desktop main.ts
- O binário compilado abre uma janela apontando para um servidor HTTP local vinculado ao handler de
Deno.serve()
- No macOS/Linux, ele é executado com
./main
- No Windows, ele é executado com
.\\main.exe
Deno.serve() é vinculado automaticamente ao endereço para o qual o webview navega, então não é necessário informar porta ou nome de host- A documentação relacionada é dividida em configuração, backends, serving HTTP, frameworks, gerenciamento de janelas, bindings, menus, tray e dock, caixas de diálogo, notificações, HMR, DevTools, atualização automática, relatório de erros, deploy, comparação e referência da CLI
Deno.BrowserWindow trata de ciclo de vida da janela, múltiplas janelas e eventosDeno.autoUpdate() trata de manifesto, bsdiff e rollbackbindings.() é a forma de binding para chamar código Deno a partir do webview
1 comentários
Comentários do Hacker News
O Deno Desktop parece ter escolhido esse compromisso de forma bem opiniosa: “o padrão é enxuto, a compatibilidade com Node é completa”
Testei
deno desktop index.tscom o Hello World de 5 linhas do post, e no Windows 10 o resultado foi de 442MBEu esperava que fosse menor que um build de Electron, então fiquei surpreso por ter ficado muito maior;
libcef.dlltinha 247MB, edeno-test.dll, com o Hello World, tinha 78MBFiquei me perguntando se fiz algo errado
Então eu esperava que, reutilizando algo como a webview do sistema operacional, surgisse uma solução com menos de 20MB, mas passar de 400MB parece meio enganoso
Pode ser que eu tenha configurado algo errado, então queria saber se além de
deno desktop test.tstem mais alguma coisa que precisa ser feitaAchei interessante a parte que diz que, em vez de cada app empacotar seu próprio CEF, dá para gerenciar um runtime compartilhado de CEF, reduzindo o tamanho do binário por app para alguns MB, e que isso está no roadmap
Como não conheço muito bem CEF, fiquei curioso sobre como funcionaria o gerenciamento de versões
Se cada app exigir uma versão diferente de CEF, isso acaba voltando para um modelo como o do Electron, em que cada app carrega seu próprio navegador, ou ainda sobra alguma vantagem no runtime compartilhado mesmo nesses casos?
https://docs.deno.com/runtime/desktop/comparison/
https://github.com/chromiumembedded/cef
O resultado não foi muito bom, mas não sei se isso foi um problema da tecnologia CEF em si ou culpa de outros componentes ou processos
https://www.riotgames.com/en/news/architecture-league-client...
Na prática, quase todos os apps Electron no desktop usam versões diferentes do Chromium, e às vezes mantêm versões antigas por causa do risco de quebrar algo ao atualizar
No Windows, seria algo no estilo do WebView2
O Deno continua impressionando
Faz bastante tempo que não começo um projeto novo sem Deno, e já passei a apoiar totalmente o ecossistema Deno em vez do Node.js
Não sei com que frequência eu usaria esse recurso, mas é muito bom ter essa opção
Trabalho impressionante
Parece algo bem interessante para criar apps desktop com vibe coding
Ferramentas como Lovable, Bolt e v0 já usam TypeScript por padrão ao criar apps web, então isso parece combinar muito bem aqui
Para apps desktop pequenos eu vinha usando Go/Wails em vez de empacotar Chromium e Node, e o Electron também sempre cumpriu seu papel, mas aquele bundle enorme sempre me incomodou bastante
Eu estava curioso para saber como isso se integra com o sistema de permissões do Deno, que é um dos seus maiores pontos fortes
Isso é especialmente importante quando você deixa agentes circularem livremente no seu dispositivo
A documentação de referência da CLI diz que “as permissões concedidas na compilação ficam embutidas no binário compilado”
Seria bom se isso fosse exposto de um jeito que permitisse ao usuário saber e decidir quais permissões serão concedidas
https://docs.deno.com/runtime/reference/cli/desktop/#runtime...
Nesse caso, mostrar um prompt de permissões do Deno poderia até induzir a erro, porque não haveria garantia de integridade dessas permissões
Seria uma forma de aplicar o sistema de permissões do Deno ao sandboxing no desktop, exibindo prompts de permissão para cada acesso ao sistema de arquivos ou à rede
É um recurso inteligente de lançar
Parece algo que eu certamente levaria em consideração ao decidir qual plataforma usar
Com instalação pequena e multiplataforma, parece uma alternativa decente a Electron ou Tauri
Acho que a expressão “tecnologias web são o toolkit de UI mais amplamente conhecido do mundo” não é muito apropriada
Um dos grandes motivos de tantos apps em Electron receberem críticas é justamente por ele estar quase no extremo oposto de um toolkit de UI
Muitas vezes ele não segue direito os padrões de UI do sistema operacional hospedeiro
Tecnologias web são apenas tecnologias web; elas conseguem renderizar um botão, mas não há garantia de que até mesmo um botão sem estilo vá parecer nativo do SO, e isso ainda varia de navegador para navegador
O objetivo nunca foi simplesmente ser um “toolkit de UI” ou “seguir os padrões de UI do SO hospedeiro”
O Chromium traz uma quantidade enorme de recursos, e o Electron aproveita essa utilidade diretamente, o que é uma vantagem
Por exemplo, se você já trabalhou com vídeo, sabe que poder usar dentro de um app desktop toda a capacidade de um navegador moderno muda completamente o jogo
Implementar por conta própria não só a reprodução de vídeo, mas também transcoding com a web moderna e WebCodecs, é um trabalho enorme; ainda mais se for um app desktop que precisa funcionar em Windows/macOS/Linux
Já fiz um app em Electron em algumas dezenas de horas que, de outro jeito, provavelmente levaria dezenas de dias, e mesmo com IA seria difícil se você não fosse especialista em vídeo
Ninguém afirmou que fosse uma UI “nativa”
A UI nativa no Linux sempre me pareceu bem feia, e eu sempre achei muito melhor usar um layout em HTML+CSS bem feito
Na minha experiência, Electron costuma ser criticado principalmente por ser pesado e lento; o fato de não ser nativo é mais um ponto adicional que as pessoas mencionam
Há muito tempo eu queria criar uma integração direta com o navegador que usasse HTML+CSS para layout, mas sem precisar de runtime JavaScript
Não sei o quão leve é o Servo, mas seria ótimo se uma ideia assim virasse realidade algum dia
Como usuário, estou muito satisfeito, e embora ainda faltem recursos básicos como acessibilidade, acho que isso deve ser implementado em breve
Do ponto de vista de desenvolvedor, além do Rust, não vejo muito bem qual seria a barreira de entrada, e ao mesmo tempo o Rust também é um diferencial
Isso era discussão de uns 25 anos atrás; depois que até a Microsoft deixou de se importar, praticamente ninguém mais ligou muito para isso
Eu não quero que meu app pareça diferente em cada SO
Não tenho recursos para testar em todos os dispositivos, e saber que a tela testada em um sistema vai parecer exatamente igual nos outros é uma vantagem enorme
Fico feliz de ver surgir um concorrente nessa área
Especialmente porque o Deno, no estado atual, consegue executar TypeScript de verdade diretamente, em vez de apenas remover os tipos como a implementação do Node
Ainda assim, isso parece que vai tomar uma fatia considerável do mercado do Tauri
Agora, por que eu usaria Tauri?
Na maioria das conexões de internet, um aumento de 150 MB no tamanho do bundle significa só uma diferença de 1 a 10 segundos no download, e em troca você ganha um mecanismo de renderização confiável
Se quiser checagem de tipos, é preciso rodar com
deno run --checkou usar separadamente o subcomandodeno checkDurante o desenvolvimento isso geralmente não é um grande problema, porque a IDE costuma fazer checagem de tipos e lint automaticamente
Na verdade, você nem precisa usar JavaScript
E já vimos várias startups de frameworks para desenvolvedores, como Astro, Nuxt, UV, Bun e Vite, serem adquiridas
Para software que precisa ser mantido e receber suporte por anos, esse tipo de movimento não inspira muita confiança
Deno Desktop e Tauri não usam ambos a webview do sistema?
Por que usar isso e não usar Electron?
Entre os materiais divulgados pelo Deno, a seção de comparação foi a que eu mais gostei
Na última linha, o suporte a iOS/Android aparece como “no” para o Electron e “not yet” para o Deno; se eles realmente conseguirem fazer isso, vai ser algo bem maior
Parece muito bom para distribuir jogos web como apps da Steam ou apps para compras online
Pretendo testar