Server vs Client Rendering

[igorlvicente]

Depois do Phoenix com o LiveView, o Rails também passou a contar com uma nova forma de "controlar o frontend pelo backend" com o Hotwire.

A ideia é basicamente deixar o mínimo de computação do frontend no lado do cliente e passar a computar o que deve ser computado no backend, enviando só o resultado disso (HTML, portanto) para o frontend.

Gostaria de saber vossas opiniões em relação a isso. Achais que isso vai pegar de novo ou que os Reacts e similares não vão sair de cena tão cedo?

[wilsongomes-swe]

Penso que ambos tem abordagens válidas, e o React Server Components pode aproveitar os dois mundos.

Mas minha opinião, backend tem que ser exposto apenas como API, front consome esta API e o que é de front processa no front, o que é de mobile processa no mobile... Front é um client, assim como mobile, gosto muito mais desta linha de pensamento pois ela facilita muito a vida em questões de separação de responsabilidades e preocupações, até a nível de equipe.

Mas em um projeto pessoal que apenas eu vou mexer, vou de PHP com handlebars e boa! rs Agora em um projeto com 50 devs, gosto de ter as equipes separadas, as responsabilidades separadas, as preocupações separadas...

[ninetails]

Ia comentar também sobre o React Server Components. Ressalto que vale dar uma olhada.

Mesmo no React existem projetos bem conhecidos da comunidade atualmente como o Next.js e o Gatsby. Hoje já não é futurismo falar de SSR e SSG para nenhum dos frameworks mais utilizados.

Tem-se o híbrido ainda usando SPA para suportar caching no frontend e offline navigation. E sempre teve o PWA, que seguindo o manifesto (não o que tá na boca de marqueteiros), a aplicação deve funcionar desde desabilitando o JavaScript quanto num celular high end, neste último aproveitando caching e funcionalidades atuais; logo para funcionar com JS desabilitado ainda requer que o servidor cuide da renderização.

E tem o Svelte que eu adoro citar pois a idéia dele é gerar um JS pro front compilado em tempo de build, diminuindo o tamanho do bundle.

Eu acho que atualmente estamos numa era de transição. O meu único medo com isso é voltar à época do PHP/ASP código macarrônico sem MVC raiz, onde a galera dá um passo pra trás e coloca código de servidor no meio do código do cliente.

Tirando isso, ainda acho que zero bundle size é uma evolução necessária mas que ainda está dentro de PWA pois ainda precisamos de "interatividade" e dinamismo no frontend mas cada vez mais tirando o ônus da carga da aplicação pro cliente, especialmente se incluir IoT e interfaces menores, com menor poder de hardware ou até mesmo centralizando e otimizando requisições do render da UI fazendo isto no server-side.