- O React continua sendo o framework de UI mais usado, mas, nos últimos anos, a confusão, as controvérsias e a desconfiança na comunidade aumentaram, e a combinação de falta de comunicação entre a equipe oficial e desenvolvedores externos com marketing inadequado ampliou as preocupações
- O React 19 foi lançado oficialmente, trazendo grandes recursos como Server Components, o novo hook
use e integração com formulários, porém a política de "recomendar apenas frameworks" e a estrutura centrada no Next.js geraram insatisfação em muitos usuários
- Espalharam-se mal-entendidos e FUD como "agora o React só pode ser usado direito com Next.js" e "em breve o suporte exclusivo ao cliente será encerrado", mas, na prática, a renderização no cliente jamais vai desaparecer, e os recursos de RSC e de servidor são opcionais
- A política da equipe do React de priorizar frameworks busca padronizar desempenho/arquitetura e melhorar a experiência do usuário, mas a falta de consideração por SPAs e por arquiteturas diversas, além de documentação informal e pouco amigável, aumentou a confusão na comunidade
- Só recentemente métodos diversos, como SPAs baseadas em Vite e Parcel, passaram a constar na documentação oficial, mas ainda persistem a falta de explicação oficial sobre Server Components (RSC) e problemas de comunicação
Introdução e objetivo
- Em 2025, a comunidade React vive um momento complexo, misturando sucesso, desconfiança e controvérsia
- O objetivo deste texto é organizar a trajetória de evolução do React, sua direção de desenvolvimento e o contexto das principais decisões, além de dissipar o FUD e a confusão
Histórico do autor e participação na comunidade
- Não faz parte da equipe do React, mas atua profundamente no ecossistema React desde 2015
- Mantenedor da família de bibliotecas Redux, especialmente Redux Toolkit, e importante membro ativo da comunidade
- Participou de inúmeros tutoriais, blogs, palestras e podcasts sobre React/Redux
- Atua como moderador e administrador em comunidades importantes como Reactiflux Discord e o subreddit /r/reactjs
- Tem experiência de colaboração com a equipe do React (por exemplo, como testador alfa do hook
useSyncExternalStore) e participou de vários grupos internos de feedback
- Fez contribuições técnicas em React DevTools, sourcemaps, Replay DevTools e outras áreas
-
Aviso sobre vieses e limitações
- O autor reconhece que nem sempre pode estar certo e que pode haver algumas imprecisões por limitações de informação, mal-entendidos ou simplificações no resumo
- Mantém o Redux, e sua experiência com React também é mais voltada a ferramentas internas e ao formato de SPA
- Tem experiência prática limitada com SSR, RSC, tráfego em larga escala, i18n etc.
- Está familiarizado com temas discutidos profundamente na comunidade, mas isso pode se distanciar em parte do cotidiano do desenvolvedor de aplicativos em geral
- Tanto experiências pessoais positivas quanto negativas com a equipe do React influenciam sua perspectiva
- Procura transmitir os fatos da forma mais fiel possível ao explicar o contexto histórico e estrutural
Breve história do React
- Desenvolvido internamente no Facebook (atual Meta) entre 2011 e 2012, e aberto como open source em 2013
- Até recentemente, todo o desenvolvimento central foi liderado pela equipe do React no Facebook/Meta
- Os conceitos centrais (componentes, props, state, fluxo de dados) foram mantidos, enquanto implementação, APIs e escopo de aplicação continuaram se expandindo e mudando
createClass → classes ES6 → componentes funcionais (com suporte a Hooks)- Expansão para várias plataformas: mobile com React Native, WebGL com react-three-fiber via react-reconciler, CLI com ink etc.
- Refatoração interna completa para a arquitetura "Fiber" (inovação estrutural e de desempenho)
- Introdução dos Hooks em 2018, levando estado e efeitos aos componentes funcionais
- Com a estratégia de "biblioteca mínima de UI (o V do MVC)", arquitetura, frameworks de mais alto nível, build e gerenciamento de estado foram delegados à comunidade
- Com isso surgiram inúmeras bibliotecas de terceiros e ferramentas de build, como Redux/Mobx/Zustand (estado), Styled-Components/Emotion/CSS Modules (estilo), React Query/Apollo/SWR(RTK Query) (dados), Webpack/Vite/Parcel etc.
- A flexibilidade é uma vantagem, mas exige escolher bibliotecas conforme a necessidade de cada projeto → junto com isso vieram diversidade de codebases, fadiga e ausência de padrões
-
Ferramentas de build e CRA
- No início, configurações complexas com Webpack/Babel etc. eram obrigatórias
- Create React App (CRA): CLI baseado em Webpack+Babel, que escondia a complexidade e permitia criar projetos com um único comando (modelo de caixa-preta)
- Data fetching e gerenciamento de estado dependiam de ferramentas separadas de terceiros
- O SSR (server-side rendering) existia desde cedo, mas exigia implementação manual
- Depois surgiram frameworks como Next.js (SSR/roteamento por sistema de arquivos, data fetching), Gatsby (sites estáticos, GraphQL) e Remix (loaders de dados no servidor)
-
React Server Components (RSC) e a transição para frameworks
- No fim de 2020, foi revelado o protótipo de React Server Components (RSC), uma mudança arquitetural para padronizar componentes assíncronos e data fetching no servidor com React
- Durante o desenvolvimento, alguns membros da equipe do React foram para a Vercel e colaboraram com o Next.js na primeira implementação do App Router e de RSC
- Entre 2020 e 2023, a documentação oficial do React (react.dev) foi completamente reformulada, com mais tutoriais interativos e referências de API
-
Mudança nas recomendações oficiais de uso
- No passado, a documentação oficial recomendava começar SPAs com CRA e, em caso de necessidade de SSR/site estático, indicava alternativas como Next e Gatsby
- Na nova documentação (react.dev), o uso de frameworks é fortemente recomendado (roteamento, data fetching, integração de build), e apenas o Next.js é citado como implementação de RSC
- O CRA ficou praticamente sem manutenção a partir de 2022 (não estava oficialmente deprecated, mas foi sendo substituído pela comunidade)
- Tanto na documentação oficial quanto na comunidade, ganharam destaque opiniões como "Next.js é o verdadeiro React 18", reforçando a forte associação com o Next.js
Relação entre React e a empresa proprietária (patrocinadora)
-
Meta (Facebook)
- O React sempre foi um projeto de propriedade e liderança do Facebook/Meta
- Embora seja open source, o desenvolvimento prático sempre foi conduzido pela equipe React da Meta, e reuniões centrais e roadmap também eram centrados internamente
- Novos recursos eram validados e testados em vários times internos de apps da Meta antes de serem lançados externamente
- A equipe do React tinha alto grau de autonomia e liderava a definição de roadmap e visão
- Internamente, era preciso comprovar como os resultados e o projeto contribuíam para os negócios da Meta
- A Meta usa ativamente sua própria infraestrutura de servidores e tecnologias próprias, como GraphQL e Relay, utilizando React de forma diferente da comunidade em roteamento, gerenciamento de estado etc.
- Por isso, internamente na Meta, o uso de bibliotecas externas de terceiros é menos frequente
-
Vercel, Next.js e React
- A Vercel é uma plataforma de hospedagem de aplicações web e a empresa por trás do framework Next.js
- Seu modelo de negócio é expandir a adoção de frameworks como o Next e, com isso, atrair hospedagem para a plataforma da Vercel
- O CEO, Guillermo Rauch, investe e confia profundamente na filosofia de renderização do React desde os primeiros tempos
- Em 2021, o líder da equipe React, Sebastian Markbage, saiu da Meta para a Vercel, seguido por nomes importantes como Andrew Clark e Tom Occhino
- Os membros que foram para a Vercel implementaram recursos centrais como React Server Components (RSC) e o Next.js App Router tanto no React quanto no Next.js
- Engenheiros da Vercel também contribuíram de forma concreta para o core do React e para recursos de renderização no servidor
- Em 2025, a equipe do React está dividida entre Meta e Vercel (com a maior parte na Meta, mas com implementações centrais importantes também na Vercel), além de alguns contribuidores externos
Padrões de uso do React
-
Arquitetura padrão
- O próprio React suporta várias formas de uso, como SPA, SSR, SSG e híbridos
- SPA: renderiza toda a árvore React no cliente a partir de um HTML vazio
- SSR: gera HTML dinâmico no servidor a cada requisição
- SSG: pré-geração de HTML estático em build time
- Pode ser combinado com várias linguagens e frameworks (Python/Django, Ruby/Rails, PHP/WordPress etc.)
- Desde por volta de 2015, o padrão era o modelo SPA (renderização no cliente), mas havia trade-offs como velocidade de carregamento inicial, tamanho do bundle JS e diferenças no comportamento nativo do navegador
- O data fetching antes era implementado manualmente em Redux e afins; depois foi simplificado com hooks e bibliotecas dedicadas como React Query/Apollo/SWR/RTK Query
- Frameworks como Next.js e Remix ampliaram o alcance do React ao padronizar SSR, SSG e roteamento por sistema de arquivos, além de estruturar o data fetching
- Houve uma tendência de migração para arquiteturas baseadas em SSR (renderização no servidor, prefetch, code splitting etc.)
- A equipe do React evita o fenômeno de "waterfall de data fetching" e recomenda padrões de melhoria de desempenho como prefetch por rota
-
Situação atual de ferramentas de build e frameworks
- Principais ferramentas/frameworks:
- Next.js (SSR/SSG/RSC/SPA)
- Remix / React-Router v7 (SSR/SSG/SPA)
- Vite (SPA, ferramenta de build, suporte a plugins para vários frameworks)
- Create React App (SPA)
- O Vite começou no ecossistema Vue, mas suporta React, Svelte e muitos outros, com plugin oficial para React e tornando-se padrão de build para frameworks
- Remix/React-Router também vêm migrando recentemente para uma estrutura de suporte a SSR/SSG baseada em Vite
- Resumo das estatísticas de download:
- Next.js lidera com folga em adoção
- O plugin React do Vite cresce rapidamente e é o segundo mais usado
- CRA (
react-scripts) está em queda desde 2023, mas ainda mantém uso considerável
- Remix tem forte boca a boca, mas escala geral limitada; React Router avança lentamente na transição para framework mode
- Gatsby fica bem atrás de Next/Vite/CRA e recentemente até foi ultrapassado pelo Astro (site estático multi-framework)
- Astro não é especializado em React, mas tem escala semelhante à do Remix
- Somando o uso de Vite + CRA, chega-se a um volume equivalente ao do Next → a demanda por SPAs continua alta
Relação entre React Server Components (RSC), o funcionamento interno e os frameworks
-
Contexto de desenvolvimento do RSC e colaboração com a Vercel
- A infraestrutura interna da Meta já tinha sua própria estrutura de servidor, então havia limitações para desenvolver e testar RSC (React Server Components)
- O RSC foi um projeto de visão futura conduzido diretamente pela equipe do React, não partindo de ordens ou exigências da Meta ou da Vercel, mas da visão independente da equipe do React
- A equipe do React apresentou sua visão de RSC à Vercel, e a Vercel entrou como campo de experimentação e apoiadora do desenvolvimento
- Membros centrais do React como Sebastian Markbage e Andrew Clark migraram da Meta para a Vercel, e a equipe do Next.js construiu o App Router (o primeiro caso real de uso de RSC)
- Nesse processo, o Next.js foi praticamente redesenhado e reimplementado do zero
- Outros frameworks como Shopify (Hydrogen) e Remix também tentaram colaborar e testar nas fases iniciais, mas sem participação profunda
- Como resultado, só o Next.js App Router se consolidou como implementação de RSC realmente "pronta para produção", enquanto outros frameworks (React Router, Parcel, Waku etc.) ainda trabalham em integrações, sem o mesmo uso popular
-
Estrutura de integração entre RSC, frameworks e bundlers
- Uma pergunta frequente é: "Por que o RSC precisa necessariamente de framework ou bundler?"
- O SSR tradicional (
renderToString, renderToPipeableStream) pode ser executado em qualquer lugar, mas o RSC é estruturalmente muito mais complexo
- interpretação das diretivas
'use client' e 'use server' no código
- necessidade de automatizar a separação e o registro de componentes de cliente/servidor
- integração estreita com um bundler que analise e compile todo o grafo de módulos (por exemplo, Webpack, Vite etc.) é indispensável
- O core do React fornece apenas a lógica central do RSC e a API de serialização de dados; o funcionamento real, o roteamento e as chamadas a endpoints ficam a cargo do framework
- Cada framework tem sua própria forma de aproveitar, arquitetar e implementar RSC
- O Next.js App Router aplica suas próprias regras de layout e roteamento
- Parcel, Waku, React Router etc. estão introduzindo desenhos diferentes
- Resumo:
- O RSC é um recurso híbrido embutido no core do React, mas o uso prático exige necessariamente integração com bundler/framework
- Só quando o framework oferece suporte é possível aproveitar de fato as vantagens do RSC
Preocupações e confusão na comunidade
-
1. A preocupação de que "a Vercel tomou conta do React"
- Como a Vercel contratou membros importantes da equipe do React e o Next.js foi enfatizado na documentação e nos exemplos, espalhou-se a suspeita de que “a Vercel lidera o desenvolvimento do React”
- Na prática, a equipe do React liderou a visão do RSC e a estrutura do Next App Router, e a Vercel atuou como apoiadora e campo de testes
- Em vez de a Vercel ter "tomado conta" do React, o que houve foi uma parte da equipe central do React migrar para a Vercel para realizar essa visão
-
2. O mal-entendido de que "o React agora só funciona com Next"
- Como apenas o Next.js é destacado como implementação de RSC em produção, esse mal-entendido surgiu
- A documentação oficial do React menciona, além do Next, vários frameworks e também formas de uso sem framework
- O Next é apenas um framework baseado em React; o React continua podendo ser usado sozinho ou com outras ferramentas
-
3. O receio de que "o React possa desaparecer dos apps cliente"
- Com a ênfase em recursos de servidor (RSC, SSR etc.), há quem tema o fim do suporte a SPAs no cliente
- A capacidade de renderização no cliente do React nunca vai desaparecer
- Grandes codebases, como as da Meta, também usam amplamente o modelo cliente
- A equipe do React é muito cuidadosa com compatibilidade e suporte à migração
-
4. "Por que o React força o uso de frameworks?"
- A equipe do React recomenda frameworks por padrão devido às vantagens de produtividade e desempenho em integrar data fetching, roteamento e SSR
- A posição é de que configuração manual (SPA customizada) é ineficiente no longo prazo e frameworks são o padrão da indústria
- Na prática, porém, existem vários padrões de uso, e essa recomendação acabou soando excessivamente uniforme
- SPAs ainda fazem sentido por motivos reais, como barreira de entrada para iniciantes, empresas com restrições de hospedagem em servidor e a simplicidade do hosting de SPA
- O fato de a documentação oficial tratar o caminho "sem framework" como algo secundário gerou sensação de exclusão na comunidade
-
5. Limitações da documentação oficial e polêmica sobre melhorias
- O CRA (
react-scripts) foi oficialmente deprecated, e a demora para mencionar ferramentas substitutas (como Vite) aumentou a confusão
- Abordagens "sem framework", como SPAs, também passaram a ser oficialmente reconhecidas e receberam guias (na documentação mais recente de 2025)
- A comunidade e figuras do ecossistema (como Evan You) também criticaram a demora para haver menção oficial a ferramentas importantes de build, como Vite
- Na documentação mais recente, já melhorada, também são recomendados SPA, Vite/Parcel/RSPack e há guias de escolha para roteadores e data fetching
-
6. Falta de documentação e explicações oficiais sobre RSC
- Em comparação com materiais externos como os da Next.js e da Vercel, faltam explicações conceituais e descrição do RSC na documentação oficial do React
- Há apenas informações fragmentadas na API Reference, sem guia suficiente sobre conceito geral e aplicação
- A comunidade e figuras conhecidas (como Dan Abramov) vêm complementando ativamente essas explicações, mas a falta de formalização continua causando confusão
- Foi levantada a necessidade de incluir seções de documentação sobre conceito, arquitetura, casos de adoção e FAQ de RSC
Resumo das principais preocupações
- O mal-entendido de que a ênfase em frameworks e recursos de servidor existiria "por interesse da Vercel" se enraizou na comunidade, mas na prática isso não corresponde aos fatos
- A comunicação da equipe do React e a forma como a documentação oficial foi escrita ajudaram a ampliar esse mal-entendido
- A renderização no cliente do React continuará existindo; recursos de servidor (RSC/SSR etc.) são apenas opcionais, e abordagens existentes como SPA continuam válidas
- A preocupação e a confusão da comunidade também decorrem em parte da falta de comunicação da equipe do React e de uma atuação insuficiente em DevRel
- É necessário deixar posições oficiais claras, desfazer mal-entendidos e reconhecer/orientar padrões diversos
- A recomendação de "usar frameworks" partiu de boa intenção, mas foi criticada por soar uniforme demais e por marginalizar padrões variados de uso
- Depois de 2025, a documentação oficial melhorou e passou a reconhecer/adicionar guias para SPA e builds customizados, mas levou muito tempo para incorporar o feedback da comunidade
- É necessário reforçar a documentação oficial sobre conceitos centrais do RSC (React Server Components), trade-offs etc.
- Isso ajudaria a comunidade a compreender corretamente o tema e evitar polêmicas desnecessárias
Conclusão
- O texto oferece respostas para várias perguntas sobre como o React evoluiu, sob quais influências e objetivos vem sendo desenvolvido e como os padrões de uso se estabeleceram no ecossistema atual
- A intenção foi dissipar a confusão e o FUD (medo, incerteza e dúvida) em torno da direção e das mudanças na equipe do React
- Mesmo que alguém não concorde com a direção técnica ou não veja necessidade de usar RSC/frameworks grandes, a intenção e a direção da equipe do React são plenamente razoáveis
- As políticas da equipe do React surgiram de boa-fé, com o objetivo de padronizar desempenho e melhorar a UX da comunidade, mas uma comunicação pouco amigável e uma documentação falha ampliaram confusão desnecessária
- Cresce a necessidade de respeitar a diversidade de padrões reais de uso, incluindo SPA, frameworks e várias ferramentas de build, além de melhorar a documentação oficial
- Daqui para frente, incorporar o feedback da comunidade, melhorar a documentação para acolher arquiteturas diversas e manter comunicação aberta será essencial para o desenvolvimento saudável do React
16 comentários
O React passa a sensação de ser uma biblioteca inacabada, meio capenga... Por exemplo, basta ver aquele monte de ressalvas na documentação oficial do
useEffect... só dá para achar absurdo... Ficam abrindo um monte de buracos de coelho assim e a postura é de que você que se vire para usar direito... Muitas vezes dá a impressão de medidas paliativas, feitas sem pensar muito.Vendo os incidentes acontecendo na AWS, pensei de novo... é isso mesmo.
Se você não consegue propor melhorias, então é júnior.
O React Native também está em um clima parecido. Se no React é o Next.js, no React Native é o Expo. A documentação oficial também recomenda usar o framework Expo, e o método antigo via CLI agora ficou difícil de encontrar.
Na verdade, quase não aparecem por aqui questões de desenvolvimento web frontend... ainda assim, o fato de o Next.js estar sendo mencionado tanto ultimamente parece algo fora do normal.
A sensação é de que “só Server Components são o problema; o resto está tudo bem~”.
Esse lado de js fe precisa dar uma extinção geral no ecossistema e resetar tudo de uma vez. E queria que criassem um framework já incluindo de uma vez coisas como gerenciamento de estado. Opções demais? Isso não é liberdade, é só irresponsabilidade.
A questão de os frameworks serem convenientes e a de o próprio React abandonar o CRA parecem problemas de naturezas completamente diferentes. Quando a documentação nova do React já mandou instalar o Next de cara, achei isso meio estranho, então não fui o único a sentir esse incômodo.
Eu achava que a Vercel e a equipe de desenvolvimento do React eram separadas, mas na prática a relação entre elas é bem mais profunda.
Estou fazendo prototipagem de jogos com React quando só preciso de interação de UI, cálculo de estado interno e exibição de estado. Comparado a alguns anos atrás, quando o create-react-app estava quase sendo removido da documentação oficial, senti que recentemente ficou um pouco mais difícil configurar tudo apenas consultando a documentação oficial. Acho que o texto que escrevi naquela época pode ter alguma relação com isso.
Parece que o fato em si de o RSC ter sido desenvolvido desde o início com base no Next.js não muda.
Se juntar isso ao fato de que o Next.js vem engasgando cada vez mais em ambientes fora da Vercel,
mesmo sem saber exatamente o que o time do React pensa internamente, a linha de raciocínio acaba ficando: RSC é o futuro! Mas, para rodar RSC, recomendam Next.js, e o Next.js use na Vercel. Aí, se isso não tem relação com os interesses da Vercel, bem...
Por mais que insistam que é um mal-entendido, no fim as pessoas inevitavelmente sentem que a Vercel engoliu o React, e também não foi como se tivessem respondido rápido para desfazer esse mal-entendido, não é?
Neste momento, o site oficial do React está rodando na Vercel, não em servidores da Meta.
Concordo.
O Svelte, no qual a Vercel também investe, talvez por ter uma escala menor, não me pareceu ter casos assim de vendor lock-in, então também fiquei curioso sobre qual seria a diferença.
O Svelte é apenas patrocinado pela Vercel; não é liderado pela Vercel. Já o Next é efetivamente liderado pela Vercel.
Mesmo no caso do repositório no GitHub, o Next fica sob a organização da Vercel, mas o Svelte não.
E no caso do Next.js, a Vercel aparece no copyright no rodapé do site oficial, enquanto no Svelte isso não acontece.
Então a Vercel contratou o Rich Harris como uma forma de patrocínio.
https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte Sim, é uma contratação com um forte caráter de patrocínio. Basicamente, estão pagando um salário para que ele possa se dedicar em tempo integral ao desenvolvimento do Svelte. A própria Vercel também deixou claro que o Svelte continua sendo um projeto independente.