Coisas em que engenheiros acreditam sobre desenvolvimento Web

Artigo original ↗ Discussão no Hacker News ↗

Engenheiros debatem mitos comuns sobre o desenvolvimento web moderno, desde se os navegadores realmente são bons em lidar com UIs dinâmicas complexas até quando frameworks de single-page app se justificam em vez de sites multipágina mais simples, renderizados no servidor. Muitos argumentam que stacks pesadas de JavaScript, etapas de build e arquiteturas SPA são superutilizadas em sites básicos de CRUD e conteúdo, criando custos de desempenho, acessibilidade e manutenção que superam os ganhos de UX, enquanto outros contrapõem que ferramentas front-end reativas se tornam mais produtivas à medida que a interatividade cresce. Por trás disso há uma tensão mais ampla entre “a ferramenta mais simples que funciona” versus “a stack mais flexível/moderna”, moldada pela familiaridade dos desenvolvedores, incentivos de contratação e pela divisão entre expectativas de aplicativos ao estilo desktop (por exemplo, Figma, Photoshop) e o modelo original centrado em documentos da web.

Desempenho de renderização do navegador e alternativas

  • Alguns discordam de que os navegadores sejam “bons” em árvores DOM complexas e de longa duração; outros argumentam que décadas de otimização os tornam difíceis de superar para árvores dinâmicas.
  • Alternativas citadas: WPF (Windows) e Avalonia (multiplataforma) com data binding/templates embutidos; motores de jogos e renderizadores WebGL/canvas que lidam facilmente com milhares de objetos animados.
  • Exemplos: Figma, Google Docs/Sheets e Photoshop na web contornam grande parte do DOM usando WebGL/canvas/WASM, visto por alguns como evidência de que o DOM é um encaixe ruim para UIs complexas.

JavaScript, degradação graciosa e acessibilidade

  • Uma minoria vocal defende sites que funcionem sem JS, especialmente conteúdo e apps CRUD simples, por robustez, testes e acessibilidade.
  • Outros veem usuários com JS desligado como negligenciáveis e argumentam que a realidade de negócios não justifica projetar para eles.
  • Contra-argumentos: redes instáveis podem “desativar” o JS na prática, microbrowsers/crawlers não executam JS completo, e SPAs pesadas degradam a UX em dispositivos de baixo custo ou móveis.

SPA vs MPA, espectro de interatividade e escolha de ferramentas

  • Grande tema: Figma/Photoshop são usados em excesso como justificativa para stacks SPA em apps majoritariamente CRUD.
  • Um lado: prefira JS mínimo, MPAs renderizadas no servidor para apps mais simples; a complexidade deve ficar no backend; SPAs são um “motte-and-bailey” (claramente certas para editores ricos, frágeis para a maioria dos apps).
  • Outro lado: SPAs (React/Preact/Vue etc.) parecem arquiteturalmente mais simples para interações ricas, acumulam benefícios conforme as funcionalidades crescem e oferecem UIs mais suaves (por exemplo, filtros facetados, mapas).
  • Muitos apontam padrões intermediários: aprimoramento progressivo, atualizações parciais de HTML (semelhantes a Turbolinks/Hotwire), server components, islands/SSR e incorporação de widgets SPA isolados em MPAs.
  • Trade-offs de UX: SPAs podem parecer mais rápidas e fluidas, mas frequentemente lidam mal com o histórico, falham sob conectividade intermitente e enviam bundles grandes de JS; MPAs podem piscar e parecer “abruptas” sem otimização.

Etapas de build, ferramentas e DX

  • Alguns argumentam que “a web não deveria precisar de uma etapa de build”; pipelines de build adicionam latência, complexidade e quebras frequentes ao retornar a projetos antigos.
  • Outros defendem etapas de build por tree-shaking, bundling, HMR e tipagem estática via TS/Rust/WASM, observando ao mesmo tempo que as ferramentas de build de JS são incomumente frágeis e mudam rapidamente.
  • Alternativas mencionadas: includes simples no lado do servidor, static site generators ou incorporar UIs administrativas diretamente em serviços backend em vez de frontends Node separados.

Apps desktop vs web e sandboxing

  • Um lado prefere apps pesados como software desktop nativo, vendo o navegador como um visualizador de documentos.
  • Outros preferem fortemente executar esses apps no navegador por sandboxing e desmontagem mais fácil, citando clientes nativos invasivos (por exemplo, processos em segundo plano sempre ativos).
  • Um longo subthread debate se navegadores são “mais seguros” do que apps nativos ou mobile, versus apenas outra camada de sandbox (muito complexa); surgem preocupações sobre o monocultivo do Chromium versus os duopólios de app stores.

Outros temas recorrentes

  • Tensão frequente entre “a ferramenta mais simples que funciona agora” vs “a ferramenta flexível que pode cobrir necessidades futuras”.
  • Reclamações sobre escolhas de tecnologia movidas por currículo e por moda.
  • Observações de que as especificações do navegador e as equipes de engine muitas vezes carecem de perspectiva prática do dia a dia do desenvolvimento web; por outro lado, muitos web devs entendem mal as restrições das engines.