Você Não Deveria Começar com um SPA

Artigo original ↗ Discussão no Hacker News ↗

Aplicativos de página única (SPAs) estão sendo reavaliados como a escolha padrão para novos projetos web, com muitos engenheiros argumentando que abordagens modernas renderizadas no servidor (muitas vezes aprimoradas por ferramentas como htmx, Hotwire ou LiveView) agora entregam interatividade comparável com menos complexidade e sobrecarga operacional. Os defensores dos SPAs apontam benefícios para interfaces ricas e de longa duração, comportamento offline ou local-first e APIs compartilhadas entre clientes web e mobile, enquanto os críticos destacam bundles de JavaScript mais pesados, ferramentas frágeis, desempenho mais lento em redes ruins e um acoplamento entre frontend e backend mais forte do que o anunciado. Um tema recorrente é que a arquitetura deve seguir as necessidades do produto e a estrutura da equipe: SPAs podem ser a escolha certa para aplicativos complexos e densos em dados, com sessões profundas de usuários, mas são vistos como exagero para sites mais simples ou equipes pequenas que se beneficiam de UIs fortemente integradas e orientadas pelo servidor.

Quando um SPA Faz Sentido

  • Vários comentaristas argumentam que SPAs se justificam para UIs complexas e altamente interativas (por exemplo, dashboards administrativos ricos, aplicativos com muitos dados, cenários local-first/offline-first).
  • Outros sugerem que SPAs só devem ser escolhidos quando a profundidade da sessão ou o “holotype” do aplicativo mostra que os usuários permanecem e interagem profundamente, não para blogs simples/páginas de marketing.
  • Alguns acreditam que os SPAs ficarão mais simples por meio de ferramentas mais novas (Remix, Livewire, frameworks WASM como Blazor/Leptos).

Acoplamento vs Desacoplamento de Frontend e Backend

  • Uma corrente diz que o verdadeiro desacoplamento é impossível: frontends sempre dependem das estruturas de dados do backend; tentativas de esconder essa fronteira são enganosas.
  • Outra corrente relata sucesso com APIs públicas consumidas tanto pela UI quanto por usuários avançados, projetadas desde o início, com APIs mock permitindo trabalho em paralelo.
  • Há um argumento recorrente de que “backend para frontend” (endpoints por visualização) reintroduz acoplamento apertado mesmo em sistemas nominalmente desacoplados.

Ferramentas, JavaScript e Preocupações com Escala

  • Muitas reclamações se concentram nas ferramentas de SPA: empacotamento, tempos de build, invalidação de cache e bundles enormes que crescem com as funcionalidades e o tamanho da equipe.
  • Alguns argumentam que isso é inerente aos SPAs; outros dizem que ferramentas como esbuild, configurações mais simples ou não usar frameworks pesados atenuam o problema.
  • Debate sobre o próprio JavaScript: alguns o veem como inerentemente bagunçado; outros dizem que “espaguete” tem mais a ver com práticas da equipe do que com a escolha da linguagem.

UX, Desempenho e Condições de Rede

  • Vozes pró-SPA citam navegações subsequentes mais rápidas, menos transferência de dados via JSON, comportamento adaptativo e melhores oportunidades para suporte offline e UI otimista.
  • Críticos respondem que bundles grandes de JS prejudicam o carregamento inicial, especialmente em redes lentas e dispositivos fracos, e que muitos SPAs falham de forma ruim e opaca sob problemas de rede.
  • Divergência sobre se SPAs realmente enviam menos dados do que HTML quando compressão, chrome de layout e overfetching são considerados.

Estrutura Organizacional, Equipes e Cultura

  • Alguns dizem que a arquitetura naturalmente segue o organograma (Lei de Conway); divisões de SPA muitas vezes refletem equipes separadas de frontend/backend.
  • Outros argumentam que escolher a arquitetura com base na estrutura da organização é arriscado; fluxos de trabalho full-stack com UIs renderizadas no servidor e fortemente acopladas podem ser mais produtivos para equipes pequenas.
  • Críticas culturais: os SPAs surgiram em parte porque desenvolvedores de frontend escapavam de frameworks centrados no backend, mas também por seguirem modas e adoção por “cargo cult”.

APIs, Mobile e Abordagens Alternativas

  • Um lado sustenta que apps mobile tornam as APIs obrigatórias de qualquer forma, tornando a reutilização de SPA sensata.
  • Outros respondem que, na prática, mobile e web frequentemente divergem o suficiente para que APIs compartilhadas não tragam muito benefício.
  • Alternativas como htmx, Hotwire/Turbo, LiveView, Livewire e frameworks clássicos (Django/Rails/Laravel) são frequentemente citadas como opções mais simples e produtivas que não são SPA.