React ou Astro: como escolher a stack certa pro seu projeto

O erro comum

“Qual framework usar?” é a pergunta errada. A pergunta certa é: o que o projeto precisa fazer?

Framework é ferramenta. Chave de fenda não é melhor que martelo. Depende se você tá apertando parafuso ou pregando prego. E usar martelo pra apertar parafuso, por mais que funcione, deixa marca.

Esse post é pra devs que estão decidindo entre React e Astro, e pra donos de empresa que querem entender por que o dev recomendou uma stack específica. Os critérios são práticos, baseados em projetos reais que já entreguei nos dois.

Já vi cliente pagar R$ 15k num site institucional feito em React que carregava 350 KB de JS pra mostrar 5 páginas de texto e imagem. Lighthouse 60, ranqueamento fraco, taxa de rejeição alta no mobile. Não era problema do dev, era problema da escolha de ferramenta. O dev sabia React e usou React. Só que o projeto não pedia React.

Quando usar Astro

Astro é framework pra conteúdo. Gera HTML estático no build e envia zero JavaScript pro navegador por padrão. O resultado é um site que carrega instantaneamente, indexa perfeitamente no Google, e bate Lighthouse 95+ sem configuração especial.

Use Astro quando:

• O conteúdo da página não muda depois que carrega. É o mesmo pra todo visitante
• SEO é prioridade. O site precisa ranquear no Google
• Não tem formulário complexo, estado compartilhado ou interação pesada
• Precisa carregar rápido em qualquer conexão, incluindo 3G
• O projeto é site institucional, landing page, blog ou portfólio

Projetos que fiz em Astro: Family Pilates (LP boutique com SEO local), GPM2 (institucional premium pra consultoria tributária), Tok Final (institucional B2B pra construtoras), Soline (energia renovável com dados técnicos densos), Carrega Rápido (LP pra startup de mobilidade elétrica), Laura Nasralla (veterinária com SEO local). Todos com Lighthouse 95+ e zero JS no cliente.

O que Astro faz de diferente

A maioria dos frameworks (Next.js, Nuxt, SvelteKit) parte do princípio que você precisa de JavaScript no cliente e te dá formas de reduzir. Astro inverte: parte do princípio que você não precisa e te dá formas de adicionar.

O resultado prático: num site de 8 páginas em Astro, o navegador recebe 8 arquivos HTML e zero JavaScript. O mesmo site em Next.js recebe 8 páginas HTML + 70-300 KB de JavaScript pra hydration, roteamento e runtime do React. No 3G de quem acessa pelo celular no interior do Brasil, esses 200 KB extras significam 3-5 segundos a mais de carregamento. Pra um site institucional, isso é visita perdida.

Por que escolhi Astro ao invés de Next.js tem os números detalhados de cada projeto.

Islands Architecture

Quando uma parte da página precisa de interatividade (carrossel, formulário com validação, componente com estado), Astro permite hidratar só aquele componente. É o padrão Islands Architecture.

No Family Pilates, a única ilha é o carrossel de depoimentos. Carrega 12 KB de JavaScript. O resto da página (hero, serviços, sobre, CTA) continua estático. Em Next.js, o framework inteiro hidrataria mesmo as partes estáticas.

A diretiva funciona assim:

• client:load hidrata imediatamente (formulário que precisa funcionar logo)
• client:visible hidrata quando entra no viewport (carrossel que tá no meio da página)
• client:idle hidrata quando o browser tá ocioso (componente não urgente)

Sem diretiva = HTML estático. Sem JavaScript. Sem hydration.

Onde Astro não serve

Aplicações com login, estado compartilhado entre componentes, navegação interna tipo SPA, dados em tempo real, formulários com múltiplas etapas e validação complexa. Tudo isso precisa de JavaScript no cliente. Astro pode fazer, mas não é pra isso. É como usar chave de fenda pra pregar: funciona se forçar, mas o resultado é feio.

Eu já tentei. Num projeto de teste, fiz um mini painel admin em Astro com ilhas React pra cada parte interativa. Cada navegação entre páginas recarregava tudo, o estado se perdia entre rotas, e a experiência ficou lenta e fragmentada. O mesmo painel em React puro ficou fluido, manteve estado entre telas e respondeu rápido a cada clique. Ferramenta certa pro trabalho certo.

Quando usar React

React é biblioteca pra interfaces interativas. Webapps, dashboards, painéis admin, SaaS, qualquer coisa que tenha estado, formulários complexos e atualização em tempo real.

Use React quando:

• O usuário faz login e tem sessão
• Tem formulários com validação, etapas ou lógica condicional
• Dados mudam em tempo real (notificações, chat, status de pedido, dashboard)
• Múltiplas telas com navegação interna (sidebar, tabs, rotas aninhadas)
• O sistema precisa de gerenciamento de estado (carrinho, filtros persistentes, preferências)

Projetos que fiz em React: AutoPars (marketplace com 3 painéis, 5 integrações, dashboard admin com métricas em tempo real), Mariah (controle de encomendas com dashboard financeiro e filtros por período), FitPlan (plataforma pra academias com 6 painéis, treinos, nutrição e marketplace).

React + TypeScript + Supabase

Minha stack padrão pra webapps é React + TypeScript + Supabase + Tailwind. O TypeScript pega erros de tipo antes de ir pra produção. O Supabase entrega auth, banco PostgreSQL, storage e realtime sem precisar montar backend do zero. O Tailwind acelera a UI.

Essa combinação me permite entregar MVP em 4-8 semanas trabalhando solo. O Supabase elimina semanas de setup de backend. O React dá flexibilidade pra qualquer tipo de interface. Hooks como useState, useEffect e custom hooks pra lógica de negócio mantêm o código organizado mesmo quando o sistema cresce pra 50+ componentes.

Onde React não serve (pra sites)

Site estático de 5 páginas. Landing page de conversão. Blog. Portfólio. Funciona? Sim. É a melhor escolha? Não.

React mandando 200+ KB de JavaScript pra renderizar texto e imagens é desperdício. O visitante paga com tempo de carregamento, o Google penaliza com nota menor no Lighthouse, e o SEO sofre porque SPA precisa de configuração extra pra ser indexada.

É por isso que o AutoPars (SPA React) precisou de uma LP separada em Astro como camada de SEO. A SPA não indexa bem sozinha. A LP em Astro resolve.

Quando o projeto precisa dos dois

Acontece mais do que parece. E a resposta não é “escolhe um e adapta”. É usar cada um onde faz sentido.

Dois projetos separados

O AutoPars: marketplace em React (app.autopars.com) + LP de captação em Astro (autopars.com). Dois repositórios, dois deploys, cada um na stack certa. O React cuida da interatividade do marketplace. O Astro cuida do SEO e da captação orgânica.

Astro com ilhas React

Site institucional em Astro com uma área interativa. O Astro suporta componentes React nativamente. O site é estático, e a parte interativa (formulário avançado, mini-dashboard, calculadora) é uma ilha React que hidrata só onde precisa.

Esse padrão é ideal quando 90% do site é conteúdo estático e 10% precisa de interatividade. Em vez de carregar React pra página inteira por causa de 10%, carrega só no componente que precisa.

Comparativo direto

	Astro	React
Tipo de projeto	Sites, LPs, blogs, portfólios	Webapps, dashboards, SaaS, painéis
JS no cliente	Zero por padrão	Sempre presente
SEO	Nativo, HTML estático	Precisa de SSR/SSG ou LP separada
Performance	Lighthouse 95+ sem esforço	Depende de otimização manual
Estado/interação	Limitado (Islands pra exceções)	Total
Tempo real	Não	Sim (WebSocket, polling)
Autenticação	Possível mas não ideal	Nativo
Curva de aprendizado	Baixa (HTML-first)	Média-alta (hooks, state, effects)
Ecossistema	Crescendo rápido	Maduro, enorme

Como eu decido

Três perguntas, nessa ordem:

O usuário faz login? Se sim, React. Sistema com autenticação, sessão e dados por usuário é território do React. Astro até suporta, mas não é o caminho natural.

O conteúdo muda depois que a página carrega? Se dados atualizam em tempo real, se tem formulários com estado, se a interface reage a ações do usuário, React. Se a página é a mesma pra todo mundo que acessa, Astro.

SEO é prioridade? Se sim, Astro ganha por padrão. HTML estático, meta tags no build, Schema.org nativo, zero configuração de SSR. React precisa de Next.js com SSR/SSG pra competir, e ainda assim carrega mais JS.

Se respondeu “não” pras três, é site estático. Astro. Se respondeu “sim” pra qualquer uma das duas primeiras, é webapp. React.

Na dúvida, começo pelo mais simples. Começar com React pra fazer site estático é desperdício de complexidade. Migrar de Astro pra React quando o projeto cresce é mais fácil do que otimizar React pra algo que deveria ser estático desde o início.

Pra devs que só conhecem React

Se você aprendeu React e usa pra tudo, recomendo testar Astro num projeto pessoal. A curva de aprendizado é baixa (1-2 dias pra se sentir produtivo), a sintaxe é familiar (parece JSX com frontmatter), e a experiência de ver Lighthouse 100 sem esforço muda a perspectiva.

Você não precisa abandonar React. Precisa ter duas ferramentas na caixa em vez de uma. O martelo e a chave de fenda.

Eu mesmo fiz essa transição. Antes usava Next.js pra tudo, incluindo sites estáticos. Quando testei Astro, percebi quanto JavaScript desnecessário tava mandando pro navegador em projetos que não precisavam. O build ficava mais rápido, o deploy mais leve, e o Lighthouse batia 100 sem nenhuma otimização manual. Hoje, quando começo um projeto novo, a primeira decisão é: isso é conteúdo ou é aplicação? A resposta define a stack em 30 segundos.