Nova documentação do React "finge" que SPAs não existem.
Ontem, 17 de março de 2023, uma nova documentação oficial do React foi publicada no site https://react.dev/. Essa nova documentação traz muitas novas melhorias, porém uma parte interessante se encontra na seção "Start a new React Project", onde anteriormente era recomendado o uso do create-react-app mas que deu lugar nessa nova versão para a recomendação de Frameworks como NextJS, Remix , Gatsby e Expo para projetos nativos.
Porém, essa mudança ocasionou uma certa repercursão online, uma vez que a biblioteca foi inicialmente criada com o intuito de construir Single Page Applications (SPAs) mas agora parece estar cada vez mais se desviando desse caminho.
A própria documentação afirma várias vezes que utilizar essas frameworks é a forma recomendada de se criar uma aplicação com React, e recomenda utilizar o React puro apenas em casos especiais onde sua aplicação possui alguma limitação não-usual.
A remoção da recomendação do create-react-app é algo que a maioria viu como positivo, uma vez que a maior parte da comunidade entende que o projeto era bastante problemático e já havia migrado para ferramentas mais poderosas como o Vite
Porém, alguns parecem estar descontentes com o fato de que qualquer citação à ferramentas para criação de SPAs estão escondidas dentro da seção "Can I use React without a framework?", algo que se contraria bastante aos fundamentos da biblioteca.
Tudo isso faz sentido considerando algumas mudanças recentes no React como o post feito pelo Deschamps aqui: React está querendo tornar "APIs" algo obsoleto?. Ao visto o futuro do React é menos SPAs e mais SSR e aplicações full-stack, utilizando frameworks robustas como fundação para grandes projetos.
Claro, mesmo utilizando essas frameworks ainda é possível criar SPAs. Porém apesar disso o fato é que elas não foram feitas pra isso, o que ainda é mais contraditório, pois SPAs foram toda a motivação por trás do React no começo.
Na minha opinião, consigo entender o motivo da documentação referenciar essas frameworks, porém ainda sinto que o Vite deveria ser a primeira opção mencionada, pois sinto que para quem está iniciando trabalhar com uma framework pode acabar complicando mais do que ajudando.
Mas e ai, o que vocês acham dessa mudança??
-
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.
-
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.
-
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
ótimo post 👏
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.