Será que nos perdemos no caminho para um desenvolvimento de software eficiente?

A dificuldade de abrir arquivos do Microsoft Word no Google Docs

• O pai do autor precisou instalar o Word no notebook para trabalhar em um arquivo de documento do Microsoft Word
• O autor sugeriu o Google Docs ao pai
  • porque ele já tinha uma conta Google, é fácil de usar, baseado em nuvem e sincroniza automaticamente
• Porém, ao abrir no Google Docs um arquivo de documento de cerca de 30MB, o Chrome ou o Google Docs não conseguiu lidar bem com isso, chegando a levar vários segundos para exibir na tela o que era digitado
• No fim, foi instalado o LibreOffice, e nele tudo funcionou muito rapidamente

Reflexões sobre os padrões de software de hoje

• Surge a dúvida se o desenvolvimento de software não está regredindo em termos de desempenho
  • se as ferramentas, frameworks e linguagens modernas e sofisticadas não estão nos fazendo regredir em eficiência
• As especificações de hardware estão aumentando para dar conta de webapps e navegadores
  • algo que seria desnecessário se existissem apenas aplicativos nativos puros
  • por que celulares precisam de 8GB ou 16GB de RAM
• A web precisa de renderização nativa, em vez de ser apenas um invólucro sobre um mecanismo de renderização de UI
  • o motivo de não ser possível abrir no Google Docs um arquivo Word de 30MB, mesmo em um notebook potente, é que o navegador exige mais memória e uso de CPU
• Parece que perdemos a forma de desenvolver aplicações otimizadas, eficientes e com bom desempenho. Precisamos resolver esse problema
  • o computador Apollo de 1966, com 2KB de RAM, levou a humanidade à Lua, mas em 2024 não conseguimos lidar com um arquivo de documento de 30MB no navegador
• Hoje o foco está na web, já que toda a indústria parece concentrada em aplicações PWA para o futuro

A importância da otimização de APIs

• Como o desempenho da API pode contribuir para o desempenho do app, a otimização de APIs é importante tanto em apps web quanto nativos
• O produto do autor, Onradar(https://onradar.io), ajuda na otimização por meio de monitoramento de APIs
  • O Onradar oferece monitoramento de uptime e monitoramento baseado em fluxos para APIs
  • No editor de fluxos, é possível criar cenários de usuário com as APIs relacionadas e deixar que o Onradar os teste 24/7
  • Ele fornece alertas quando ocorre um incidente

Opinião do GN⁺

• Problemas de compatibilidade entre Google Docs e MS Office são uma questão apontada há muito tempo. Isso ainda não foi resolvido perfeitamente e continua causando inconvenientes aos usuários. Seria bom que as duas empresas cooperassem de forma mais ativa para resolver isso
• Resolver problemas de desempenho de webapps apenas com o aumento das especificações de hardware não é uma solução fundamental. É necessário desenvolver software que use recursos limitados de forma eficiente
• Defender aplicativos nativos é uma abordagem possível, mas melhorar o desempenho dos webapps preservando as vantagens da web parece um caminho melhor. A portabilidade e a acessibilidade dos webapps são vantagens difíceis de abandonar
• Otimização e monitoramento de APIs são elementos importantes que podem contribuir para melhorar o desempenho de todo o sistema. Especialmente agora que a arquitetura de microsserviços se tornou dominante, a atenção à camada de API tende a crescer ainda mais
• Comparar com a era Apollo não parece muito apropriado. É difícil colocar controle de espaçonaves e processamento de texto no mesmo plano. O software atual se tornou tão vasto e complexo que é difícil esperar a eficiência da era Apollo

[GN⁺]

Comentários do Hacker News

Resumo:

• Apple e Microsoft dificultam o desenvolvimento de aplicativos nativos ao exigir conta de desenvolvedor, compra de certificados para assinar binários, participação na receita etc. A web é uma alternativa muito mais simples e barata.
• Graças à Lei de Moore, o software pegou carona nos avanços do hardware por décadas. Isso foi uma bênção e uma maldição.
• Desenvolvedores gostam de uma plataforma de computação universal, totalmente integrada e conectada, que é a web. Usuários não ligam muito se o desempenho for bom o suficiente. Fazer software bom não importa.
• Decisões de negócio são a principal causa:
  1. Migração para a nuvem - empresas preferem assinaturas recorrentes, e clientes não precisam contratar diretamente uma equipe de TI
  2. Clientes recusam upgrades de software on-premise, o que alonga o ciclo de manutenção e faz os patches continuarem indefinidamente
  3. Desenvolver para a web custa menos do que dar suporte a várias plataformas
• No começo dos anos 90, o MS Word era distribuído em disquetes e o executável tinha 2 MB. Hoje é medido em GB, mas não está claro o que melhorou.
• Existem softwares leves, mas eles não são muito escolhidos. Há ótimos softwares leves como Lua, SQLite, Fennel, Althttpd, Fossil e Mako Server.
• No frontend, há preferência por apps nativos e páginas web, mas webapps como Tiddlywiki também têm suas vantagens. Ainda assim, continuam consumindo mais recursos do que o Emacs.
• Houve um caso em que, numa transição de página em React, a renderização de um menu dropdown demorava muito. No fim, isso foi resolvido alterando o código em React.
• Como as empresas fornecem máquinas potentes aos desenvolvedores, surge o problema de não se testar o suficiente em PCs comuns e antigos.
• Desenvolvedores veem muitos posts de blog como "código idiomático" e "otimização de desempenho é a raiz de todo mal" e passam a dar mais importância ao tempo de desenvolvimento. Antigamente, havia desenvolvedores que escreviam código melhor e mais rápido.