- Alguns desenvolvedores acham que frameworks SPA (React, AngularJS etc.) são indispensáveis para desenvolver aplicações de alta qualidade
- Porém, mesmo antes das SPAs, aplicações baseadas em MPA já entregavam ótimas experiências de usuário
- Tentei desenvolver uma plataforma de observabilidade baseada em MPA e orientada a dados usando HTMX, e com as otimizações certas, até uma MPA com renderização no servidor pode oferecer excelente desempenho e experiência de uso
Equívocos e verdades sobre MPA
Equívoco 1: MPA é lenta nas transições de página
- Problema: por padrão, o navegador baixa novamente JavaScript e CSS a cada transição de página
- Soluções:
- Usar bibliotecas como PJAX, Turbolinks e HTMX Boost para trocar apenas o
body do HTML
- Usar service workers para melhorar o cache de páginas e o tratamento de requisições
- Exemplo: com um service worker aplicado, o tempo de
DOMContentLoaded caiu de 2,9 segundos para 500 ms
Como implementar um service worker
- Criar o arquivo
sw.js: escrever o script de cache e gerenciamento de requisições de rede
- Definir a lista de arquivos em cache: especificar os principais assets como HTML, CSS e JS
- Configurar a estratégia de cache: manter assets estáticos em cache permanente ou atualizá-los periodicamente
Equívoco 2: MPA não consegue funcionar offline nem armazenar requisições para reenviar quando a rede voltar
- Com service workers, o app pode funcionar mesmo em modo offline
- Uso do Workbox:
- Em caso de falha de rede, armazenar requisições em cache e tentar novamente em até 24 horas
- Configurar um handler offline para fornecer conteúdo alternativo durante as requisições
Equívoco 3: MPA causa piscadas na tela durante a troca de páginas
- Soluções:
- Usar service workers e a API de preload para adiar a pintura da tela até que os assets estejam prontos
- Desde 2019, navegadores processam transições dentro do mesmo domínio sem esse efeito de piscada
Equívoco 4: MPA não permite efeitos sofisticados de transição entre páginas
- SPAs ficaram famosas por animações de transição entre páginas, mas os navegadores também começaram a oferecer suporte a isso
- No Chrome 126, já é possível implementar animações de transição entre documentos apenas com CSS
- Link da demo
Equívoco 5: Em HTMX ou MPA, toda ação do usuário precisa ser processada no servidor
- O HTMX foi projetado para que apenas parte das ações seja processada no servidor
- Quando necessário, é possível adicionar interatividade no cliente com WebComponents ou frameworks JavaScript
- Também dá para aplicar a abordagem SPA apenas em componentes específicos
Equívoco 6: Manipular o DOM é lento, então é preciso usar React/Virtual DOM
- O Virtual DOM só mostra diferença de desempenho em aplicações extremamente complexas
- Na maioria das aplicações comuns, a manipulação direta do DOM já é rápida o suficiente
- Referência: "Virtual DOM is pure Overhead"
Equívoco 7: Até pequenas funcionalidades interativas precisam de JavaScript
- Com tecnologias modernas de navegador, já dá para implementar vários recursos sem JavaScript
- Dá para criar alternância com checkbox HTML e CSS
- Combinando com HTMX, também é possível carregar dados de forma assíncrona ao clicar
Equívoco final: Sem SPA, o código do cliente inevitavelmente vira spaghetti code
- Mesmo na era do spaghetti code, muito software produtivo foi desenvolvido
- Em fases iniciais de MVP, uma estrutura simples pode ser até mais vantajosa
Conclusão
- Em 2024, os navegadores evoluíram bastante ao incorporar o que aprenderam com a revolução das SPAs
- Só com as ferramentas nativas do navegador (HTML, CSS e JavaScript), já é possível criar aplicações interativas e que funcionam offline
- Vale a pena confiar no potencial do navegador e voltar a explorá-lo
8 comentários
Se você já tentou desenvolver com um grupo de desenvolvedores mais ou menos medianos, percebe na hora o quanto isso é uma visão fantasiosa. Quem escreveu isso ou está cercado de gênios, ou trabalha sozinho... (dá para ver isso só pelo fato de mencionar AngularJS, que já passou da época). E desenvolvimento não é feito só por gênios.
Alguém pode menosprezar isso dizendo que é "panelinha", mas mudanças sempre foram feitas por pessoas comuns.
Quando vejo esse tipo de coisa, a primeira coisa que penso é que o htmx nunca deveria ser adotado.
Embora seja um tema que vem aparecendo repetidamente ultimamente,
existe um vídeo em que Rich Harris expõe sua opinião sobre esse assunto há alguns anos.
https://www.youtube.com/watch?v=860d8usGC0o&t=635s
Se bem me lembro, dá para resumir assim: abordagens que fazem atualizações com base em HTML parcial podem acabar gerando inconsistências entre a interface e os dados.
Você ainda acredita nas especificações do navegador...?
Dito de forma bem direta, acho que SPA é um método de desenvolvimento de aplicações que tem um pouco menos de dependência do comportamento do navegador.
É verdade que os navegadores acompanharam bastante as possibilidades interessantes das SPAs, e que isso parece combinar mais com a forma de comunicação para a qual o HTTP foi originalmente projetado, mas talvez isso só tenha sido possível porque o Chrome passou a ter uma posição praticamente monopolista no mundo dos navegadores e, com isso, ganhou folga... Não sei se isso vai durar muito tempo. Seja a folga, seja a participação de mercado...
Se for algo como o
phoenix liveview, baseado em websocket e com manipulação do DOM no servidor, aí o paradigma é diferente.Quando usei
htmx, essa necessidade de o servidor ter que entregar fragmentos de HTML não me pareceu muito agradável.Principalmente na parte de CSS: se você entrega isso já com
classdefinida, do ponto de vista do servidor não tem como saber qual CSS está sendo usado na tela, então na prática passa uma sensação de estar impondo um CSS comum.Alguns anos atrás, cheguei a tentar criar uma UI um pouco complexa com Phoenix LiveView, mas era muito complicado implementar interações simples e, como cada LiveView é processado por um processo Elixir, a interação com componentes ao lado fica muito difícil. No fim, acabei desistindo e voltando para React.
Para mim, o LiveView parece ser o futuro…
Como o liveview também depende bastante da rede, quando o servidor está remoto e a latência é alta, ou em regiões como países de terceiro mundo onde a infraestrutura de internet não é boa, isso acaba sendo uma grande fraqueza.
Comentários do Hacker News
Há curiosidade sobre por que o artigo não mencionou como usar o cache do navegador para gerenciar ativos estáticos de CSS e JS. No passado, ao construir um site de compras no modelo MPA, as transições de página quase não eram perceptíveis
Há quem afirme que o desenvolvimento web na época de PHP e jQuery era o mais produtivo. Existe a opinião de que o paradigma do passado poderia ser mais produtivo do que tecnologias modernas como React. Grandes sites como Amazon ou Steam ainda são feitos renderizando HTML no servidor e adicionando JS
Há comentários pedindo uma explicação de em que a estratégia de service worker é melhor do que os cabeçalhos tradicionais de cache HTTP. Ela pode reduzir as idas e voltas de rede, mas dá a sensação de reinventar tudo por uma pequena otimização
O significado do título "You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths" parece caça-cliques por causa da parte omitida
A coisa mais perigosa na programação é o tédio dos desenvolvedores e a ignorância sobre o passado
Há quem diga não entender por que existe essa dicotomia entre lado do servidor e lado do cliente (SPA) na era dos servidores web com Node.js. Fica a pergunta se não seria possível inicializar a maior parte do trabalho no servidor, serializar para o cliente e fazê-lo funcionar como SPA
Existe uma tendência de ver SPA e MPA como times opostos, mas isso pode ser separado entre usar a stack web de forma natural e de forma "hackeada". SPA atualmente é uma forma hackeada, mas no passado houve CGI, applets Java e Flash. As formas hackeadas servem para expandir os limites do método natural
Antes de decidir a stack tecnológica, muitas vezes os desenvolvedores entendem mal o que estão escrevendo. Se não for necessário um alto nível de interatividade, na maioria dos casos um framework server-side pode ser suficiente
Há uma refutação ao mito de que "não é possível criar aplicativos web interativos sem que sejam single-page apps". SPA oferece mais controle e reduz a chance de retrabalhar partes do código
A manchete do HN é mais agressiva do que a manchete real. Trata-se de um ensaio apresentado por Tony Alaribe na BigSkyDevCon, discutindo técnicas para tornar aplicações web não baseadas em SPA rápidas e fluidas. Apresenta novas técnicas e houve quem considerasse a melhor palestra da conferência