Nova documentação do React "finge" que SPAs não existem.

Excelente post, Rafael!

1. A motivação por trás do React foi criar uma maneira mais simples de criar aplicações interativas sem manipulação da DOM. SPAs foram consequência das limitações do React, e não o motivo pelo qual o React foi construído.

2. Fazer ou não um SPA tem que ser uma decisão tomada como qualquer outra, baseado nas limitações e requerimentos do seu projeto. Eu conheço muito mais gente que fez SPA porque era o padrão do React na época e depois sofreu para quebrar essa arquitetura e fazer coisas simples como SEO, do que eu conheço gente que ativamente mediu benefícios e prejuízos e escolheu fazer um SPA.

3. Por que você acha que frameworks complicam mais do que ajudam para iniciantes?

Se o mercado está tendendo para este lado, para mim, faz todo o sentido a documentação também focar nessas áreas. As empresas que trabalhei e trabalho não criam mais aplicações SPA, já que agora você pode criar aplicações com todas as vantagens de um SPA sem as desvantagens dele (SEO, build, etc).

E também nunca vi alguém realmente utilizando de fato os recursos de um app SPA, como salvar a página e utilizar como uma aplicação separada de um navegador.

Existe uma thread no Twitter onde o Dan explica essa tomada de decisão e esse shift que está acontecendo atualmente. Inclusive em outras threads ele cita que os termos SPA, SSG, MPA, etc, devem ser deixados de serem utilizados já que frameworks como o Next são um mix dessas terminologias.

Ele inclusive cita diversas vezes que o Next não precisa de um server node para executar, ou seja, pode ser usado como SPA. Eu particularmente discordo um pouco dessa abordagem já que ao usar o Next dessa forma, muitas das principais funcionalidades deixam de funcionar. Ou seja, vc está incluindo um framework robusto na stack do seu projeto apenas para usar o sistema de rotas que não inclui tudo no arquivo index.html. Soluções como gerenciamento de estado e data-fetching ainda seriam necessárias

https://twitter.com/dan_abramov/status/1636827365677383700

será que a ideia por trás disso seria usar SSR como padrão para apps web?

ótimo post 👏

E voltamos ao bom, velho e sempre funcional MPA

Até que demorou pra nova tec front end do momento começar a se achar demais e tomar decisões dúbias baseadas em achismos e desvaneios de um diretoria que só olha pro seu umbigo.
Eu não uso React, embora já usei, e sempre achei muita coisa, se voce nao precisa fazer um projeto front end muito elaborado nao precisa dele. Na maioria dos casos a triade básica resolve: html+css+js.
Sempre indico que uma empresa NUNCA fique preso em uma framework modinha, pq sempre dá nisso. Uma hora eles piram o cabeçam e começam as bizarrices.

concordo totalmente que assumir que o React puro não é recomendado, é um tiro no pé. Desde que comecei a desenvolver com React, 90% dos casos fui para opções como SPA, especialmente em projetos que precisamos de resultados rápidos e não podem perder tempo com infra, SSR, tipos de bundles e afins. Hoje com opções como vite, concordo que o CRA hoje é visto como não performático com as configurações padrões, mas acelera muito o start do projeto, acredito que deveriam deixar como opção escolha pro dev, sem colocar como "não recomendado", porque cada caso é um caso e cabe o Dev decidir, sem interferência de uma DOC dizer que não é recomendado. DOC tem peso, o Dev decidir por contradizendo a DOC oficial, pode ser visto como má pratica, e as vezes travar uma briga com Arquitetos/Product Managers, por não ser uma opção recomendada pela DOC...

primeiramente, ótimo conteúdo.

como sempre aconteceu, as coisas mudaram e continuarão mudando, por isso é muito importante a gente se manter sempre atualizado, quando se trata de frontend há uma infinidade de opções, você deve aproveitar aquela que te faz mais produtivo mas ao mesmo tempo seguir fazendo varios scaffoldings de frameworks novos e tecnologias novas pois a história mostra que tendencias mudam rapidamente. Quando angular 2 com Typescript surgiu galera teve que correr, no react quando surgiram redux saga tivemos que correr, quando o next era novidade e queriamos fugir do SPA propositalmente por motivos especificos, entre outros, esses sao alguns dos movimentos de mudança que vi acontecer pra mim, teve outros que nem lembro, você deve ter os seus.

Vemos que tudo muda rapidamente e isso é bom. Vamos em frente acompanhar mais esta mudança, bem vindo à vida de programador que precisa estar sempre atualizado. abraços

SPA não fazem mais sentido, porque com frameworks como nextjs, você consegue gerar páginas estáticas, e embutir interatividade após o conteúdo da página ser enviado. Com nextjs você consegue SEO e interatividade. Com SPA você tem uma página interativa, que retorna apenas um arquivo javascript enorme do servidor, em que caso de uso você precisaria disso? como já respondido pela equipe do react, em casos específicos.

Na minha opinião, usar SSR não tira o status de SPA de uma aplicação, na verdade, SSR é só um meio de renderizar/gerar HTML para algumas partes do SPA.

Isso que o React está fazendo é o ideal. Você recebe os benefícios e a experiência de usuário de um SPA, e mesmo assim ainda consegue manter uma qualidade de SEO. A verdade é que a maioria das aplicações comerciais em React já usa algum framework desse tipo.

Nada te impede de fazer SPAs nesses frameworks. Na verdade, é bem fácil.
Contudo, no meu ver, iniciantes frequentemente buscam criar aplicações inerentemente MPAs como SPAs, o que as obriga a usar um roteador. Nesse caso, o bom e velho mapeamento da URL pro sistema de arquivos é muito mais intuitivo, como um PHP da vida.