O futuro (e o passado) do desenvolvimento web é renderizar do lado do servidor

No passado era muito comum as páginas web servirem apenas conteúdo estático, acessar uma página com uma imagem, era RARO! 

Hoje as páginas dos sites são dinâmicas e completas. Elas conseguem buscar os dados em múltiplas fontes, tratar e renderizar em tempo real informações simultâneas. Isso é realmente impressionante, mas tem um custo alto agregado. 

Largura de banda e velocidade aumentaram significativamente! Nos últimos 10 anos, o tamanho máximo de uma página na web passou de 468 KB para 2284 KB, um aumento de 388,3%. Para dispositivos móveis, esse salto é ainda mais impressionate - 145 KB para 2010 KB - um aumento de 1288,1%.

É muito pesado para ser enviado na rede, especialmente para dispositivos móveis. Como resultado, os usuários experimentam UX terríveis, tempos de carregamento lento e falta de iteratividade até que tudo seja renderizado. Mas todo esse código é necessário para os sites funcionarem corretamente. 

Esse é um dos problemas que os desenvolvedores frontend enfrentam hoje. O que começou divertido, hoje se tornou terrível!

Como fazer a coisa voltar aos eixos? Voltando aos servidores estáticos?

Entendendo um pouco mais como chegamos até aqui

No começo havia o PHP, e era ótimo, só era necessário gostar de pontos de interrogação () :risos

A Internet começou com uma coisa estática, mas evoluiu. Linguagens como PHP e Perl, permitiam aos desenvolvedores renderizar dados no backend em HTML e retornar ao usuário, assim eles introduziram a ideia que os sites poderiam ser dinâmicos com base no visitante. Na época essa era uma ótima solução, mas essa abordagem era mostrar informações, não interagir com elas.

Então aconteceram duas coisas: O JavaScript evoluiu e os navegadores ficaram poderosos. 

Isso significa que os programadores passaram a ter a liberdade de fazer coisas divertidas diretamente no cliente. Por que se preocupar em renderizar tudo no backend e enviá-lo quando você pode simplesmente mostrar uma página HTML básica para o navegador junto com JavaScript e deixar o cliente cuidar de tudo?

Assim surgiram os aplicativos de página única (SPAs) e da renderização do lado do cliente (CSR).

CSR

No CSR, também conhecido como renderização dinâmica, o código é executado no lado do cliente. O navegador baixa o HTML, JavaScript e outros recursos que são necessários e, em seguida, executa o código para renderizar a IU.

Essa abordagem possui alguns Benefícios como:

• Ótima experiência do usuário (se você tiver uma rede rápida).
• Você não precisa voltar ao servidor para mais solicitações, portanto, cada alteração de página ou alteração de dados ocorre imediatamente.
• Cache. Como você não está usando um servidor, pode armazenar em cache os principais pacotes HTML e JS em um CDN. Isso significa que eles podem ser acessados rapidamente pelos usuários e mantém os custos baixos para a empresa.

Server-side rendering

Essa abordagem também possui alguns benefícios:

• O desempenho é maior com o servidor porque o HTML já está gerado e pronto para ser exibido quando a página for carregada.
• A compatibilidade é maior com a renderização do lado do servidor porque, novamente, o HTML é gerado no servidor, portanto, não depende do navegador final.
• A complexidade é menor porque o servidor faz a maior parte do trabalho de geração do HTML, portanto, muitas vezes pode ser implementado com uma base de código menor e mais simples.
• Com SSR, fazemos tudo no servidor.

Qual abordagem usar atualmente? Que tal as duas? 🙃

Existem alguns frameworks JavaScript Frontend que suportam SSR: eles renderizam o HTML no servidor com JavaScript e enviam esse HTML empacotado com o JavaScript para o cliente.

Alguns desses, como NextJS e Remix, são construídos no React. NextJS e Remix oferecem melhores abstrações, facilitando a construção de sites SSR.

O SSR vem com compensações. Podemos controlar mais e enviar mais rápido, mas a limitação com SSR é que para sites interativos, você ainda precisa enviar JS, que é combinado com o HTML estático em um processo chamado "hidratação".

Enviar JS para hidratação esbarra em problemas de complexidade:

• Enviamos todos os JS em todas as solicitações? Ou baseamos na rota?
• A hidratação é feita de cima para baixo e quanto custa isso?
• Como um desenvolvedor organiza a base de código?
• No lado do cliente, pacotes grandes podem levar a problemas de memória. Sem falar que o código está lá, mas só será usado quando for hidratado.

O deno.js esta apresentado uma nova abordagem, que estão chamado de arquitetura de ilhas, pois, em um mar de HTML estático, existem ilhas de interatividade.

A diferença é que a renderização acontece em componentes de forma individual e independente. Desta forma, estamos servindo pedaços menores de JavaScript e fazendo pedaços menores na renderização no cliente.

As ilhas não são renderizadas progressivamente, elas são renderizadas separadamente. A renderização de uma ilha não depende da renderização de nenhum componente anterior, e atualizações em outras partes do DOM virtual não levam a uma nova renderização de nenhuma ilha individual.

Conclusão

A verdade é que cada vez estamos construindo aplicações mais complexas. E nossos usuários merecem ter uma experiência fluída e rápida. A melhor maneira de garantir essa entrega é conseguir criar código compacto e fácil de ser lido.

Estruturas de alto desempenho que se preocupam com a experiência do usuário enviarão exatamente o que é necessário para o cliente e nada mais. Para minimizar ainda mais a latência, implante seus aplicativos SSR perto de seus usuários na borda.

Esse artigo é uma releitura e tradução do artigo original postado no blog oficial do Deno.js. Acesse em: https://deno.com/blog/the-future-and-past-is-server-side-rendering. Último acesso 11 de fevereiro de 2023.

#javascript #reactjs #denojs #nextjs #remix #SSR #CSR #SPA #frontend #backend