Existem vários frameworks que geram o front-end da aplicação no lado servidor (JSF, Grails, Rails, Django).
Com a grande ascensão dos frameworks JavaScript (Angular, Vue.Js, React) os frameworks full-stack ainda são muito relevantes? Faz sentido adotá-los para novos projetos?
Questão de desempenho e custo? O que vale mais a pena?
Vamos discutir!
“Bom, cada caso é um caso”
Consultor
Há vantagens e desvantagens. A vantagem do framework full stack é que, como o próprio nome já diz, ele te trás tudo pronto: você está com uma plataforma completa de desenvolvimento fornecida no momento em que o desenvolvimento começa.
E isto do ponto financeiro é uma puta vantagem, por que você pode economizar horrores neste ponto. É uma única plataforma a ser aprendida, é um conhecimento que é mais fácil de ser compartilhado por toda a equipe, facilita a entrada de novos membros e, no frigir dos ovos, economiza dinheiro e custo de desenvolvimento e manutenção. Esta eu chamaria da vantagem econômica.
Do ponto de vista técnico, há algumas vantagens também nestes frameworks: a principal hoje, pra mim, diz respeito a SEO. Tanto é que o principal fator de venda da renderização do lado servidor é justamente esta. Como você não está retornando código JavaScript para os robôs, acaba facilitando e muito o trabalho dos motores de busca na indexação do seu conteúdo. Do ponto de vista de desempenho, a renderização do lado servidor pode inclusive ser mais eficiente justamente por não ter JavaScript complicado na outra ponta: é apenas HTML enviado para o seu browser (na maior parte das vezes).
Pessoalmente, ainda não encontrei uma ferramenta de scaffolding boa o suficiente que não realize a renderização do lado servidor (estou buscando, se houver indicações nesta thread seria ótimo).
Agora, trás suas desvantagens também. Ao adotar o framework você está se casando com uma mentalidade específica que pode não acompanhar o tempo. Exemplo clássico: JSF e Tapestry.
Vamos agora falar um pouco sobre a renderização do lado cliente: do ponto de vista organizacional a grande vantagem é a especialização. Você ter uma pessoa dedicada ao backend e outra ao frontend pode fazer toda a diferença (nada contra o fullstack, pelo contrário, mas na esmagadora maioria das vezes tendem a ser patos (nadam, voam, andam, mas não fazem nenhum destes com perfeição)).
O simples fato de você projetar o seu backend como uma API já justificaria estrategicamente esta abordagem. Esta segunda abordagem trás uma vantagem estratégica que a meu ver é fenomenal: você não fica 100% preso a uma abordagem (fica apenas 50% - o fato de estar desenvolvendo algo focado em uma API, o que não é ruim (hoje)).
Economicamente, entretanto, você não tem a mesma vantagem do fullstack, por que são conhecimentos distintos os necessários para manter o projeto. E gestão de conhecimento é cara.
Poder trocar o framework usado no frontend, por exemplo, é maravilhoso. Veja o /dev/All, por exemplo: nasceu como uma aplicação Grails (full stack até a alma). Pouco a pouco vimos que o ideal seria termos, antes de uma interface, uma API. Nasceu então uma API implementada inicialmente no próprio Grails que era consumida por um frontend Vue.js (embarcado no GSP do Grails).
Passou algum tempo, matamos o backend feito em Grails e o substituímos rapidamente por Node.js e depois por Spring (sem prejuízo para o frontend, visto que mantivemos os contratos). E no front-end, então, várias mudanças: GSP -> Vue.js -> Angular hoje e talvez mobile nativo amanhã se fizer sentido.
Resumindo então, a meu ver, é questão de pesar o lado econômico e também da própria equipe, definir muito bem a estratégia (uma API nem sempre faz sentido no projeto) e escolher aquilo que atende ao projeto, já diria o consultor. 
2 Curtidas
Oi Kico. No caso do /dev/All pq se deu a mudança do Node para o Spring? Você pode comentar a experiência?
Um abraço.
Oi Igor, claro!
Essencialmente apesar de gostar muito do Node, o Java ainda é muito mais estável, e apesar de ter a aura de mais verboso (o que é em grande parte balela), as ferramentas que temos pra ele, além do próprio ecossistema de bibliotecas/frameworks ainda está à frente.
Além disto também queríamos fazer algumas experiências com Spring Boot internamente no /dev/All, o que justificou a implementaçao como inicialmente uma prova de conceito e posteriormente como versão semi definitiva.
Mas se eu tivesse uma crítica ao Node.js, hoje, seria o seguinte: você tem ilusão de poder e produtividade. Pra projetos pequenos, cai muito bem, mas quando você topa com problemas como um bloqueio ou um callback hell, toda a história da produtividade vai pro saco muito rápido.
Semi definitiva por que na realidade usamos internamente o /dev/All (o crawler e a API) na itexto como material de estudo para diversas tecnologias aqui na itexto. Então, se quisermos, por exemplo, testar Erlang pro desenvolvimento, temos um caso real no qual podemos validar o uso da tecnologia.
Então não excluímos a possibilidade de em breve haver uma implementação da API do /dev/All em Node.js de novo.
2 Curtidas