--- title: "A ditadura do Chromium e os navegadores ocultos no seu PC" author: "Ricardo Pupo Larguesa" date: "2026-04-18 14:11:00-03" category: "Opinião" url: "http://aintuicao.scale.press/portal/aintuicao/post/2026/04/18/a-ditadura-do-chromium-e-os-navegadores-ocultos-no-seu-pc/md" --- Fui surpreendido hoje (ou talvez nem tanto) com a notícia de que o OpenCode abandonou o Tauri e reescreveu toda a sua interface desktop em Electron. Isso não é apenas uma mudança de repositório, é o sintoma mais claro do aumento desenfreado de entropia em que a arquitetura desktop se meteu. A justificativa é sempre a inconsistência de renderização entre plataformas. O Tauri é "menos feio" na teoria: para economizar memória, ele não embute um navegador inteiro, mas "pega carona" no WebView nativo que já existe no seu sistema (WebKit no Mac, Edge no Windows). Na prática, isso significa que o app pode se comportar de um jeito no macOS e de outro no Windows, forçando o desenvolvedor a gastar um tempo precioso garantindo que o CSS e o JavaScript funcionem igualmente em motores diferentes. A saída mais fácil? O Electron. Ele empacota um Chromium inteiro junto com a porcaria do Node JS para dentro do seu app, uniformizando tudo. O resultado é estabilidade, mas a um preço caríssimo para o seu hardware. Como professor, sempre provoquei meus alunos com isso o tempo todo. O mercado atual nos colocou em um labirinto onde todas as saídas cobram um pedágio pesado: - **Electron**: Traz o conforto de programar a interface usando apenas JavaScript/TypeScript e tecnologias web. No entanto, a aplicação consome facilmente mais de 200MB de RAM apenas em repouso e gera binários inchados de 80MB para cima. - **Tauri**: Cai para cerca de 30MB de consumo de memória e binários minúsculos, mas traz o ônus da fragmentação visual e exige pontes complexas de comunicação via mensagens assíncronas com o backend em Rust. - **Flutter Desktop**: Abandona o navegador e desenha a própria interface via Skia, o que o torna incrivelmente fluido e idêntico em qualquer tela. O grande defeito é que ele não usa a estrutura do sistema operacional e precisa "emular" a árvore de acessibilidade para leitores de tela de forma artificial. No fim das contas, a indústria abraçou a "arquitetura da redundância" por uma razão puramente financeira. O Time-to-Market venceu a engenharia de software. As empresas descobriram que é muito mais barato consumir a memória RAM do usuário (afinal, o hardware quem paga é você) do que pagar pelo tempo de engenheiros especializados escrevendo código nativo de baixo nível. O conforto do desenvolvedor foi priorizado, e tanto o Electron quanto o Tauri são, na sua essência, abordagens péssimas por transferirem o desperdício de recursos para o cliente final. Embora a um custo maior de projeto e desenvolvimento, o ecossistema atual até oferece melhores rotas de fuga para quem se recusa a aceitar essa imposição do mercado. Se quisermos fugir da abstração web pesada, podemos optar pelo egui em Rust, que delega o desenho da interface direto para a GPU usando tecnologias como WGPU, derrubando o consumo de memória em repouso para a faixa de 15 a 40 MB e gerando executáveis enxutos de 1 a 5 MB. Para os puristas que buscam um controle ainda mais cirúrgico, o Zig integrado a motores de baixo nível como o Mach, ou o próprio C++ puro rodando com bibliotecas diretas como SDL ou GLFW, representam o ápice da eficiência. Nessas arquiteturas, por não haver o peso de runtimes, navegadores embutidos ou máquinas virtuais, o consumo despenca para assombrosos 2 a 10 MB de RAM com binários que mal chegam a 1 MB. Mesmo se a equipe exigir o conforto de componentes visuais maduros e prontos, o uso do tradicional Qt com C++ entrega altíssima performance consumindo entre 10 e 20 MB de memória. Quando colocamos essas tecnologias lado a lado com os 200 MB exigidos pelo Electron, fica claro que optar por linguagens compiladas nativamente pode representar uma economia real de mais de 90% dos recursos da máquina. Mas, como eu, disse, a um custo muito mais alto de projeto e desenvolvimento. Só que nós mudamos de era. Com a revolução da Inteligência Artificial e dos fluxos autônomos baseados em LLMs, dinâmicas que desmonto em detalhes no meu livro Engenharia de Prompt para Devs, a escrita de códigos mais densos deixou de ser o pesadelo de antes. Hoje, usando agentes integrados à stack, a desculpa de que linguagens de baixo nível demoram demais para serem construídas caiu por terra. Ficou plenamente viável utilizar abordagens que antes considerávamos complexas para obter melhorias dramáticas na economia computacional. Atualmente, quando estamos rodando modelos localmente, cada ciclo de CPU e cada megabyte importam. Não há lógica nenhuma em gastar recursos rodando cinco instâncias diferentes de um navegador mascarado só para manter ferramentas básicas do dia a dia abertas. A grande e incômoda verdade é que, olhando pelo prisma da real eficiência de máquina, nós jamais deveríamos ter saído do C++. Frameworks e bibliotecas em C++ operam no "chão" do sistema operacional, sem o intermédio de máquinas virtuais ou interpretadores, entregando poder total consumindo na casa dos 10 a 20 MB. Agora que a IA pode assumir o trabalho pesado e o boilerplate que tanto afastava os times dessa linguagem de baixo nível, chegou a hora de pararmos de tratar o hardware moderno como lixo e voltarmos a fazer engenharia de verdade.