Se seu time de produto está sério sobre entregar IA que de fato roda nas máquinas dos usuários, você voltou ao mundo do desktop. A sandbox da web não alcança metade do hardware de que você precisa. Com o HN em polvorosa sobre o Deno Desktop e fornecedores correndo para expor WebGPU, Vulkan 1.2, DirectML e Core ML, 2026 é o ano em que “Electron vs Tauri” virou uma decisão de três vias — agora com o runtime permissionado do Deno na jogada.
Eis a verdade incômoda: sua escolha de desktop vai travar a maior parte do seu risco — segurança, mecânica de updates, acesso à GPU e a velocidade com que você consegue shippar. Este post oferece um framework de decisão à altura de um CTO, não um veredito de fã-clube.
Por que essa decisão é urgente
Três mudanças tornaram essa escolha inadiável:
- O centro de gravidade migrou para IA local. Depois de um ano de debates sobre “há pouca desvantagem em migrar para modelos abertos”, muitos times agora entregam pesos abertos de 3–7B na ponta por latência, privacidade e controle de custos. Isso significa múltiplos gigabytes, bindings de GPU e uma tubulação de updates de verdade.
- As APIs de GPU amadureceram. Com apps mainstream adotando Vulkan 1.2 e o WebGPU estabilizando em pilhas baseadas em Chromium, você consegue de fato descarregar inferência e pipelines de imagem para a GPU do usuário sem bruxaria.
- Segurança e confiança apertaram. Usuários, TI e reguladores estão sensíveis a assinatura de código, notarização e ao que seu app comunica para fora. Seu updater e as configurações de sandbox agora fazem parte da reputação do seu produto.
Os três candidatos a desktop em 2026
Electron (Chromium + Node)
- Footprint: Tamanhos de instalador comumente entre 80–150 MB; updates delta podem cair para dígitos simples de MB com estratégias de block-map.
- Memória: Renderer em idle + processo principal tipicamente 150–300 MB, dependendo de extensões e disciplina com devtools.
- Caminho de GPU: Melhor suporte de WebGPU no curto prazo (Chromium), além de Node-API maduro para backends nativos de ML (llama.cpp, ONNX Runtime, bindings para TensorRT).
- Postura de segurança: Maior superfície de ataque por padrão, mas endurecida com contextIsolation, remote desabilitado e IPC estrito. Renderers em sandbox são recomendados.
- História de updates: Maduro. Assinatura de código + notarização + updates delta são caminhos bem conhecidos.
Tauri (núcleo em Rust + WebView)
- Footprint: Minúsculo. Instaladores na faixa de 5–20 MB para muitos apps porque você reutiliza o webview do sistema.
- Memória: Frequentemente 50–120 MB em idle; árvore de processos menor que a do Electron.
- Caminho de GPU: Você recorrerá a crates Rust e runtimes nativos de ML (llama.cpp, candle, ort) diretamente. O WebGPU dentro do webview do sistema é mais irregular que no Chromium, mas o lado Rust em GPU é forte via wgpu/Vulkan/Metal/DirectX.
- Postura de segurança: Superfície mínima por design. Listas de permissão de comandos, sem Node, menos partes móveis. Você controla os limites nativos em Rust.
- História de updates: Sólida, updates assinados entre plataformas, porém com menos “baterias incluídas” que o ecossistema do Electron.
Deno Desktop (emergente, runtime Deno + shell de UI)
- Footprint: Relatos iniciais sugerem dezenas de MB para o bundle do runtime (menor que um Chromium completo, maior que um shell puro de webview). Espere que isso evolua.
- Memória: Comparável a outros shells de webview para apps simples; mais pesado com UI complexa e tarefas em background.
- Caminho de GPU: Promissor via WebGPU no engine subjacente, além do FFI do Deno para bibliotecas nativas. Ecossistema ainda amadurecendo.
- Postura de segurança: Modelo de permissões forte herdado do Deno (allow-read, allow-net, etc.). Bons defaults para uma postura de menor privilégio.
- História de updates: Em evolução, ainda não tão turnkey quanto as ferramentas incumbentes do Electron. Valide o updater e as peças de assinatura de código em um spike antes de se comprometer.
Primeiro, identifique o perfil do seu app
Não escolha um runtime antes de se comprometer com o que o app realmente é. A maioria dos produtos de IA desktop que vemos se encaixa em um destes três perfis:
- Console de Agente: UI sempre online que orquestra inferência em nuvem com algumas ferramentas locais (captura de tela, teclas, prompts de sistema). Uso local pequeno de modelos; foco em UI/IPC e updates seguros.
- Studio Offline: Inferência local pesada (modelos 3–7B, pipelines de visão, embeddings) com sync opcional na nuvem. Modelos vivem em disco; aceleração por GPU é mandatória.
- IDE/Notebook híbrido: Experiência voltada a desenvolvedores com plugins e ferramentas locais (formatadores, linters, modelos menores) e chamadas ocasionais à nuvem.
Mapeie seu perfil para suas restrições:
- Crítico para segurança? Você pode enfrentar políticas de MDM, checagens corporativas de assinatura de código e regras de sandbox do app.
- Crítico para GPU? Você escolherá backends nativos de ML e os exporá com segurança por meio do seu runtime.
- Sensível a footprint? Tamanho de distribuição e memória importam para usuários de massa e frotas em EDU/governo.
- Skills do time? Times fortes em JS/TS vs. Rust empurram em direções diferentes.
Checagem de realidade sobre GPU e runtime de modelos
Há muito entusiasmo com WebGPU. É merecido, mas dimensione corretamente:
- Modelos pequenos/médios e operações de imagem: WebGPU dentro do Chromium do Electron pode ser ótimo para efeitos baseados em shader e cargas modestas de tensores. Espere aceleração significativa em GPUs integradas.
- LLMs 3–7B em 4-bit: O caminho prático hoje ainda são backends nativos que exploram aceleradores da plataforma: DirectML no Windows, Metal/Core ML no macOS, CUDA na NVIDIA, Vulkan via IREE ou Vulkan do ggml para Linux/AMD. WebGPU não é uma bala de prata para modelos grandes ainda.
- Biblioteca de inferência cross-platform: llama.cpp (família GGUF/ggml) continua sendo a base pragmática. Suporta Metal, CUDA, Vulkan e DirectML e é entregue como bibliotecas estáticas ou dinâmicas às quais você pode se ligar via Node-API (Electron) ou Rust (Tauri). Deno Desktop pode chamá-la via FFI, mas você assumirá mais cola.
A consequência: seu runtime precisa tornar bindings nativos algo entediante — buildar, assinar, pré-carregar e atualizar sem brickar as máquinas dos usuários.
Postura de segurança: a reputação do seu app depende disso
Hardening no Electron
- Desabilite Node nos renderers, habilite contextIsolation, use um IPC tipado com listas de permissão estritas de canais.
- Proíba o módulo remote e require dinâmico no renderer. Faça preload apenas do que for necessário via contextBridge.
- Imponha CSP e audite todos os carregamentos de URL. Trate todo pacote de UI de terceiros como não confiável.
Disciplina no Tauri
- Mantenha a lógica de negócio em comandos Rust; UIs ficam burras. Listas de permissão de comandos com menor privilégio.
- Revise cada crate que você adicionar; um crate comprometido é um comprometimento nativo.
- Coloque acesso a arquivos em sandbox e fixe domínios de egress de rede quando possível.
Permissões no Deno Desktop
- Aproveite as permissões explícitas do Deno (--allow-read, --allow-net, --allow-ffi). Negue por padrão.
- Torne permissões visíveis na UI de configurações; conquiste a confiança do usuário expondo exatamente o que você usa e por quê.
Updates: a fonte silenciosa de indisponibilidades
A maioria das quedas de desktop é auto-infligida por updaters. Seu plano precisa ser explícito:
- Assinatura e notarização: macOS exige assinatura Developer ID + notarização; Windows precisa de Authenticode e reputação no SmartScreen (um certificado EV acelera isso). Automatize ambos os caminhos.
- Updates delta com rollback: A estratégia de block-map do Electron frequentemente reduz updates para 5–20 MB. O updater do Tauri suporta diffs assinados. Seja qual for, implemente rollback automático quando o app falhar ao iniciar após um update.
- Pesos de modelo não são updates do app: Não empacote arquivos de modelo de 3–7 GB dentro de instaladores. Faça download no primeiro run, suporte requisições HTTP com range, verifique checksums e armazene em caches apropriados do SO. Aplique throttle e mostre progresso. Mantenha modelos versionados e com coleta de lixo.
- Rollouts escalonados: Faça canário com 5–10% dos usuários primeiro. Seu updater deve respeitar coortes para que você possa interromper builds ruins rapidamente.
O que medir (antes de se comprometer)
Rode um spike de duas semanas em cada stack candidata com as mesmas features mínimas:
- Carregue um modelo GGUF de 3–4 GB, rode um prompt de 60 segundos, faça streaming de tokens e então descarregue. Registre tokens/s e latência ponta a ponta.
- Registre tempo de cold start em boot limpo e RSS em idle após 60 segundos, com e sem devtools.
- Entregue um build assinado para um grupo de teste e depois envie um update delta. Meça taxa de falhas, desempenho de rollback e downtime percebido pelo usuário.
- Derrube o worker de inferência no meio da execução. Verifique se o app sobrevive e recupera o estado do modelo sem corromper o cache.
Números que movem decisões no mundo real:
- Tamanho do instalador e do delta: Impacta conversões de download e atrito na implantação corporativa.
- Memória em idle: Prediz quantas janelas/abas paralelas você consegue suportar antes de os usuários culparem você pela Síndrome da Máquina Lenta.
- Tokens por segundo em hardware representativo: Em um Mac com M‑series de 16 GB, modelos 7B em 4-bit podem sair de dígitos simples t/s (CPU) para dezenas de t/s (GPU) com o backend certo. Valide isso na sua stack.
Framework de decisão: escolha deliberadamente
Se seu app é um Console de Agente e seu time é forte em TS
- Escolha Electron pelos próximos 12 meses. WebGPU está na frente aqui, o ecossistema para auto-updates e assinatura de código é maduro e há abundância de bindings Node-API para backends nativos.
- Guardrails: Trate renderers como não confiáveis. Nada de Node no renderer, IPC estrito. Use updates delta com rollback. Fixe todos os endpoints de update.
Se seu app é um Studio Offline e você pode alocar Rust
- Escolha Tauri se footprint e menor privilégio importam. Mantenha a inferência em Rust com um crate estável (llama.cpp/candle/ort) e exponha comandos mínimos à UI.
- Guardrails: Reserve 4–6 semanas para acertar backends de GPU, empacotamento binário por plataforma e um updater confiável. Trate seu núcleo em Rust como um serviço de backend com logging e crash reporting.
Se você quer um runtime permissionado e aceita arestas de early adopter
- Faça um piloto com Deno Desktop para ferramentas internas e rollouts controlados. O modelo de permissões é excelente; o ecossistema está alcançando.
- Guardrails: Faça spike cedo no caminho de updater, assinatura e notarização. Tenha uma rota de fuga para Electron ou Tauri se uma integração ausente bloquear sua data de lançamento.
Arquiteturas de referência que sobrevivem ao contato com a realidade
Referência em Electron
- Processo principal: Mínimo. Sem lógica de negócio. Cuida de ciclo de vida, updates e IPC seguro.
- Renderer: React/Svelte + WebGPU para computação leve e visualização. Preload com contextBridge expõe apenas uma superfície de API tipada.
- Worker de inferência: Módulo nativo envolvendo llama.cpp ou ONNX Runtime com interface restrita. Envie binários pré-compilados por plataforma/arquitetura com assinatura de código.
- Updates: Hosting estático compatível com S3 com manifests assinados e deltas via block-map; canário de 10%, rollback em 1 clique.
Referência em Tauri
- Núcleo: Rust orquestra inferência, storage e acesso a arquivos. A UI envia comandos; zero lógica de negócio em JavaScript.
- GPU: Use backends de ML no lado Rust (llama.cpp via C FFI ou bindings Rust; wgpu para kernels customizados) e exponha eventos de streaming para a UI.
- Updates: Updater assinado do Tauri com coortes escalonadas. Modelos baixados pós-instalação, com checksum e retomada.
Referência em Deno Desktop
- Runtime: Flags de permissão do Deno são sua política padrão. A UI roda em um webview; a lógica de negócio fica atrás de gates explícitos allow-*.
- Chamadas nativas: FFI para uma pequena camada em C que envolve seu backend de ML. Mantenha o boundary diminuto e auditado.
- Updates: Valide o updater cedo; se estiver imaturo, implemente um bootstrapper externo assinado que troque o app de forma atômica.
Realismo de time e custo
- POC em Electron: 2–3 engenheiros TS experientes conseguem entregar um POC assinado crível em 2–3 semanas, incluindo um updater básico e um demo de modelo local pequeno.
- POC em Tauri: 1 engenheiro Rust + 1 TS normalmente precisam de 4–6 semanas para integrar um backend acelerado por GPU, ligar um updater sólido e publicar um build assinado em macOS e Windows.
- POC em Deno Desktop: Espere 3–5 semanas com mais risco no updater e nos bindings. Pilote com um público interno primeiro.
Nota de staffing: Brazil tem pools de talento profundos tanto em Rust quanto em TypeScript. Um pod nearshore com 6–8 horas de overlap com os EUA e custo total (fully-loaded) 20–30% menor que contratações nos EUA pode reduzir o risco do seu POC sem virar uma reescrita de um ano.
Riscos que você não pode ignorar
- Supply chain: Sua maior vulnerabilidade ainda são dependências. Trave versões de pacotes, use checagens de integridade e rode builds assinados e reprodutíveis. Revise crates nativos e módulos Node-API como você revisaria um driver de kernel.
- Pressão de disco: Caches de modelos vão inflar. Defina limites explícitos, evacuação por LRU e uma UI limpa para controle de armazenamento. Mantenha a amplificação de escrita sob controle; não desgaste SSDs com logs incessantes ou reescritas em blocos.
- Privacidade e limites de dados: Inferência local não é carta branca de compliance. Telemetria, dumps de crash e prompts em cache ainda podem conter PII. Construa deleção e redação no seu produto, não no backlog.
O que recomendamos agora
- Se você vai shippar neste trimestre com um time forte em TS, escolha Electron, endureça e entregue. Reavalie em 12 meses se o footprint virar sua principal reclamação.
- Se você está construindo um studio offline-first com GPU pesada e pode alocar Rust, escolha Tauri e invista no seu backend nativo de ML como módulo de primeira classe.
- Se sua organização valoriza permissões estritas e APIs padrão da web e você tolera algumas arestas, pilote Deno Desktop agora em ferramentas internas; mantenha um plano B.
Pontos-chave
- Escolha a stack que combina com o perfil do seu app: Console de Agente (Electron), Studio Offline (Tauri) ou Piloto Permissionado (Deno Desktop).
- WebGPU ajuda, mas modelos locais grandes ainda exigem backends nativos de ML. Planeje cedo sua história de bindings e assinatura.
- Seu updater faz parte da segurança do produto. Deltas assinados, rollouts por etapas e rollback instantâneo são inegociáveis.
- Meça o que importa antes de se comprometer: tamanho do instalador, RSS em idle, t/s em hardware representativo e taxas de falha/rollback de updates.
- Footprint e segurança empurram para Tauri; velocidade e ecossistema puxam para Electron; Deno Desktop é promissor para apps permissionados, mas ainda está amadurecendo.
Author: Diogo Hudson Dias