Será que nos perdemos no desenvolvimento de software eficiente?

• Ao tentar editar um documento do Word de cerca de 30 MB no navegador, o atraso na digitação se tornou um exemplo perceptível do custo de desempenho dos apps web modernos
• O documento era composto principalmente por texto, com apenas algumas imagens e tabelas, mas não foi processado com fluidez no Google Docs ou no ambiente do Chrome
• No LibreOffice, instalado em vez do Microsoft Office pago, o mesmo documento funcionou muito mais rapidamente, evidenciando a diferença entre apps web e apps nativos
• À medida que aplicações web modernas exigem mais memória e CPU, isso leva à percepção de que o aumento das especificações de hardware está ligado a apps web intensivos em recursos
• Mesmo com a expansão de PWAs e interfaces baseadas em navegador, a renderização nativa e um design de software eficiente continuam sendo importantes para a usabilidade real

---

Problema de desempenho de apps web revelado por um documento de 30 MB

• O Google Docs foi a primeira escolha por permitir usar uma conta Google e a sincronização automática na nuvem
• Depois de enviar o documento para o Google Docs e tentar digitar, levava alguns segundos para os caracteres aparecerem na tela
• O arquivo tinha cerca de 30 MB e, embora incluísse algumas imagens e tabelas simples, era composto majoritariamente por texto
• A conclusão foi que o Chrome ou o Google Docs não conseguiu lidar adequadamente com esse documento
• O Microsoft Office foi descartado por ser pago e, no LibreOffice instalado em seu lugar, o mesmo documento funcionou muito rapidamente

Uma questão maior sobre eficiência

• Isso leva a refletir se ferramentas, frameworks e linguagens modernos estão tornando o software mais pesado em termos de desempenho
• A visão é que as especificações de hardware aumentaram para dar conta de aplicações web intensivas em recursos, e que essas exigências poderiam ser menores se existissem apenas apps puramente nativos
• Citando como exemplo a situação em que dispositivos móveis precisam de 16 GB de RAM, questiona-se o aumento do uso de recursos pelo software
• A web deveria ter eficiência no nível da renderização nativa, em vez de permanecer apenas como um wrapper de motor de renderização de UI simples
• O contraste entre o computador da Apollo de 1966, que possibilitou o pouso na Lua com 2 KB de RAM, e a dificuldade de trabalhar com um documento de cerca de 30 MB em um navegador em 2024 destaca a necessidade de otimização

[GN⁺]

Opiniões no Hacker News

• Mesmo querendo criar apps nativos, dá a sensação de que a Apple e a Microsoft ficam colocando obstáculos. É preciso aceitar conta de desenvolvedor, certificado de assinatura de binários e até uma taxa de 30% sobre a receita sem grande motivo; especialmente as APIs da Microsoft ficaram confusas
  Por isso acaba-se escolhendo a web, que é mais simples e barata

  • No macOS, o Apple Developer Program só é necessário quando você quer assinatura de binários ou distribuição pela Mac App Store. A Microsoft também só cobra se você publicar na Microsoft Store ou se usar o Visual Studio em uma empresa acima de certo porte
    Apps não assinados ainda podem ser executados no Windows e no macOS, mas aparecem mais avisos. A taxa de 30% também só se aplica ao usar a Mac App Store ou a Microsoft Store; e, pelo que parece, a Microsoft Store não cobra taxa se não for um jogo e você usar seu próprio sistema de pagamento
  • Um dos motivos pelos quais migrei de anos de desenvolvimento em C/C++ para desenvolvimento web em JavaScript foi isso. O processo de colocar um app de iPhone na Apple App Store era um inferno, enquanto apps web não precisam de licenças, aprovações nem instaladores
  • Indo direto ao ponto, no caso da Microsoft, criar uma conta de desenvolvedor, assinar binários e compartilhar 30% da receita não é obrigatório. Também não acho que as APIs da Microsoft sejam uma bagunça; há opções como Win32, .NET e UWP, que funcionam bem e são bastante flexíveis
    Não sei bem quanto à Apple, mas é bem possível que dê para criar apps para Mac sem conta de desenvolvedor; para iPhone, é preciso ter uma. O preço que vi no passado era de US$ 99 por ano, e não é muito dinheiro se você pretende levar a criação de apps a sério
  • Se você integrar pagamentos com cartão diretamente na web, precisa pagar 2,9% + 30¢ ao Stripe. Só ao cobrar 10 dólares a taxa de transação cai para algo em torno de 6%, o que cria um piso de preço e limitações no modelo de cobrança
    Chargebacks e reembolsos também têm custos, e você precisa gastar tempo com suporte ao cliente ou contratar alguém. Se a receita anual for inferior a 1 milhão de dólares, a taxa da Apple é de 15%; então, para apps baratos ou apps de valor agregado, a Apple pode ser um negócio melhor do que processar pagamentos diretamente
  • Ao criar apps nativos para macOS, Windows e Linux, nunca precisei fazer nada disso; simplesmente uso Qt

• É irônico que este texto esteja no Medium, que entrega 10,88 MB para um artigo de 265 palavras

  • Do ponto de vista do Medium, os anúncios são o conteúdo de verdade. O artigo é o meio que transporta até o navegador o conteúdo real, que são os anúncios, e entregar anúncios exige muita complexidade
  • Olhando pelo about:process do Firefox, mesmo 10 minutos depois do carregamento terminar, este artigo ainda estava usando 239 MB de memória e 0,06% a 0,2% de CPU; cerca de 45% do tempo de CPU parece ser gasto pelo Google reCAPTCHA
    Seria bom se organizações como Mozilla ou Google coletassem estatísticas de uso de CPU, memória e energia por domínio e envergonhassem publicamente os desenvolvedores que não se importam com desempenho
  • Os navegadores ficaram maiores que a maioria dos sistemas operacionais, e o ecossistema também parece fechado. O WASM ainda tem muitas limitações, e as opções realmente viáveis no desenvolvimento web são basicamente JS/HTML/CSS
    A web voltou a parecer 2005. Só que, desta vez, os pop-ups estão embutidos dentro da página
  • Nesses casos, abro gemini://gemi.dev/bin/waffle.cgi no navegador Gemini e colo a URL. Quem não usa a rede Gemini pode trocar medium.com por scribe.rip na URL
  • Em navegadores em modo texto, fica tudo bem

• Sim, nos perdemos, e o motivo é simples: porque era possível fazer assim. Era o caminho de menor resistência, então foi o caminho escolhido
  Durante décadas, o software pegou carona de graça na evolução do hardware, especialmente na web e nos apps desktop. A Lei de Moore foi uma bênção e uma maldição, e o software que usamos hoje foi criado por pessoas que aprenderam tecnologia no auge dessa carona grátis

  • É enlouquecedor que o que fazemos no computador seja quase o mesmo a cada ano, mas o software fique cada vez mais pesado. Em 2010, uma distribuição Linux com ambiente desktop carregado usava 100 MB de RAM logo após iniciar; versões otimizadas ficavam em torno de 60 MB
    Hoje, computadores com menos de 8 GB são inutilizáveis, e 8 GB mal dá para usar. Softwares novos usam Electron e consomem no mínimo 1 GB de RAM; tudo, incluindo o navegador, usa uma quantidade absurda de memória
    O Windows é ainda mais incompreensível. Sempre que ajudo no computador da minha mãe, mesmo sendo um PC com i5 recente e 8 GB de RAM, ele é lento demais; inicializar, abrir programas e atualizar demora muito. Se um computador leva mais de um minuto para inicializar, dá vontade de jogá-lo pela janela
  • É verdade. Acho que uma boa parte dos problemas difíceis de software não foi resolvida, foi contornada. Contêineres são um exemplo perfeito disso
    Eles não resolveram a distribuição de aplicações em várias linguagens e ambientes; apenas desviaram do problema com um motor de contêineres. Se o usuário quiser, você pode fornecer um script de build que instale compiladores e ferramentas, mas isso é difícil de testar corretamente, então no fim usa-se contêiner
    Redbean e Cosmopolitan libc pareceram ser o mais próximo de “resolver” esse problema. Se o usuário quer distribuir um app de forma fácil e confiável, contêineres têm vantagem competitiva; e aí imediatamente vêm junto mais de 100 MB em disco e um motor de contêineres
  • Se levar a lógica de “porque dá” até enxames de bots assassinos de IA, vira Slaughterbots
    Enquanto a competição entre países ou empresas for tratada como o princípio central do desenvolvimento tecnológico, será difícil controlar crises globais como mudanças climáticas, destruição de ecossistemas e IA assassina. Precisamos de colaboração e cooperação como princípios organizacionais de mais alto nível; a competição cria enormes externalidades negativas para o planeta inteiro
  • Não concordo. A causa são os recursos de segurança de frameworks e sistemas operacionais, como telemetria, e suas bibliotecas
    Programas escritos em Lazarus, ou seja, Free Pascal, rodam muito rápido mesmo em Windows modernos como o Windows 11. Manter software desktop escrito para um propósito específico é o melhor para velocidade e estabilidade
    Toda modernização do software, tanto de hardware quanto de frameworks, funciona como um imposto cobrado sobre todo o conjunto de funcionalidades existentes
  • Gosto da expressão “caminho de menor resistência”. Parece que, sobre esse caminho, espalharam uma quantidade enorme de desenvolvimento guiado por currículo
    A complexidade se acumulou nos lugares completamente errados

• Esse tipo de reclamação se repete, mas, na prática, é um estado que quase ninguém quer de verdade
  Desenvolvedores gostam da web, uma plataforma de computação universal totalmente integrada e conectada, e usuários parecem não se importar muito com desempenho, desde que seja bom o suficiente. No fim, permite-se que o software fique ruim até o ponto em que não irrite demais os usuários
  A liderança também não tem interesse em criar um software melhor se um software suficientemente bom já foi desenvolvido. Nada muda a menos que alguém decida que é necessária uma ruptura radical, e há pouquíssimos incentivos para mudança de qualquer ponto de vista

  • As pessoas certamente reclamam de desempenho e tamanho de download, mas normalmente expressam isso falando dos efeitos colaterais. Algo como perguntar por que o laptop esquenta ou por que o iPhone dá “travada na tela”
    Pessoas que baixam apps grandes em celulares com sinal fraco, que vivem em regiões com internet instável ou que usam aparelhos antigos por serem de baixa renda ou de países em desenvolvimento ficam frustradas com apps grandes e lentos. Se parece que elas não ligam para desempenho e tamanho de app, talvez você esteja fazendo as perguntas erradas às pessoas erradas
  • O inchaço de software não é um fenômeno novo. Há reclamações pelo menos desde meados dos anos 1990, e quem é mais antigo diria que isso remonta aos anos 1980 ou 1970
    Com o tempo, só quem reclama passa a parecer estranho, e os demais fazem upgrade, aceitam o inchaço ou continuam usando software antigo
    Mas também é preciso olhar para os benefícios que esse inchaço traz. Se o Google Docs fosse apenas uma cópia do Word, não seria muito usado, mas há quem o use por ser gratuito, permitir acesso em vários dispositivos e oferecer colaboração fluida
    Além disso, parte do que parece inchaço é, na verdade, melhoria de conveniência. Recursos como fontes proporcionais que ficam bonitas em qualquer tamanho, fontes Unicode, processamento de documentos maiores que a memória, alternância entre documentos de trabalho e materiais de referência e proteção de memória consomem muitos recursos, mas melhoram a qualidade de vida
  • Fico em dúvida se isso é mesmo verdade. Desenvolvedores web talvez pensem assim, mas eu quase nunca fiz desenvolvimento web diretamente. Interfaces web são uma escolha, e a necessidade comercial de querer receita por assinatura e evitar vendas únicas parece ser um grande motor
    O mundo moderno baseado em nuvem, ou meio online, é bastante artificial do ponto de vista do usuário, e casos como o OpenOffice, que não têm necessidade de monetização, podem continuar como aplicações desktop
  • Uma das startups bem-sucedidas era um app de página única que baixava um bundle de 5 MB e fazia pré-leitura dos dados, e levava quase 10 segundos para iniciar
    Ninguém reclamava disso, e mesmo quando o desempenho de partes do app era péssimo, reclamações de clientes eram raras. As reclamações começavam a aparecer quando o carregamento chegava a algo como 60 segundos
    Ainda assim, aquele software resolvia um problema muito valioso, reduzindo para minutos algo que levava uma semana, então os clientes o elogiavam muito. Com o aumento da concorrência, melhorias passaram a ser necessárias, mas a maioria realmente não se importava, e isso sempre ficava no fim da lista de prioridades
  • O lugar em que essa diferença é sentida com mais força é ao usar software que não caiu nessa armadilha. Sistemas como MYOB EXO/CRM ou SAP ERP mudaram bases de código de décadas de forma muito lenta e, na prática, ainda são tecnologia dos anos 2000; continuam desconfortáveis de usar, mas isso acaba sendo uma grande vantagem
    É divertido abrir o gerenciador de tarefas e ver que, mesmo com boa parte do banco de dados atual carregada, ele usa apenas 20 a 30 MB de RAM. VLC e Blender são exemplos parecidos

• É interessante que a maioria culpe os desenvolvedores, mas, na realidade, tudo isso são decisões de negócio
  A ida para a nuvem acontece porque empresas gostam da receita estável das assinaturas, e clientes corporativos não precisam contratar equipes de TI, além de a responsabilidade passar para fora, permitindo exigir alta disponibilidade. O desempenho só precisa ser “bom o bastante” para o usuário final
  Clientes que se recusavam a atualizar software on-premises geraram ciclos longos de manutenção e patches sem fim, e desenvolver uma vez para a web é mais vantajoso para o negócio do que ter desenvolvedores e testadores separados para cada plataforma. Só a especialização dos desenvolvedores não consegue mudar essas forças fundamentais

  • Depois de certo tempo, aquele software simplesmente funciona bem para o cliente. O Photoshop é um bom exemplo
    Talvez não dê para usar os recursos modernos mais chamativos, mas o CS4 em uma máquina com Win7 ainda funciona sem custo adicional
  • Dá para criar apps web eficientes mesmo sobre a nuvem. No fim, é só um servidor
    O problema está em desenvolvedores criarem em máquinas com desempenho inacessível para os usuários e não se preocuparem com desempenho e código eficiente
  • Acho que muitos desenvolvedores tomariam a mesma decisão. Manter versões separadas do mesmo software para cada plataforma é doloroso, e lidar com servidores consome tempo de desenvolvimento

• No início dos anos 90, lembro que o MS Word cabia em alguns disquetes, e o executável principal tinha 2 MB. Ele rodava bem até em um 386 de 16 MHz com 2 MB de RAM total.
  A maior parte do que fazemos hoje já era feita naquela época; acho que só não havia verificador gramatical. Agora medimos em GB, ficou 1000 vezes maior, e não sei o que ganhamos. Não só nos perdemos no caminho, como também já nem sabemos qual era o destino.

  • O que ganhamos foram recursos e gráficos.
    Por exemplo, só o dict.words do Linux já tem 4,8 MB, e Arial Unicode é uma fonte de cerca de 20 MB. Um único ícone de app em que estou trabalhando tem 400 KB, e o handler do Google Crashpad para tratamento de crashes também tem alguns MB.
    Uma tela 4K true color é 138 vezes maior que uma tela 640x480 de 16 cores.
  • Alguns anos atrás, como pegadinha de 1º de abril, coloquei imagens de disco do DOS/Windows 3.11 em um servidor de boot de rede PXE. Incluía um Word 6 for Windows funcionando, e a imagem comprimida com gzip cabia em 12 MB.
    Os PCs daquela época conseguiam dar boot sem UEFI e, se configurados corretamente, o Windows 3.11 abria quase instantaneamente, e o Word também abria na hora.
    O Word de hoje ganhou um bom número de recursos bem pequenos e alguns recursos grandes, mas tenho certeza de que, se a Microsoft se importasse, poderia reduzir o uso de memória para um décimo. Só que não há incentivo. Os computadores são rápidos, têm muita memória e não dependemos de disquetes; isso só custaria mais.
    Acho que o inchaço do software talvez tenha um impacto ambiental nada desprezível, mas isso não vai mudar a menos que surja uma insatisfação forte o bastante ou algo como uma lei da UE anti-inchaço-de-software.
    Recentemente também vi no GitHub o código-fonte do MS Word for Windows 1.0. A publicação original está no Computer History Museum e pode ser vista em https://computerhistory.org/blog/microsoft-word-for-windows-.... Era C puro, e grandes partes eram em assembly, mas o código era sujo a um ponto incomparável com os padrões, padrões de projeto e recursos de linguagem atuais de C/C++.
  • Tempos atrás, liguei por nostalgia o Word 5.1 em um PowerBook Duo antigo que tinha chegado para descarte.
    Já vi a frase de que software é como gás: ele se expande para preencher o espaço disponível.
    Algo parecido acontece com distribuições live. Antes elas tinham 700 MB para caber em um CD-R; agora ficou difícil achar uma que caiba em um USB de 2 GB. Ainda assim, é bom ver o “minimal” ganhando força.
  • Na empresa, o arquivo Docker que roda código de machine learning tem 6 GiB. E isso nem inclui os arquivos do modelo.
    Nvidia, fico me perguntando o que exatamente vocês estão nos fazendo baixar. Seriam milhares de combinações de código gerado que nunca vamos usar?
  • Os recursos que existiam no Word 6 são, na prática, os mesmos que uso no Word mais recente hoje.
    Só que levo mais tempo para encontrar o que quero no meio de todos os recursos inchados que foram acrescentados.

• Software minimalista existe, mas as pessoas não costumam escolhê-lo. Dá um bom trabalho escolher dependências de forma conservadora, e isso leva a uma stack leve e com bom desempenho.
  Hoje em dia prefiro ferramentas como Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2] e Mako Server[3]. Dá para usar de graça software excelente, leve, estável e eficiente, mas é preciso sair um pouco do caminho mais comum. Não são coisas que se ouvem com frequência no Stack Overflow.
  Quanto ao frontend, tenho um certo conflito. Prefiro apps nativos e páginas web, mas uso Tiddlywiki todos os dias e acho que web apps têm seu lugar. Ainda assim, uma aba com um arquivo Tiddlywiki de 6 MB usa 155 MB de RAM, enquanto uma sessão do Emacs bastante customizada usa só 88 MB, então concordo com a preocupação do autor.
  [0]: https://fennel-lang.org/
  [1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md
  [2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
  [3]: https://makoserver.net/

  • Lua é a ferramenta de programação mais subestimada que conheço. Dominar Lua é uma das melhores formas de elevar sua habilidade de programação.
    Claro que também dá para usá-la mal, mas, em comparação com a maioria das outras linguagens, é quase chocante como programas em Lua podem ser pequenos e eficientes.

• Vejo o problema mais ou menos assim: um executivo da empresa decide que, para manter a competitividade, os desenvolvedores precisam do melhor hardware, e então o desenvolvedor cria um web app em um notebook potente com 128 GB de RAM fornecido pela empresa.
  E não testa em um ambiente como o PC da família de 2010 usado pelo pai, ou não testa com frequência e rigor suficientes para perceber que muita coisa quebra e fica praticamente inutilizável.

  • A conexão de rede é a mesma coisa. A experiência de alguém usando o app no escritório com Wifi 7 e internet de fibra gigabit simétrica inevitavelmente será diferente da de alguém usando o roteador Wi-Fi ruim do condomínio e uma conexão residencial.
  • Isso é fácil de corrigir. Ao desenvolver, configure as ferramentas de desenvolvedor para mobile e conexão limitada.
    Assim, mobile-first responsivo, espaço de tela limitado e problemas potenciais em conexões ruins passam a ser tratados como preocupações de primeira classe.
    Normalmente, quando se avisa o responsável pelo produto sobre o problema, ele simplesmente deixa passar. Então o terceiro item poderia ser corrigido para: “também testamos no PC da família de 2010, mas isso não é uma preocupação para os stakeholders mais importantes”.
  • Parte do meu trabalho atual é testar em hardware antigo ou de baixo desempenho, em navegadores antigos que ainda são usados e, especialmente, em ambientes mobile.
  • Não é uma suposição descabida. Só que o texto em si tratava de um problema imaginário.
  • Relacionado a isso, fico curioso se os engenheiros do Google Android usam de fato celulares Android para testar. Imagino que a maioria seja usuária da Apple.

• Recentemente, migramos uma página antiga de HTML puro com geração no back-end para React, e um dropdown com cerca de mil itens levava alguns segundos para abrir. Antes, a página inteira abria em cerca de 100 ms
  No começo, surgiu a sugestão de mostrar só os primeiros 100 itens e renderizar o restante apenas quando o usuário digitasse três letras. Hoje em dia, a realidade é meio essa mesmo
  Claro que, na prática, corrigimos o código React péssimo e fizemos renderizar instantaneamente

  • Exato. É comum. Enquanto aumentavam os textos sobre desempenho, como tempo até a primeira exibição da tela, o React criou toda uma nova categoria de problemas como esse
  • Dá para usar um framework de renderização no servidor como o Turbo. Experimentei bastante os frameworks do lado do cliente que as pessoas querem hoje em dia, mas, com muitos dados, todos eram lentos; o Turbo foi a única exceção
  • Uma caixa de seleção com milhares de opções parece oferecer uma experiência de usuário péssima
    Se um framework novo expõe o problema de forma tão evidente a ponto de dar a alguém uma justificativa para realmente corrigi-lo, isso até cria mais um motivo para usar esse framework

• Quando se promove textos como “Ruby idiomático” ou “otimização prematura é a raiz de todo mal” e se diz que “tempo de desenvolvimento é mais importante que desempenho”, é isso que acontece
  Antigamente havia desenvolvedores que escreviam código melhor em menos tempo

  • Não concordo. Hoje há muito mais materiais do que no passado que ajudam a escrever código eficiente
    Já vi muito código antigo horrível que não seria criado hoje