Uma Apelação de 2024 por Software Enxuto

Artigo original ↗ Discussão no Hacker News ↗

O software tem se tornado cada vez mais inchado, com até ferramentas simples reunindo enormes árvores de dependências, runtimes pesados como Electron e instaladores na escala de gigabytes, levantando preocupações sobre segurança, desempenho e desperdício. Comentadores contrastam isso com alternativas mais enxutas, antigas e atuais, argumentando que incentivos de mercado, o conjunto de habilidades dos desenvolvedores e as demandas de multiplataforma empurram as equipes para a conveniência em vez da eficiência. As soluções propostas vão de mudança cultural e ferramentas melhores a regulação e APIs abertas, embora muitos duvidem que o inchaço possa ser revertido de forma significativa.

Serviços simples/auto-hospedados vs. serviços amigáveis ao usuário

  • Vários comentários observam que é possível construir ferramentas extremamente enxutas (por exemplo, compartilhamento básico de imagens/trechos via servidor web + SSH/FTP/NFS + pequenos scripts).
  • Outros contrapõem que usuários não técnicos vivem quase inteiramente no navegador; pedir que aprendam FTP/SFTP ou mounts é uma barreira real.
  • Para auto-hospedagem entre família/amigos, alguns argumentam que você pode simplesmente ensinar ou pré-instalar ferramentas como FileZilla, sistemas de arquivos SFTP ou ferramentas de sincronização em vez de criar frontends de upload personalizados.

Exemplo de compartilhamento de imagens, desempenho e privacidade

  • Alguns criticam o app de demonstração do artigo por não redimensionar ou otimizar imagens e por servir miniaturas em tamanho original, chamando isso de “otimizar a coisa errada” (tamanho binário vs. largura de banda).
  • Debate sobre EXIF: um lado diz que não remover metadados é um sério risco de privacidade/segurança em muitos contextos; outros dizem que isso é mais uma questão de responsabilidade do usuário ou pode ser um recurso para compartilhamento privado.
  • Há discordância sobre se isso torna o artigo “hipócrita” ou apenas “inacabado”.

Incentivos e causas do inchaço

  • Vários comentários culpam incentivos organizacionais: lançar rápido rende promoções; engenharia cuidadosa e enxuta parece “improdutiva”.
  • O inchaço também resulta de escolhas de segurança/portabilidade: incluir tudo (drivers, runtimes, mapas de debug) é mais fácil do que reduzir por plataforma.
  • Alguns argumentam que o inchaço é inevitável à medida que as capacidades crescem; outros acham que isso é בעיקר cultura e prioridades dos desenvolvedores.

Electron, stacks web e toolkits de GUI

  • Muitos veem Electron e “web em uma caixa” como emblemáticos do inchaço (downloads enormes, alto uso de RAM/CPU para apps simples).
  • Os defensores observam que o Electron reduz drasticamente o custo de desenvolvimento multiplataforma, aproveita a abundância de desenvolvedores web e acelera a iteração da interface.
  • Alternativas mencionadas: Qt, JavaFX, Avalonia, Tauri, Slint, apps nativos “pesados” como o Telegram. Os trade-offs incluem licenciamento (Qt), maturidade das ferramentas e dificuldade de contratação.
  • Alguns acham que, sem Electron, muitos apps desktop (especialmente no Linux) talvez nem existissem; outros dizem que stacks nativas são perfeitamente viáveis.

Bibliotecas, empacotamento e compartilhadas vs. estáticas

  • Discussão sobre o tamanho do Mesa e onde “traçar a linha” entre complexidade necessária e excesso de envio.
  • Argumentos a favor de bibliotecas compartilhadas (centralizadas, mais enxutas em disco/RAM) vs. binários estáticos (implantação mais simples, menos dependências ocultas).
  • Gerenciadores de pacotes podem esconder a complexidade real: apt install não dá pista se você está puxando um engine de navegador completo ou um binário estático minúsculo.

A qualidade do software está piorando?

  • Um lado diz que apps modernos (especialmente Electron) são claramente piores: ferramentas triviais usando centenas de MB de RAM/CPU e padrões ruins de UX em comparação com UIs nativas antigas.
  • Outro lado diz que o software do passado (por exemplo, desktop dos anos 90) também era notoriamente bugado e inseguro; nostalgia pode ser viés.
  • Uma visão mais nuançada: houve um “período de ouro” (~2003–2013) com toolkits nativos sólidos e melhores práticas de engenharia, seguido por regressão impulsionada por pressões web/mobile multiplataforma.

Exemplos de inchaço vs. enxutez

  • Inchaço relatado:
    • Notion Calendar ~84 MB.
    • Firefox como Snap consumindo centenas de MB por versão.
    • Binário “client” do ClickHouse ~900 MB porque inclui servidor/ferramentas.
    • Instaladores do QGIS para Windows em torno de 1 GB e crescendo.
  • Contraexemplos mais enxutos:
    • Cliente antigo do Ventrilo com poucos MB e RAM mínima.
    • Alguns apps desktop em Qt/JavaFX mantidos abaixo de ~30–140 MB e dezenas de MB de RAM com cuidado.
    • Uma ferramenta reduzida de 33 MB para 1,4 MB ao remover partes desnecessárias (detalhes não totalmente descritos).

Regulação, cadeia de suprimentos e APIs

  • Nova legislação de segurança e obrigações de atualização de longo prazo já estão levando algumas organizações a repensar a proliferação de dependências.
  • Alguns sugerem melhores ferramentas e métodos formais leves para raciocinar sobre enormes grafos de dependências, em vez de esperar que o inchaço desapareça.
  • Outros defendem APIs abertas para que usuários possam escolher clientes alternativos e enxutos em vez de serem forçados a usar os oficiais e inchados.

Sistemas operacionais e modelo de segurança

  • Uma linha de discussão culpa os modelos de segurança dos sistemas operacionais: sistemas antigos (por exemplo, configurações baseadas em disquete) impunham implicitamente fronteiras simples de capacidades, enquanto sistemas modernos permitem código arbitrário com amplo acesso, tornando as enormes árvores de dependências de hoje mais perigosas.