SSR - Essa 'revolução' não entra na minha cabeça.
Fala galera!
Muito provavelmente são altas as chances de você ter lido isso e pensado: 'putz, que cara burro' (ou não rs), mas vamos lá... sou desenvolvedor back-end, odeio front-end e ultimamente estou me aventurando no Front por conta de alguns projetos pessoais, mas sinceramente, não consigo entender o porque o tal SERVER SIDE RENDERING seria algo revolucionário.
Isso não seria a mesma coisa de anos atrás, onde era comum ter códigos PHPs macarrônicos que buscavam as coisas do server, montavam um HTML final com os dados já populados e se necessário utilizasse jQuery para as interações?
A única revolução então seria fazer exatamente isso diretamente com React/Vue/Svelte?
Seria isso?
Meus 2 cents:
Ok, vamos nos reunir ao redor da fogueira e vou contar como fazíamos quando os dinossauros andavam por estas paragens...
- Antes tudo era estático, reinava o HTML - que nasceu como uma linguagem de formatação do conteúdo.
Nos primórdios da web, a internet era um lugar simples, quase bucólico. Tudo era estático. O HTML, criado por Tim Berners-Lee no final dos anos 80 e início dos 90, era usado para estruturar páginas com títulos, parágrafos, links e imagens. Essas páginas eram arquivos .html fixos, armazenados em servidores e entregues aos navegadores exatamente como foram escritos.
Era como se fosse um livro digital: você podia ler, mas não havia interação real. Cada página era como uma folha impressa, imutável. Se alguém queria atualizar o conteúdo, precisava editar manualmente o arquivo HTML e substituir a versão antiga no servidor. Era um processo lento e trabalhoso, mas funcionava para a época.
Os primeiros servidores web, como o Apache HTTP Server, surgiram nesse período. O Apache, lançado em 1995, tornou-se rapidamente o servidor mais popular da web, responsável por entregar essas páginas HTML estáticas aos navegadores. Ele era robusto, confiável e altamente configurável, permitindo que administradores personalizassem como os arquivos eram servidos.
Outros servidores web também começaram a ganhar espaço, como o IIS (Internet Information Services) da Microsoft, que se tornou padrão em ambientes Windows, e mais tarde o NGINX, conhecido por sua eficiência em lidar com alto tráfego e servir arquivos estáticos rapidamente.
- Aos poucos, quem fornecia conteúdo queria incluir informações dinâmicas no meio do conteúdo estático e assim nascia o CGI.
Com o tempo, as pessoas começaram a perceber que o conteúdo estático tinha limitações. Imagine um site de notícias onde os artigos precisavam ser atualizados diariamente, ou uma loja online que precisava exibir produtos diferentes dependendo do estoque. Era inviável manter tudo manualmente.
Foi então que, no início dos anos 90, surgiu o CGI (Common Gateway Interface). O CGI era como uma ponte mágica entre o navegador do usuário e o servidor. Ele permitia que programas externos gerassem conteúdo dinâmico e o inserissem no meio das páginas HTML.
Esses programas eram escritos em linguagens como Perl, C ou até Shell Script. Eles recebiam dados do navegador (como entradas de formulários) e enviavam respostas customizadas de volta. Por exemplo:
- Um formulário de contato poderia enviar os dados para um script CGI, que gerava uma resposta personalizada.
- Um contador de visitas poderia ser implementado com CGI, mostrando quantas pessoas já tinham acessado a página.
Mas havia um problema: cada requisição CGI gerava um novo processo no servidor, o que era pesado e ineficiente. Mesmo assim, foi um avanço monumental, pois abriu as portas para o conteúdo dinâmico. Servidores como o Apache e o IIS suportavam CGI, permitindo que desenvolvedores começassem a explorar a web dinâmica.
- Então chegou o PHP, que trouxe luz ao caos do CGI e popularizou o SSR (Server-Side Rendering).
O CGI era poderoso, mas complexo e difícil de manter. Foi aí que, em 1994, Rasmus Lerdorf criou uma ferramenta chamada PHP (originalmente "Personal Home Page Tools"). No início, era apenas uma coleção de scripts Perl para gerenciar seu site pessoal, mas rapidamente evoluiu para uma linguagem completa.
O PHP revolucionou a web porque permitia embutir código diretamente no HTML. Em vez de criar um programa separado para gerar conteúdo dinâmico, você podia misturar PHP e HTML no mesmo arquivo. Por exemplo:
<html>
<body>
<h1>Bem-vindo, <?php echo $nome; ?>!</h1>
</body>
</html>
Isso simplificou enormemente o desenvolvimento web. O PHP também era executado como um módulo do servidor web (como o Apache), o que era muito mais eficiente do que iniciar um novo processo para cada requisição, como no CGI.
Com o PHP, o SSR (Server-Side Rendering) tornou-se amplamente acessível. O servidor processava o código PHP, gerava o HTML final e o enviava ao navegador. Isso permitiu a criação de sites dinâmicos, como blogs, sistemas de login e lojas virtuais.
- Python entra na jogada com Flask e Django, trazendo elegância e poder ao SSR.
Enquanto o PHP dominava o mundo do desenvolvimento web, outras linguagens começaram a ganhar espaço. Uma delas foi o Python, conhecida por sua simplicidade e legibilidade.
Em 2004, Adrian Holovaty e Simon Willison criaram o Django, um framework web robusto e completo para Python. Inspirado no Ruby on Rails, o Django seguia o padrão MVC (Model-View-Controller) e trazia muitas funcionalidades prontas, como autenticação de usuários, administração de conteúdo e ORM (Object-Relational Mapping) para interagir com bancos de dados. O Django era especialmente popular para projetos grandes e complexos, como plataformas de e-commerce e sistemas de gerenciamento de conteúdo.
Por outro lado, em 2010, Armin Ronacher lançou o Flask, um microframework minimalista para Python. O Flask era leve e flexível, ideal para projetos menores ou para desenvolvedores que preferiam construir suas próprias soluções sem muita "mágica" automática. Ele se tornou popular para APIs e pequenas aplicações web.
Ambos os frameworks, Django e Flask, usavam SSR para renderizar páginas dinamicamente no servidor, entregando HTML pronto para os navegadores. Eles funcionavam perfeitamente com servidores como o Apache, NGINX e até o Gunicorn (um servidor WSGI para Python).
- Finalmente, chegamos ao Next.js e à era moderna do SSR dinâmico.
Nos anos 2010, o JavaScript dominou o mundo web. Com o surgimento do Node.js, o JavaScript passou a ser executado tanto no navegador quanto no servidor. Isso abriu as portas para frameworks modernos como React, que permitiam criar interfaces dinâmicas e interativas no lado do cliente.
No entanto, as SPAs (Single Page Applications) baseadas em React tinham problemas:
- Carregamento inicial lento.
- Dificuldades com SEO (Search Engine Optimization).
Para resolver isso, em 2016, a Vercel lançou o Next.js, um framework baseado em React que trazia de volta o SSR de forma moderna. O Next.js permite:
- SSR: Renderizar páginas dinamicamente no servidor.
- SSG (Static Site Generation): Gerar páginas estáticas em tempo de build.
- ISR (Incremental Static Regeneration): Atualizar páginas estáticas sem precisar reconstruir todo o site.
Com o Next.js, o SSR dinâmico atingiu sua forma mais avançada. Hoje, é possível criar sites rápidos, otimizados para SEO e altamente interativos, combinando o melhor dos mundos: conteúdo estático e dinâmico.
- Os servidores web continuam evoluindo: Apache, IIS e NGINX.
Ao longo dessa jornada, os servidores web também evoluíram para atender às demandas crescentes da web moderna:
- O Apache permaneceu como uma escolha popular para hospedar sites PHP e outros conteúdos dinâmicos, graças à sua flexibilidade e suporte a módulos.
- O IIS continuou sendo a escolha padrão para ambientes corporativos baseados em Windows.
- O NGINX emergiu como uma solução leve e eficiente para servir conteúdo estático e balancear carga em aplicações de alto tráfego. Ele também é amplamente usado como proxy reverso para Node.js, Django e outros frameworks modernos.
Epílogo: A evolução continua...
A história do HTML estático ao SSR dinâmico é uma jornada fascinante que reflete a evolução da própria web. De páginas simples e imutáveis a experiências ricas e personalizadas, cada avanço tecnológico trouxe novas possibilidades.
Hoje, enquanto contamos histórias ao redor da fogueira, sabemos que a próxima revolução já está sendo escrita. Quem sabe o que o futuro nos reserva? 🌟
Vc tem razão, não tem nada de revolucionário. É apenas mais um dos milhares de casos que acontecem na nossa área, de dar nomes novos para coisas velhas, e geralmente com algum discurso bonito pra parecer que é algo inovador e "disruptivo".
Sobre isso, tem uma discussão interessante aqui, e destaco os comentários abaixo:
"Basicamente o SSR do VUE é pra consertar aquilo que o pessoal da 'moda' em geral não tinha entendido até então. O HTML sempre foi SS por natureza, mas mesmo com o advento do Ajax, tem um pessoal que foi esperto desde o começo, e fazia coisa server side que melhorava com JS, sem perder o server side. Infelizmente, uma parcela do pessoal do JS não olhou a figura maior e atropelou em boa parte dos frameworks"
"Você está no ponto A abre um caminho para o ponto B porque acha que lá é mais bonito. Você percebe que B não é exatamente o que você esperava e deseja voltar ao A. Você tem duas opções: 1) voltar pelo mesmo caminho até A ou 2) Abrir um novo caminho e parar em C achando que está em A. SSR é a segunda opção."
Aliás, é incrível como nossa área anda em círculos:
- surge algo diferente
- começam a usar
- acham que é a solução pra tudo
- usam pra tudo (até pra casos em que não faz sentido e/ou é a pior solução)
- voltam para como era antes (muitas vezes com nomes novos pra parecer que é algo moderno)
- começam a usar
- acham que é solução pra tudo
- e assim vai...
Não é, é só mais uma vez algumas pessoas tirando proveito de algo normal.
SSR sempre existiu, toda a web foi montada em cima dele, antes mesmo de existir jQuery, AJAX e afins, portando não tem revolução alguma, estão peganbdo o erro, cantado por várias pessoas, voltanram atrás e estão vendendo como acerto. Percebe o padrão?
Não é curioso que as pessoas continuam usando AJAX mas abandonaram o termo? Por isso que eu falo disso aqui.
Embora eu não ache que a maioria dos casos estejam exatamente corrigindo o erro principal, o mercado é sempre assim, olham para o lado errado. Eu costumo responder mais pelo lado de enganheria, claro que não ignoro o que o mercado faz, mas tenho que ressaltar o erro técnico.
Quase sempre que você deveria fazer SSR na verdade não deveria estar usando tecnologias complexas, porque é um site "simples" que precisa de SEO. Claro que existem casos que pode ter uma necessidade real. E quase sempre que não precisa do SSR é porque tem grande chance, mas não total, de ser melhor fazer uma aplicação nativa, criada da maneira certa só tem vantagens.
Quase todo mundo concorda que complexidade é ruim, certo? Então por que a maioria opta por ela quando pode fazer o simples? Por que muita gente usar uma ferramenta nova para consertar o erro que só existe porque ela errou antes em adotar algo que não deveria?
Toda tecnologia (seus criadores) quer ser usada de forma ubíqua, então ela vai oferendo o que as pessoas vão sentindo falta, mesm oque originalmente ela não tenha sido criada para aquilo. Por exemplo usar OOP em PHP, a linguagem não foi criada para isso, mas passou a ter porque as pessoas passaram usar PHp até onde deveria usar outra coisa, então ela correu atrás para alcançar o mercado, mesmo que do ponto de vista de engenharia não deveria ser assim.
É claro que existe alguma vantagem em ter o mesmo código atuando em modo SSR e CSR, mas como eu disse, só em alguns casos é realmente pertinente e não está só consertando o erro. O SSR tem várias vantagens, e algumas desvantagens também, ele tem aplicação, mas não é uma revolução, é uma arrumação, a descrição fantástica é só marketagem.
S2
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).
Vamos lá, sou dev frontend e ja fui hater de SSR principalmente pq comecei pelo PHP e dizia "se for pra usar isso dai eu volto pro PHP", muita gente falou aqui sobre historia e sobre marketing, mas tem três vantagens do SSR do NextJS que gosto muito.
- SEO: SSR permite ajustes finos para melhorar SEO só que conseguindo ter gerenciamento de estado que é a principal razão de se usar React.
- Melhor desempenho: Como React envia JS para renderizar o html no front, utilizar SSR reduz a necessidade de processamento no cliente ja que o componente ja foi processado no back, um detalhe que difere o SSR do NextJS ao PHP é que no PHP a página é processada a cada requisição consumindo recursos do servidor, no NextJS isso é feito no momento de build uma única vez, entao acaba sendo mais eficiente.
- Intercalar client e server: Por padrão componentes são SSR mas caso precise de funções client o NextJS te permite que use componentes desse tipo dentro de componentes SSR e vice versa, isso traz muitas possibilidades.
Concordo que chamar isso de "revolução" é exagero de marketing. É mais uma evolução natural e uma correção de curso.
O SSR moderno (Next.js, Nuxt, etc.) traz refinamentos significativos, como hidratação progressiva, streaming SSR e renderização parcial, que não existiam nas implementações antigas.
A lição valiosa é que devemos ser cuidadosos com soluções "revolucionárias" e nos concentrar nas necessidades reais de cada projeto, em vez de seguir cegamente as tendências do momento.
Em certos momentos todo mundo faz e é perfeito. Em outro momento, você não pode mais fazer isso, pois é errado. E logo depois, olha lá a mesma coisa sendo feita, porem com nome diferente e agorsa é uma mas maravilhas do mundo. Ou seja, melhor focar no produto, do que evengelizar uma cacetada de ferramentas...
Termo bonito pra um coisa que já se fazia há anos atrás, só que agora com supostos padrões "corretos" e seguindo uma filosofia dos criadores, seja Blade Template Engine no PHP com alguma lib, Vue, React e toda a sopa de letrinhas javascript full-stack que encontrar por aí, nada de novo, apenas padronizado, teoricamente fácil e com filosofia própria, dar novos nomes a coisas velhas, Conteineres, Buckets de dados, Servidores Bare Metal, Edge Computing... tudo nome bonito pra dizer que as novas supostas filosofias e tecnologias saem no mercado de época a época não resolvem tudo e com vergonha decidem voltar atrás rebatizando o antigo pra omitir o fracasso.
Cara, também não sou front-end, mas ao meu ver como todos aqui já mencionaram, é básicamente mais do mesmo, o que está em alta e que trouxe esse conceito ao 'hype' novamente é que no Brasil estão começando a adotar os microsfrontends que equivale aos microsserviços, e por conta disso é necessário um mecanismo que junte tudo isso para que seja renderizado, ai é que entra o SSR, vejo principalmente o pessoal utilizando isso alinhado ao BFF do NEXT.js, mas é mais do mesmo, é como eu disse, precisam de um mecanismo para juntar as partes do front-end e para isso utilizam o conceito de SSR, porém agora deixou de ser o código macarrônico em PHP e passou a ser utilizado arquiteturas modernas como Clean Arch por exemplo, e frameworks pensados nisso.
eu lembro que quando eu estava aprendendo, estava no hype do Next.js 13 onde essa ideia era algo revolucionário. Depois que aprendi Node.js, notei que já havia soluções para criar páginas do lado do servidor a muito tempo usando um arquivo chamadado .pog, que é um template, se eu não me engano, não estudei a fundo.
Indo mais a fundo descobri que PHP era uma linguagem de back-end (eu jurava que era front-end pois era muito falado no contexto da web), depois disso eu entendi que não havia nada de novo para os experientes, apenas havia mais uma trend como é com o React... Depois disso eu entendi o quanto eu estava em uma bolha...
A única revolução então seria fazer exatamente isso diretamente com React/Vue/Svelte?
Não sei o Svelt, mas o vue e o react precisam de frameworks para realmente funciona bem. Nuxt.js e Next.js, respectivamente. Apesar de haver outros por ai que são baseados em React também além do next.js.
Acredito que a única revolução é em otimização e refinamento dessa estratégia que já existia a tempos.
É exatamente isso, porém, estamos falando de Frameworks mais modernos com muito dinamismo, eficiencia em navegação, como Next, Remix, etc, que até então não não se tinha como fazer um SEO eficiente com eles.