- Electron é um framework para criar aplicativos desktop baseados em HTML·CSS·JS com suporte simultâneo a Windows, Mac e Linux, e é usado por vários apps como Slack, Discord e VS Code
- No entanto, como cada app inclui o mecanismo Chromium separadamente, o tamanho fica grande, surgem problemas de lentidão e falta de resposta, e a integração com recursos do sistema operacional também é limitada
- Com o surgimento dos agentes de programação, capazes de gerar código nativo por plataforma com base em especificações e testes, pode parecer que as vantagens do Electron estão diminuindo
- Mas, na prática, os agentes conseguem automatizar apenas até 90% do desenvolvimento, e os 10% finais de tratamento de exceções e manutenção ainda continuam difíceis e dependentes de pessoas
- Por isso, mesmo com o avanço da tecnologia de agentes, ainda existem motivos práticos para usar Electron, como no caso do app Claude da Anthropic
Vantagens e limites do Electron
- O Electron permite criar aplicativos desktop multiplataforma com tecnologias web
- Uma única base de código atende Windows, Mac e Linux
- Como é possível reutilizar o código de webapps existentes, a eficiência de desenvolvimento é alta
- Entre as desvantagens estão o aumento do tamanho do app e a queda de desempenho
- Cada app inclui seu próprio mecanismo Chromium, chegando à casa de centenas de MB
- Surgem problemas como menor velocidade de resposta e integração insuficiente com recursos do sistema operacional
- Alguns problemas podem ser melhorados com otimizações específicas para cada sistema, mas a vantagem estrutural do Electron não incentiva isso de forma ativa
A chegada dos agentes de programação e as expectativas
- Recentemente, os agentes de programação passaram a mostrar capacidade de automatizar implementações entre linguagens e plataformas com base em especificações (spec) e testes
- Em teoria, seria possível gerar apps nativos de cada plataforma a partir de uma única especificação e de um conjunto de testes
- Isso sugere a possibilidade de times pequenos e focados oferecerem apps nativos de alto desempenho para um mercado amplo
O caso de Claude e da Anthropic
- A Anthropic implementou com um agente de programação um compilador C baseado em Rust, mas esbarrou em limites na etapa final
- Ao adicionar novos recursos ou corrigir bugs, problemas de quebra de funcionalidades existentes se repetiam
- O resultado foi impressionante, mas avaliado como inadequado para uso real
- O app desktop do Claude também foi feito com base em Electron e é citado como um app lento, cheio de bugs e grande em tamanho
A dificuldade dos ‘10% finais’
- Os agentes de programação processam rapidamente os 90% iniciais do desenvolvimento, mas
o tratamento de exceções e a manutenção em ambientes reais continuam complexos e exigem intervenção humana
- Em ambientes reais de usuários, cenários inesperados se acumulam e o desenvolvimento nunca termina
- Se forem criados apps separados para cada plataforma, bugs e escopo de suporte se ampliam em 3 vezes, aumentando a carga de manutenção
- O Electron ameniza esse problema em certa medida por meio de um wrapper comum
Por que continuar usando Electron
- Mesmo que o desenvolvimento baseado em especificações seja possível, o custo dos 10% finais do desenvolvimento e o peso da manutenção continuam existindo
- Apesar do avanço da tecnologia de agentes, a vantagem prática de uma base de código única no Electron continua válida
- No momento atual, o Electron ainda é avaliado como uma escolha racional
- Os agentes de programação mostram avanços impressionantes, mas ainda são insuficientes como substituto completo
1 comentários
Comentários do Hacker News
Sou Boris, da equipe do Claude Code
Havia engenheiros que antes trabalhavam no Electron, então havia uma preferência por construir de uma forma que não fosse nativa
Isso permite compartilhamento de código entre web e desktop, mantendo a mesma UI/UX
Claro, tudo envolve trade-offs, então isso pode mudar no futuro
Parece que isso poderia ser resolvido com otimização de performance sem trocar a stack. O mesmo vale para apps mobile
Fica a lição de que é importante olhar para as ações, não as palavras
E brincaram que então bastaria pedir ao Claude: “faz isso sem ficar ruim”
os agentes de IA conseguiriam manter isso só com especificações e testes?
Especialmente considerando os limites de modelos como o Opus 4.6, fico curioso com o resultado
É bem claro por que código não é de graça
Nossa equipe também usou bastante o Claude por 6 meses, mas a taxa de bugs continua aí
IA não é solução mágica
Se você terceiriza o raciocínio para a IA, perde o mapa mental do sistema
Mesmo assim, já tem gente perguntando “por que não reescrever tudo com IA?”, o que é engraçado
Veja o link do Imgur
Agentes de coding com IA ainda não chegaram totalmente a esse nível, mas é preciso tomar cuidado com erros mais rápidos
O navegador da OpenAI também já tem 4 meses desde o lançamento, mas ainda é só para macOS
Mesmo já rodando sobre um engine cross-platform, é estranho que a expansão seja tão lenta
A expressão “Free as in puppy” foi bem espirituosa
Disseram que o título original começava com “If code is free,”
Este texto e a thread como um todo parecem um padrão típico de debate estilo HN
É a repetição de enquadramentos como “IA ruim”, “JavaScript ruim”, “Electron ruim”
Na prática, o Electron é quase uma ‘quarta plataforma de SO’, e muitos desenvolvedores não entendem isso
Os apps de hoje parecem sites remendados, com inconsistências de estilo e muitos bugs
É muito mais prazeroso fazer um app nativo para Mac
O Electron tem vantagens, mas quase não há otimização por SO
Também existe muita UI nativa ruim, e no fim tudo depende de como as pessoas escrevem o código
Se o Claude oferece uma ferramenta CLI, então escolher Electron é razoável
Reconheci as vantagens do Electron e expliquei por que ele foi escolhido
Só acho interessante o fato de que até num Mac Studio com 64 GB de RAM ele é lento
Incluir até dependências do npm por padrão parece uma falta de orgulho técnico
Isso não combina com o slogan de “contratar os melhores talentos”
Eu gosto de JavaScript, mas o uso de RAM é absurdo
A Anthropic nunca disse que “código é de graça”
Eles enfatizaram ganhos de produtividade, e de fato escrevem a maior parte do código com LLMs
Se for criticar, é melhor apontar problemas reais em vez de um espantalho
por que o resultado não é melhor?”
Veja a entrevista na Lenny’s Newsletter
Este texto parece mirar nesse grupo
Sou Felix. Cuido dos apps Electron do Claude Code Desktop e do Claude Cowork
Nossos apps também incluem bastante código em Rust, Swift e Go
Escrevemos em detalhes sobre por que usamos Electron e por que distribuímos nosso próprio engine na
documentação oficial
Electron é apenas uma ferramenta, e podemos usar outra coisa se for necessário
O CEO disse que “codificação é quase um problema resolvido”, então eu gostaria de perguntar por que o resultado é esse
Tive problemas com o login do Claude
O navegador entrou num estado de carregamento infinito, e ao clicar em login eu era levado para cadastro
É decepcionante ver uma função tão básica instável para algo vendido como “o futuro da codificação”
Código nunca é de graça
No fim, você sempre paga o custo de algum jeito
Mesmo que a IA escreva todo o código, ainda é preciso alguém que entenda aquilo
Saber ler manual é uma força dos hackers,
e uma empresa que não conhece o funcionamento do próprio produto é arriscada
Acho que o fato de o Claude usar Electron não é uma questão técnica, e sim cultural
Para uma startup, Electron é uma escolha razoável, mas
para uma empresa grande, o certo seria investir em qualidade de app nativo e UX
Mesmo com coding automatizado possível, ainda assim não fazem isso
porque a cultura de desenvolvimento de hoje perdeu a vontade de criar o melhor software possível