Passe tempo suficiente no Hacker News ou no Reddit e você acabará vendo a mesma crítica: Electron é inchado, Electron usa memória demais e aplicativos de desktop sérios deveriam ser nativos.
Há alguma verdade nessa crítica. Aplicativos Electron geralmente têm um consumo básico de recursos maior porque incluem Chromium e Node.js. Um aplicativo nativo cuidadosamente desenvolvido pode usar menos memória, iniciar mais rápido e se integrar mais profundamente ao sistema operacional.
Mas esse debate se concentra demais no computador e de menos na empresa que desenvolve o software.
Para a maioria dos usuários, a tecnologia por trás de um aplicativo pouco importa. Eles se importam com o funcionamento, a capacidade de resposta, a correção de bugs e a chegada constante de recursos úteis. Para uma empresa de software, uma das propriedades mais importantes de uma stack tecnológica é, portanto, algo que raramente aparece em tabelas de benchmarks: com que rapidez a equipe consegue desenvolver, lançar, aprender e melhorar o produto?
Para muitos aplicativos de desktop modernos, Electron é excepcionalmente bom nisso.
O recurso escasso é o tempo de engenharia
A empresa idealizada de software para desktop nativo tem uma excelente equipe de macOS, outra equipe desenvolvendo o aplicativo para Windows e talvez mais uma dando suporte ao Linux. Cada aplicativo é cuidadosamente otimizado para sua plataforma, e cada engenheiro conhece profundamente o sistema operacional com o qual trabalha.
A maioria das empresas não tem esse luxo.
Um produto para desktop pode ter cinco engenheiros. Pode ter dois. Esses mesmos engenheiros precisam desenvolver recursos, corrigir bugs, melhorar o desempenho, atender aos clientes, manter a infraestrutura, lidar com mudanças nos sistemas operacionais e fazer o produto continuar avançando.
O desenvolvimento nativo torna isso mais difícil porque macOS, Windows e Linux são plataformas realmente diferentes. Elas têm diferentes frameworks de interface, APIs, sistemas de permissões, comportamentos de ciclo de vida, instaladores, mecanismos de atualização, sistemas de notificações, gerenciamento de janelas, APIs de acessibilidade e anos de peculiaridades específicas de cada plataforma.
Electron muda essa equação. Ele combina Chromium, Node.js e APIs de desktop em um modelo de aplicativo compartilhado entre macOS, Windows e Linux. Muitas vezes, o mesmo engenheiro de TypeScript consegue desenvolver um recurso da interface à lógica do aplicativo e lançá-lo em todas as plataformas de desktop. O código nativo continua disponível quando é realmente necessário, mas passa a ser a exceção, e não a base do produto. O próprio Electron descreve isso como uma de suas principais vantagens: uma única base de código JavaScript para as três principais plataformas de desktop.
Essa diferença se acumula ao longo dos anos. Se cada recurso significativo exige implementações separadas para Mac e Windows, a empresa paga repetidamente esse custo por plataforma: a cada recurso, reformulação, experimento, correção de bug, melhoria de acessibilidade e otimização de desempenho.
Com Electron, grande parte desse trabalho é feita uma única vez.
Electron otimiza a velocidade de iteração
Produtos raramente se tornam excelentes porque a primeira implementação foi perfeita. Eles se tornam excelentes por meio da iteração.
Uma equipe lança algo. Os clientes usam. A equipe aprende. Ela modifica o recurso. Mais pessoas usam. Outro problema fica evidente. A equipe melhora o recurso novamente.
Quanto mais curto o ciclo entre ideia, implementação, feedback e melhoria, mais rápido o produto melhora.
Electron é particularmente bom em encurtar esse ciclo porque se baseia em tecnologias que as empresas de software já usam em toda parte: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js e npm.
Isso significa que as empresas podem compartilhar muito mais do que código-fonte. Elas podem compartilhar engenheiros, componentes de interface, ferramentas, bibliotecas, infraestrutura, abordagens de teste e conhecimento institucional entre seus produtos web e desktop.
Um engenheiro de frontend não se torna repentinamente irrelevante porque a empresa precisa de ajuda com o cliente para Windows. Um engenheiro de desktop pode contribuir para o aplicativo web. Um engenheiro full-stack de TypeScript pode transitar entre produtos conforme as prioridades mudam.
Para uma empresa pequena ou média, essa flexibilidade pode valer muito mais do que economizar 100 MB de RAM.
Veja quem realmente usa Electron
Às vezes, Electron é descrito como um atalho para empresas que não querem investir em um aplicativo de desktop “de verdade”. Os produtos desenvolvidos com ele tornam esse argumento cada vez mais difícil de sustentar.
O próprio projeto Electron destaca produtos como Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom e Canva. Não são utilitários simples. Muitos estão entre os aplicativos de produtividade mais sofisticados e amplamente utilizados do mundo.
Visual Studio Code é um exemplo particularmente útil. A Microsoft poderia desenvolver seu principal editor de código com praticamente qualquer tecnologia Windows que quisesse, mas o VS Code usa Electron no Windows, macOS e Linux. Ele inclui terminais, depuração, servidores de linguagem, integração com Git, desenvolvimento remoto, notebooks, extensões e editores altamente personalizados.
A pergunta interessante não é se a Microsoft poderia economizar memória desenvolvendo três versões nativas separadas. Claro que poderia.
A pergunta mais relevante é se o VS Code teria evoluído tão rapidamente, mantido tanta consistência entre plataformas e desenvolvido um ecossistema tão grande se cada funcionalidade importante exigisse várias implementações separadas.
ChatGPT e Claude mostram a diferença de abordagem
O contraste entre ChatGPT e Claude também é instrutivo.
A OpenAI inicialmente desenvolveu um aplicativo nativo dedicado para o ChatGPT no macOS. A Anthropic, por outro lado, desenvolveu o Claude Desktop com Electron e contou, desde o início, com uma base de desktop compartilhada entre plataformas.
Essa diferença se tornou mais importante à medida que os produtos se expandiram. O Claude Desktop pôde continuar adicionando funcionalidades como integrações MCP, extensões e Claude Code ao mesmo aplicativo multiplataforma. A Anthropic agora oferece suporte ao Claude Code diretamente em sua experiência de desktop, incluindo várias sessões locais e remotas.
Mais tarde, a OpenAI também direcionou sua nova estratégia de desktop multiplataforma para Electron, e o Electron agora lista tanto ChatGPT quanto Claude entre os aplicativos de destaque que usam a tecnologia.
Seria exagerado afirmar que Electron, por si só, explica a diferença no ritmo de evolução dos produtos. O tamanho da equipe, as prioridades, a estratégia de produto e a organização interna também importam. Mas a vantagem arquitetural é clara: uma base multiplataforma compartilhada facilita o lançamento de recursos em diferentes sistemas operacionais sem manter implementações separadas.
Esse é exatamente o tipo de vantagem que se torna mais valioso à medida que um produto para desktop cresce.
O Evernote aprendeu o custo de manter clientes separados
O Evernote é um dos exemplos históricos mais claros desse problema.
Durante anos, o Evernote manteve aplicativos diferentes para Mac, Windows, dispositivos móveis e web. Com o tempo, esses produtos acumularam comportamentos diferentes, diferenças de renderização, premissas legadas e problemas de sincronização.
Em 2020, o Evernote reconstruiu seus aplicativos para Windows e Mac em torno de uma base de código compartilhada. A empresa afirmou que a nova base tornaria os aplicativos mais estáveis, permitiria corrigir bugs mais rapidamente, lançar recursos com mais frequência e melhorar a sincronização entre plataformas.
Essa migração não foi indolor, e alguns usuários de longa data não gostaram da perda inicial de recursos específicos de cada plataforma. Mas o motivo que levou o Evernote a realizar uma reescrita tão cara é mais interessante do que os próprios problemas da migração.
Quando um produto tem um editor com recursos avançados, armazenamento offline, busca, anexos, colaboração, tarefas, calendários e sincronização complexa, manter várias implementações independentes se torna cada vez mais caro. Os bugs se comportam de maneiras diferentes. A renderização varia. A lógica de sincronização interage com diferentes arquiteturas locais. Cada mudança significativa no produto precisa se propagar por vários clientes.
Uma arquitetura compartilhada não faz os problemas difíceis desaparecerem. Ela permite que a empresa resolva mais deles uma única vez.
Linux talvez seja a vantagem mais subestimada do Electron
Linux torna os argumentos a favor do Electron ainda mais fortes.
Dar suporte adequado ao Linux é difícil. Ao contrário do macOS ou do Windows, o “desktop Linux” não é uma única plataforma rigidamente controlada. Os desenvolvedores precisam lidar com diferentes distribuições, formatos de pacotes, ambientes de desktop, stacks gráficas, bibliotecas de sistema e protocolos de exibição.
Para muitas empresas de software, a decisão de negócio racional seria simplesmente não oferecer suporte ao Linux.
Electron muda essa relação de custos.
Como Electron fornece um ambiente de execução comum para macOS, Windows e Linux, adicionar suporte ao Linux pode ser drasticamente mais fácil do que manter uma implementação nativa separada para Linux. Esse é um dos motivos pelos quais os usuários de Linux hoje têm acesso a muitos aplicativos de desktop importantes que, historicamente, talvez nunca tivessem recebido um cliente oficial para Linux.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian e muitas outras ferramentas podem oferecer suporte ao Linux sem manter um aplicativo GTK ou Qt inteiramente separado.
Electron também absorve boa parte da complexidade específica do Linux em nome dos desenvolvedores de aplicativos. Um bom exemplo é a mudança do X11 para o Wayland. Os mantenedores do Electron descreveram como a transição do Chromium para o Wayland efetivamente levou os aplicativos Electron junto, reduzindo a quantidade de trabalho relacionado à stack de exibição que cada equipe de aplicativo precisava fazer de forma independente.
Sem frameworks como Electron, muitas empresas não desenvolveriam clientes nativos para Linux. Elas simplesmente dariam suporte ao macOS e ao Windows e deixariam os usuários de Linux com uma aba no navegador.
Electron provavelmente fez mais pelo software comercial para desktop Linux do que se costuma reconhecer.
Até a Microsoft escolhe cada vez mais a tecnologia web
A Microsoft talvez seja o contraexemplo mais forte à ideia de que software sério para Windows deve sempre usar frameworks nativos de interface do Windows.
A Microsoft controla o Windows. Ela controla Win32, .NET, WinUI, WebView2 e boa parte da plataforma sobre a qual os desenvolvedores trabalham. Se o desenvolvimento totalmente nativo para Windows fosse sempre a resposta óbvia, a Microsoft estaria na melhor posição possível para usá-lo em toda parte.
Mas não usa.
Visual Studio Code usa Electron. O Teams continua baseado em React, TypeScript e Chromium, mesmo depois de a Microsoft substituir Electron por um host WebView2 mais otimizado. O novo Outlook para Windows também depende fortemente da tecnologia web, e a Microsoft descreve explicitamente essa arquitetura como uma forma de melhorar a agilidade, permitir a entrega mais rápida de recursos e criar uma experiência mais consistente.
O Teams é especialmente instrutivo. A Microsoft queria melhorar o desempenho e reduzir o consumo de recursos, então mudou a arquitetura. Mas não reescreveu a interface como um aplicativo tradicional nativo do Windows.
Ela manteve a stack web e fez otimizações ao redor dela.
Essa distinção importa. A Microsoft decidiu que valia a pena preservar as vantagens organizacionais de React, TypeScript e Chromium, mesmo enquanto melhorava agressivamente o desempenho.
Há outra lição aqui. A própria Microsoft introduziu muitas gerações de tecnologias para aplicativos Windows ao longo dos anos: Win32, WPF, UWP, WinUI e outras. Uma empresa que escolhe o “Windows nativo” não está necessariamente escolhendo uma plataforma atemporal. Muitas vezes, está apostando em uma geração do framework preferido da Microsoft.
A plataforma web se tornou, de forma um tanto irônica, um dos alvos de desenvolvimento de aplicativos mais estáveis disponíveis.
Contratação faz parte da arquitetura
As escolhas de frameworks também determinam quem você pode contratar.
Desenvolvedores de JavaScript e TypeScript representam um dos maiores grupos de talentos de engenharia do setor. Uma empresa que desenvolve com Electron pode recrutar nesse grupo, em vez de precisar de equipes separadas de especialistas experientes em macOS, Windows e Linux.
Especialistas em desenvolvimento nativo continuam sendo valiosos. Produtos sérios para desktop ainda precisam de engenheiros que conheçam profundamente os sistemas operacionais. Mas Electron muda a quantidade de especialistas de que você precisa.
Em vez de exigir que a maior parte do aplicativo seja desenvolvida por especialistas de plataforma, você pode manter uma quantidade relativamente pequena de código de integração nativa e deixar a maior parte da equipe trabalhar no produto compartilhado.
Isso importa ainda mais quando a empresa já tem um aplicativo web. Às vezes, componentes React podem ser compartilhados. Bibliotecas TypeScript podem ser reutilizadas. A lógica do produto pode transitar entre web e desktop. Engenheiros podem mudar de equipe sem aprender um ecossistema inteiramente diferente.
A contratação também se torna menos frágil. Se o único engenheiro que conhece profundamente seu cliente nativo para Windows sair, substituir esse conhecimento pode ser difícil. Com Electron, uma parcela muito maior da base de código usa tecnologias familiares ao restante da organização.
Portanto, um framework não determina apenas como uma interface é renderizada. Ele afeta como a própria organização de engenharia pode ser estruturada.
Nativo não significa automaticamente software melhor
Desenvolvedores frequentemente usam “nativo” quase como sinônimo de “rápido”.
Não é.
APIs nativas dão aos desenvolvedores a oportunidade de criar um aplicativo muito eficiente. Se o produto final realmente alcançará isso depende da arquitetura, da equipe, do orçamento e da quantidade de trabalho de otimização que a empresa pode bancar.
Um aplicativo nativo ainda pode ser lento, cheio de bugs, consumir muita memória, ser inconsistente ou receber pouca manutenção.
Mais importante ainda, dividir uma equipe limitada entre várias implementações nativas significa que cada implementação recebe menos horas de engenharia.
Imagine que uma empresa tenha seis engenheiros disponíveis para seu produto de desktop. Uma opção é dividi-los entre Mac e Windows, talvez deixando Linux sem suporte. Outra é colocar quase todos os seis engenheiros em um único aplicativo Electron compartilhado que atende às três plataformas.
Qual abordagem dá à empresa mais capacidade de engenharia para melhorar o tempo de inicialização, corrigir vazamentos de memória, refinar interações, melhorar a acessibilidade, reduzir falhas e responder aos usuários?
Não é evidente que os aplicativos nativos resultem no melhor produto.
Isso cria um paradoxo interessante: um framework que consome um pouco mais de recursos da máquina pode permitir que uma empresa desenvolva um produto mais otimizado porque consome muito menos recursos de engenharia.
Electron oferece uma plataforma controlada
Electron também tem outra vantagem que é fácil ignorar: ele inclui o ambiente de execução Chromium para o qual o aplicativo foi desenvolvido e com o qual foi testado.
Isso elimina uma variável importante do desenvolvimento multiplataforma.
Frameworks baseados nas webviews dos sistemas operacionais podem gerar aplicativos menores, mas a contrapartida é que o mesmo frontend pode rodar no WebView2 no Windows, no WKWebView no macOS e no WebKitGTK no Linux. Esses motores têm capacidades, bugs, cronogramas de lançamento e comportamentos de renderização diferentes.
Electron faz uma escolha diferente: incluir o ambiente de execução e torná-lo parte do aplicativo.
Sim, isso consome espaço em disco.
Mas oferece aos desenvolvedores um alvo muito mais consistente em três sistemas operacionais bastante diferentes.
A consistência tem um enorme valor para a engenharia.
Quando Electron não é suficiente, você ainda pode usar código nativo
Escolher Electron não significa abrir mão do acesso a funcionalidades nativas.
Aplicativos Electron podem usar módulos nativos e código específico de plataforma quando necessário. Isso significa que a escolha arquitetural não é realmente:
100% nativo ou 100% JavaScript.
Para muitos produtos, um modelo melhor é:
a maior parte do aplicativo compartilhada, com uma pequena quantidade de código nativo onde o sistema operacional realmente exige.
O código nativo se torna uma válvula de escape, em vez de ser a base de todo o produto.
Essa é uma alocação muito melhor do esforço de engenharia para muitas empresas.
Usuários se importam com produtos, não com frameworks
Existe um pequeno grupo de usuários com conhecimentos técnicos avançados que abrem o Monitor de Atividade, percebem vários processos do Chromium e imediatamente reclamam que um aplicativo usa Electron.
A maioria dos usuários não faz isso.
Eles não se importam que o Slack use Electron. Não se importam que o VS Code seja desenvolvido com tecnologias web. Não sabem qual framework o Claude usa. Eles se importam se o software os ajuda a realizar seu trabalho.
Se um aplicativo inicia rápido o suficiente, responde bem, raramente apresenta falhas e resolve o problema do usuário, a tecnologia de implementação é praticamente invisível.
O inverso também é verdadeiro. Um aplicativo nativo não se torna automaticamente um bom produto porque usa Swift ou WinUI.
A competição entre softwares acontece no nível do produto, não no nível do framework.
Otimize a empresa, não apenas o binário
Electron tem custos reais. Ele usa mais espaço em disco. Seu consumo básico de memória costuma ser maior que o de um pequeno aplicativo nativo. Sem dúvida, existem produtos para os quais esses custos tornam Electron a escolha errada.
Um pequeno utilitário de barra de menus provavelmente não precisa do Chromium. Um driver de dispositivo certamente não precisa. Jogos, softwares profissionais de áudio e aplicativos extremamente sensíveis à latência têm requisitos diferentes. E, se seu produto só vai rodar em um único sistema operacional, o desenvolvimento nativo fica muito mais fácil de justificar.
Mas uma enorme parcela do software de desktop moderno não se enquadra nessas categorias.
Ela consiste em interfaces complexas conectadas a serviços em nuvem. Precisa rodar no Windows e no macOS, e cada vez mais os usuários também esperam suporte ao Linux. Precisa evoluir continuamente. Compete com produtos que lançam mudanças toda semana. E geralmente é desenvolvida por uma empresa com um número limitado de engenheiros.
Para esses produtos, a produtividade dos desenvolvedores faz parte do desempenho do aplicativo.
Electron permite que uma empresa contrate em um grupo muito maior de talentos, compartilhe engenheiros entre web e desktop, mantenha um único aplicativo principal em vez de vários, reutilize o ecossistema JavaScript, lance recursos de forma mais consistente entre sistemas operacionais, ofereça suporte ao Linux a um custo que, de outra forma, muitas vezes seria difícil justificar e dedique mais tempo de engenharia a melhorar o produto em vez de manter implementações paralelas.
É fácil medir o custo do Electron em megabytes.
Os custos das alternativas são mais difíceis de enxergar. Eles aparecem na forma de engenheiros adicionais, implementações duplicadas, ciclos de lançamento mais longos, bugs específicos de plataforma, dificuldades de contratação, silos organizacionais, usuários de Linux sem suporte e recursos que levam meses a mais para chegar a todos.
Esses custos não aparecem no Monitor de Atividade.
Mas, para a empresa que desenvolve o software, eles podem ser consideravelmente maiores.
O objetivo do desenvolvimento de software não é produzir o menor binário.
É desenvolver o melhor produto que sua organização consegue lançar, manter e melhorar continuamente.
Para uma classe surpreendentemente ampla de aplicativos de desktop, Electron continua sendo uma das formas mais eficientes de fazer exatamente isso.