5 alternativas leves ao Electron

Cinco alternativas leves ao Electron merecem atenção: tinyjs, Electrobun, Neutralinojs e Wails, que renderizam o frontend no webview do próprio sistema operacional, e Perry, que compila TypeScript em um app nativo que desenha widgets reais da plataforma e não usa webview nenhum.

Você tem um frontend em React ou Svelte que funciona bem, mas o instalador de um pequeno utilitário construído sobre ele é maior do que a maioria dos apps instalados ao lado.

Todo app Electron empacota seu próprio Chromium e Node.js, então cada instalação carrega um motor de navegador completo, e cada app em execução paga esse preço em espaço em disco e memória. Este artigo compara cinco alternativas usando os mesmos quatro critérios: como cada uma renderiza, qual linguagem roda o backend, quais plataformas desktop ela suporta e para quem ela é indicada.

Por que os desenvolvedores procuram alternativas ao Electron?

A maioria das alternativas ao Electron deixa o Chromium fora do pacote e aproveita o webview que o sistema operacional já traz, o que deixa os apps bem menores. O preço é a consistência de renderização. Seu app roda no WebKit no macOS, no WebView2 no Windows e no WebKitGTK no Linux, então os casos extremos se comportam como quando você publica um mesmo site para o Safari e o Chrome.

Duas opções bem conhecidas não fazem parte das cinco abaixo. O Tauri combina o webview do sistema com um backend em Rust. O Deno Desktop cria apps desktop sobre o runtime do Deno.

A tabela abaixo compara as cinco alternativas ao Electron quanto a motor de renderização, linguagem do backend, plataformas desktop e tamanho informado:

tinyjs: backend em JavaScript sem portas abertas

O tinyjs roda um backend em JavaScript sobre o txiki.js e exibe sua página no webview nativo da plataforma: WebKit no macOS, WebView2 no Windows e WebKitGTK no Linux. A página e o backend se comunicam por um Unix socket (um named pipe no Windows), então o app nunca abre uma porta de rede local.

• Backend: txiki.js (QuickJS mais libuv), com acesso a arquivos, processos, sockets, FFI e SQLite. O Node não é necessário em tempo de execução.
• Plataformas: o repositório tem como alvo macOS, Windows e Linux, e o site do projeto considera o macOS a plataforma principal. Os builds precisam ser feitos no mesmo sistema operacional para o qual você vai distribuir. O tinyjs build gera um pacote assinado e o tinyjs notarize o envia para a notarização da Apple.
• Tamanho: o tinyjs estima um app distribuído em cerca de 6 MB. O runtime txiki.js responde por 5,6 MB desse total.

tinyjs new myapp --template react-ts
cd myapp
tinyjs dev
tinyjs build

O backend exporta um objeto api, e a página chama seus métodos pelo nome:

// src/backend/main.js
export const api = {
  greet: async ({ user }) => `Welcome, ${user}`,
};

// in the page
const message = await tiny.api.call('greet', { user });

O tinyjs alerta que o Linux é onde a renderização mais varia. Os codecs de mídia dependem de quais plugins do GStreamer estão instalados, e a saída da Web Audio pode apresentar chiados no WebKitGTK. Indicado para: desenvolvedores JavaScript que querem o app inteiro, incluindo o backend, em uma única linguagem.

Electrobun: processo principal em TypeScript ou compilado

O Electrobun renderiza com o webview do sistema por padrão. Seu processo principal roda TypeScript sobre o Cottontail (ou Bun), ou você pode escrevê-lo em Zig, Rust, Go ou Odin. Ele tem como alvo macOS, Windows e Linux.

• Renderizador: o webview do sistema, por padrão. Você pode empacotar o Chromium via CEF quando a renderização idêntica entre plataformas importar mais do que o tamanho do download.
• Backend: Cottontail, que a versão 2.0 apresenta como um runtime JavaScript construído com Zig sobre o JavaScriptCore.
• Tamanho: o Electrobun informa downloads compactados de um hello world no macOS ARM64 de 1,28 MiB com processo principal nativo e cerca de 15 MiB com o Cottontail.
• Distribuição: assinatura de código, atualizações diferenciais e instaladores para cada sistema operacional já vêm integrados. O pacote tem licença MIT no npm.

npx electrobun init

import { BrowserWindow } from "electrobun/main";

new BrowserWindow({
  title: "Inventory",
  url: "views://mainview/index.html",
  frame: { width: 1024, height: 720 },
});

O esquema views:// carrega uma view empacotada do seu projeto. Se você usa a CLI Hutch do Electrobun, o hutch electrobun init gera o mesmo projeto. Indicado para: equipes que querem a divisão main/renderer do Electron em um pacote bem menor.

Neutralinojs: apps só de página, sem backend de uso geral

O Neutralinojs renderiza no webview do sistema operacional e não tem um processo de backend JavaScript de uso geral. Seu código roda na página e chama uma API nativa integrada. A documentação confirma que nenhum Chromium é distribuído com o app. Em vez disso, ele usa o web view fornecido pelo sistema operacional, como o WebKitGTK no Linux.

• Backend: a página acessa a camada nativa por meio de uma biblioteca cliente. Segundo o repositório do Neutralinojs no GitHub, as chamadas nativas trafegam por um WebSocket, e um servidor estático integrado entrega os arquivos do frontend. Para lógicas que a API não cobre, você pode escrever extensões em qualquer linguagem e conectá-las via IPC.
• Plataformas: Linux, Windows, macOS e Web. A página de releases lista a v6.10.0 como a versão mais recente.

Indicado para: pequenos utilitários cujas necessidades cabem na API integrada (acesso a arquivos, execução de comandos, diálogos).

Perry: widgets nativos, não um webview

O Perry não é um wrapper de webview. Ele compila TypeScript ahead of time via LLVM em um executável nativo que desenha widgets reais da plataforma: AppKit no macOS, Win32 no Windows e GTK4 no Linux. O Perry também tem como alvo dispositivos móveis, relógios e TV.

• Backend: não existe um backend separado. O app inteiro é TypeScript compilado para código de máquina, com o runtime do Perry linkado ao binário quando o programa precisa dele.
• Limitações: o Perry compila um subconjunto prático do TypeScript, e sua página de limitações descarta o eval() e outros códigos dinâmicos, além de indicar apenas suporte parcial a decorators. Alguns pacotes npm não compilam. Para compatibilidade com pacotes npm em JavaScript, o Perry oferece um runtime V8 opcional via --enable-js-runtime.
• Tamanho: o repositório do Perry indica cerca de 34 KB para um hello world que apenas imprime constantes. Quando o programa usa o runtime (loops, JSON, async), espere alguns MB, cerca de 5,5 MB no macOS arm64.

perry doctor
perry check ./src
perry compile main.ts -o myapp

O perry doctor verifica se o compilador, o linker e o SDK da plataforma estão instalados. O perry check aponta o código que não vai compilar nativamente. O Perry não tem DOM, então o código de frontend que depende do DOM não pode ser aproveitado. Indicado para: desenvolvedores TypeScript dispostos a reescrever a UI para ter controles nativos.

Wails: backend em Go, webview do sistema

O Wails combina um backend em Go com o webview do sistema operacional. Desenvolvedores Go continuam usando as ferramentas de frontend web que já conhecem, e o WebView nativo de cada plataforma faz a renderização, então nenhum motor de navegador é empacotado. O Wails v3.0.0 foi lançado em 26 de outubro de 2026.

• Renderizador: WebView2 no Windows e WebKit no macOS. Desde a v3.0.0, o Linux usa por padrão GTK4 com WebKitGTK 6.0, e a stack antiga com GTK3 continua disponível com -tags gtk3 até a v3.1.
• Status: a v3.0 é a linha estável atual, e a v2 ainda recebe atualizações críticas. O suporte a iOS e Android na v3 é experimental e fica fora da garantia de estabilidade. Novas versões são lançadas com frequência.
• Tamanho: a página Why Wails informa binários de cerca de 15 MB.

go install github.com/wailsapp/wails/v3/cmd/wails3@latest
wails3 setup

Indicado para: equipes cuja lógica de backend já está em Go.

Qual alternativa ao Electron você deve escolher?

A alternativa certa ao Electron depende, em primeiro lugar, da linguagem que você quer no backend e, depois, de quanta variação de renderização você consegue aceitar. JavaScript de ponta a ponta aponta para o tinyjs. Um processo principal em TypeScript com Chromium empacotado opcional aponta para o Electrobun. Go aponta para o Wails, e um app que só precisa de uma API nativa integrada aponta para o Neutralinojs. Se você quer controles nativos em vez de uma UI web, o Perry é a única opção entre as cinco. Antes de se comprometer, crie um hello world com seus dois principais candidatos e rode seu frontend real no webview de cada sistema operacional de destino.

Perguntas frequentes

Os usuários de Windows precisam instalar o WebView2 para rodar apps criados com essas ferramentas?

Normalmente, não. O Evergreen WebView2 Runtime vem pré-instalado em todos os dispositivos com Windows 11, e a Microsoft o distribuiu para a maioria dos dispositivos com Windows 10, incluindo os gerenciados e os ingressados em domínio, a partir de janeiro de 2023. Um pequeno número de máquinas com Windows 10 ainda não o possui. Por isso, a Microsoft recomenda que seu instalador verifique a presença do runtime e o instale quando estiver ausente, mesmo que você use o modo Evergreen.

Posso reaproveitar um frontend React existente com o Perry?

Só em parte, e apenas de forma experimental. O Perry não tem DOM, mas o projeto separado perry-react é um renderizador compatível com React. Um bloco packageAliases no package.json redireciona os imports de react e react-dom para o perry-react, e os elementos JSX são mapeados para widgets nativos, por exemplo, div para VStack e button para Button. O projeto se descreve como uma prova de conceito da Fase 1 voltada ao macOS, com iOS, Android, GTK4 e Win32 planejados. Na Fase 1, instâncias do mesmo componente compartilham o estado dos hooks, a estilização via className não é suportada (apenas props de style inline), e bibliotecas que dependem do DOM ou de className, como MUI ou React Router, não funcionam.

Quais dessas alternativas ao Electron também conseguem criar apps mobile?

O Perry tem como alvo dispositivos móveis. Ele compila o mesmo TypeScript para iOS e Android, e também para watchOS e TV. O tinyjs afirma não suportar iOS nem Android e se define como um runtime desktop. O Neutralinojs lista Linux, Windows, macOS e Web como suas plataformas. O Wails v3 tem suporte experimental a iOS e Android que ainda não está coberto pela garantia de estabilidade. Se você quer um app baseado em webview que também rode em celulares, o Tauri 2 suporta iOS e Android além do desktop.

O que os usuários de Linux precisam ter instalado para rodar um app que usa o webview do sistema?

Eles precisam de uma biblioteca WebKitGTK, porque essas ferramentas usam o webview do sistema em vez de empacotar um próprio. Os exemplos do tinyjs listam a libwebkit2gtk-4.1-0 como requisito no Linux. O Wails v3.0 usa por padrão GTK4 com WebKitGTK 6.0. O suporte a áudio e vídeo depende de quais plugins do GStreamer estão instalados na máquina, então teste a reprodução de mídia em todas as distribuições Linux que você pretende suportar.