Guias

«SPA vs PWA» é uma das confusões mais comuns no desenvolvimento front-end, e a razão é simples: os dois termos não são de todo opostos. Uma single-page application (SPA) descreve como uma aplicação é construída e navega, ao passo que uma progressive web app (PWA) descreve o que uma aplicação pode fazer pelo utilizador. Colocá-las frente a frente é um pouco como perguntar «carro manual ou elétrico»: estás a comparar dois eixos diferentes, e uma aplicação pode perfeitamente ser ambas, apenas uma, ou nenhuma.

O que é uma SPA

Uma single-page application carrega um único documento HTML e depois reescreve a página no navegador à medida que navegas, em vez de ir buscar uma página nova ao servidor a cada clique. Após o primeiro carregamento, o JavaScript substitui as partes relevantes da interface e traz apenas os dados de que precisa, normalmente como JSON a partir de uma API. O resultado aproxima-se de uma aplicação de desktop ou móvel, com transições instantâneas e sem recarregamentos completos da página. React, Vue, Svelte e Angular existem em grande parte para tornar este modelo praticável.

O que é uma PWA

Uma progressive web app é uma ideia completamente diferente: é um site que usa os padrões web modernos para se comportar mais como uma aplicação instalada. Os três pilares são um manifest de aplicação web (para poder ser adicionada ao ecrã inicial com um ícone e um nome), um service worker (um script capaz de colocar recursos em cache e servi-los offline) e HTTPS (necessário para essas capacidades). Uma PWA pode enviar notificações push, funcionar sem ligação e abrir na sua própria janela, tudo a partir de um URL normal, sem loja de aplicações.

• SPA = arquitetura (navegação no cliente, sem recarregamentos)
• PWA = capacidades (instalável, offline, push)
• Uma PWA é muitas vezes uma SPA — mas nenhuma exige a outra
• O SSR é um eixo à parte (renderização, não tipo de aplicação)
• Escolhe consoante o que o produto precisa e depois acrescenta funcionalidades

Porque não são opostos

Este é o cerne da confusão que vale a pena esclarecer: as duas não são mutuamente exclusivas. Uma PWA é muitas vezes construída como uma SPA, mas não tem de o ser: podes adicionar um manifest e um service worker a um site multipágina tradicional e torná-lo uma PWA. Da mesma forma, muitas SPA não são PWA de todo, porque nunca acrescentam suporte offline nem instalabilidade. A SPA é sobre a arquitetura de navegação; a PWA é sobre a entrega e as capacidades acrescentadas por cima.

Os compromissos de uma SPA

Visto isoladamente, o modelo SPA dá-te interatividade fluida a um certo custo. Depois de o bundle carregar, as interações são rápidas porque a aplicação pede dados em vez de documentos inteiros. Mas o primeiro carregamento é mais pesado — o navegador tem de descarregar e executar JavaScript antes de mostrar conteúdo útil — e os motores de busca podem ver apenas uma casca vazia, a menos que faças renderização no servidor. As SPA destacam-se em painéis, editores e produtos do tipo aplicação, e menos em sites de conteúdo simples.

Os compromissos de uma PWA

As capacidades de uma PWA resolvem um problema diferente: o reengajamento e a resiliência. O suporte offline significa que a aplicação continua a funcionar numa ligação instável de comboio; a instalabilidade coloca um ícone no ecrã inicial e remove a moldura do navegador; as notificações push trazem os utilizadores de volta. As contrapartidas também são reais: os service workers acrescentam uma complexidade de cache que pode servir conteúdo desatualizado se for mal gerida, e o suporte da Apple no iOS, embora muito melhorado, ainda fica atrás do Android em alguns pontos.

Onde entra o SSR

Um terceiro termo costuma irromper nesta comparação: o SSR, ou renderização no servidor. Vale a pena separá-lo, porque é mais um eixo — uma estratégia de renderização, não um tipo de aplicação. Os meta-frameworks como o Nuxt e o Next.js renderizam a primeira página no servidor para que utilizadores e motores de busca obtenham conteúdo real de imediato, e depois hidratam-na numa SPA no navegador. Podes combinar SSR com uma SPA, e uma PWA também pode usar SSR; nenhum destes rótulos exclui os outros.

Como escolher

Então, como escolher na prática? Parte daquilo de que o produto precisa, não da sigla. Se for muito interativo e se comportar como software, a arquitetura SPA encaixa. Se os utilizadores beneficiarem de acesso offline, instalabilidade ou notificações push, acrescenta as capacidades PWA por cima: é incremental por conceção, que é precisamente o que «progressive» significa. Se o site for sobretudo conteúdo e o SEO for o mais importante, apoia-te na renderização no servidor ou até numa abordagem multipágina tradicional, e acrescenta funcionalidades PWA apenas onde realmente compensem.

A conclusão

A conclusão honesta é que «SPA vs PWA» é o enquadramento errado. São camadas complementares: uma decide como a tua aplicação navega, a outra decide o que ela pode fazer assim que está lá. As aplicações web modernas mais sólidas combinam frequentemente as três ideias — uma SPA para a interatividade, a renderização no servidor para um primeiro desenho rápido e para o SEO, e as funcionalidades PWA para o modo offline e a instalabilidade — escolhidas de forma deliberada em vez de tratadas como campos rivais.