Stack frontend para solo founder: como escolher Astro, Next.js, React, Tailwind e shadcn/ui

O projeto tem quatro superfícies: /blog, /tools/image-resizer, /dashboard/settings e /pricing. Colocar tudo em Next.js ou separar o blog Astro do painel Next.js? Um blog Astro passa a precisar de login, pagamento e histórico; enquanto isso, um projeto Next.js com apenas vinte artigos Markdown já exige entender cache, Server/Client Components e implantação.

Escolher o frontend de uma empresa de uma pessoa não é eleger o melhor framework. Tipo de página, dados dinâmicos e custo de manutenção determinam o framework, o limite do repositório e a responsabilidade pelo código copiado do shadcn/ui. A decisão real é quando islands bastam, quando o App Router custa mais do que entrega e quando React + Vite é mais simples.

Backend, implantação, banco, pagamentos e autenticação ficam para os próximos artigos.

Tabela de decisão de frameworks

Comece pelo tipo de página, não pela popularidade.

Várias superfícies no mesmo produto

Com cerca de 80% de conteúdo e 20% de painel, Astro pode continuar como app principal; o painel pode usar islands React ou um app Next.js separado.

Com 80% de aplicação e 20% de blog, Next.js pode carregar o produto e gerar o blog estaticamente.

Em uma divisão 50/50, um app Astro para conteúdo e outro Next.js para painel criam um limite claro. Um monorepo pode preservar essa divisão.

Dois apps aumentam dependências e implantação, mas impedem que regras de cache de uma superfície afetem todas.

Alerta sobre custo de manutenção

Cache do Next.js, limites Server/Client e diferenças entre Vercel, Cloudflare e servidor próprio precisam de validação. Com poucas páginas dinâmicas, Astro ou React + Vite podem custar menos.

O comparativo Astro vs Next.js aprofunda a arquitetura.

Sites de conteúdo: Astro e a arquitetura Islands

Astro atende blogs, documentação, marketing e outros sites orientados a conteúdo. Server-first e zero JS by default significam que o HTML nasce no build ou servidor; só componentes marcados como interativos carregam JavaScript cliente.

Content collections organizam, validam e tipam Markdown ou dados estruturados. Frontmatter e consultas por data, tag ou categoria podem ser verificados no build.

Islands: HTML estático e interação local

A maior parte da página fica em HTML. Uma área interativa vira island, e client:load ou client:visible define quando ela carrega.

Um botão de envio pode ser o único componente React com client:load.

Um seletor de tema pode ler localStorage e alterar variáveis CSS.

Um visualizador de imagens pode esperar por client:visible.

Assim não é necessário hidratar a página inteira por causa de um formulário ou ferramenta pequena.

Quando Astro não deve carregar tudo

Se quase toda rota verifica identidade, carrega dados privados, compartilha muito estado ou exige rotas cliente complexas, Astro deixa de ser o início óbvio. Um painel cheio de islands autenticadas costuma ficar mais claro em Next.js ou em um app React próprio.

O caso Astro 5 e Lighthouse mostra collections e islands em um site real.

Ferramentas e produtos interativos: React + Vite vs Next.js

Uma ferramenta costuma concentrar uma ação; um produto interativo acrescenta rotas, estado compartilhado, colaboração ou editor.

Quando React + Vite funciona

React + Vite serve para SPA cliente ou ferramenta independente sem renderização no servidor.

Um compressor processa arquivos no navegador.

Um formatador JSON analisa a entrada localmente.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Um editor Markdown combina edição, prévia e localStorage.

Implantação estática e ausência das fronteiras de cache do Next.js simplificam o sistema. Se busca for central, uma SPA cliente exige estratégia explícita de SEO.

Quando Next.js funciona

Next.js é útil com renderização no servidor, várias rotas ou renderização mista.

Início, ferramenta e resultado podem ter rotas renderizadas.

Páginas explicativas podem ser indexadas por SSG ou SSR.

A apresentação pode ser estática e os resultados privados, dinâmicos.

Condições para escolher React + Vite

A ação principal usa Browser APIs, localStorage ou Canvas.

A ferramenta deve ser implantada como arquivos estáticos sem Node.js.

Não precisa de routing, cache ou SSR do Next.js.

Um limite claro entre cliente e backend é mais fácil de manter.

Se busca e rotas servidor forem centrais, seu benefício deve pagar a complexidade extra.

React 19 Actions aprofunda formulários e ações assíncronas.

Painéis SaaS: Server e Client Components do Next.js

App Router separa trabalho do servidor e interação no navegador. 'use client' marca o limite cliente.

Server Components vs Client Components

Server Components executam no servidor ou build sem adicionar sua lógica ao bundle JavaScript do navegador.

Servem para conteúdo estático, consultas ao banco e API.

Não podem usar localStorage, window, useState, useEffect ou onClick.

Client Components executam no navegador e lidam com interação, estado e Browser APIs.

Servem para formulários, botões e atualizações ao vivo.

O arquivo de limite declara 'use client'.

Um Server Component pode importar um Client Component. O cliente não importa diretamente um Server Component, embora possa receber conteúdo renderizado no servidor.

Casos de uso no painel SaaS

App Router combina com autenticação, dados dinâmicos e muitos formulários.

Configurações leem dados do usuário e salvam preferências.

Pedidos mostram listas, detalhes e mudanças de estado.

Analytics carregam dados protegidos no servidor e gráficos interativos no navegador.

O acesso direto à camada de dados ajuda quando identidade e permissões são centrais.

Alerta sobre custo de manutenção

Renderização estática ou dinâmica, revalidate, limites e runtime devem corresponder à versão usada. Documentação atual vale mais que exemplos antigos.

Com poucas páginas dinâmicas, React + Vite e um backend Node.js ou Supabase separado podem ser mais simples.

A série App Router cobre routing, migração, Middleware, Auth e Dark Mode separadamente.

Camada de estilos: Tailwind e utility-first

Utility-first combina classes pequenas em HTML ou JSX. Em <div class="bg-blue-500 text-white p-4 rounded-lg">, cada classe controla uma propriedade.

Tailwind é uma camada de colaboração, não substituto para design.

Reduz a necessidade de nomear classes CSS.

Mantém estilo perto do markup usado.

Dá a pessoas e agentes um vocabulário comum para alterar a interface.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Tailwind não produz qualidade de design

Cores, tipografia, espaçamento e raios precisam de regras consistentes.

Tokens do produto são melhores que utilities aleatórias.

Combinações repetidas de botões, cartões e linhas devem virar componentes.

Sem limites, o markup fica denso sem tornar o produto coerente.

Tailwind independe do framework

Tailwind funciona com Astro, Next.js e React + Vite. O caminho Vite atual do Tailwind CSS v4 usa @tailwindcss/vite e @import "tailwindcss";; Astro pode usar o mesmo plugin. Confira o guia oficial ao implementar.

Camada de componentes: propriedade e integração do shadcn/ui

shadcn/ui não esconde uma implementação fixa em pacote tradicional. Sua CLI copia o código para o projeto, que passa a mantê-lo.

O projeto possui o código

Atualizações upstream não modificam cópias automaticamente.

Teclado, ARIA e leitores de tela devem ser testados nas combinações reais.

Cores, raios e espaçamento devem alinhar com o design system.

Validação, envio e lógica de negócio continuam na aplicação.

Código visível e editável é a vantagem; atualizações, acessibilidade, tema e estados são a responsabilidade.

shadcn/ui e Tailwind

Os guias atuais para Astro e Next.js pressupõem Tailwind. Tailwind fornece a linguagem visual; shadcn/ui, o código-fonte mantido pelo projeto.

Casos adequados

Painéis, configurações e páginas com formulários aproveitam Button, Input, Select, Dialog e Table.

Configurações reutilizam controles e erros.

Cadastro, login e checkout usam primitives, mas a aplicação mantém validação e estado.

Uma biblioteca existente ou design system completo reduz a vantagem.

Integração com Astro

Componentes React precisam da integração React.

Tailwind fornece os estilos.

Eles servem a formulários e diálogos locais, não a transformar todo conteúdo em app React.

O template oficial configura Tailwind e React; reveja os passos da CLI.

Integração com Next.js

shadcn/ui oferece template Next.js e caminho para projetos existentes.

Cada componente deve ficar no lado Server/Client adequado. Não é preciso converter a página inteira em Client Component.

CLI, presets e registry podem mudar.

Quando não usar shadcn/ui

Quando é necessário um design system completo, não primitives.

Quando o projeto não quer manter código, atualizações, acessibilidade e tema.

Quando Ant Design, Material UI ou biblioteca interna já atende.

Quando um site de conteúdo quase não usa formulários ou painel.

O custo real de manutenção para solo founders

Tipo de página e dados não bastam: complexidade do framework, propriedade de componentes e revisão de código gerado por IA definem o trabalho de longo prazo.

Manutenção do Next.js

Uma diferença entre intenção e regras de renderização ou cache pode entregar dados antigos.

Limites Server/Client decidem onde vivem estado e acesso a dados.

Vercel, Cloudflare e runtime Node.js próprio devem ser avaliados separadamente.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Em páginas principalmente estáticas, esse custo pode superar o benefício.

Manutenção do shadcn/ui

Correções e atualizações upstream precisam de revisão.

Teclado, ARIA e leitores de tela exigem testes do produto.

Cores, densidade e espaçamento seguem os tokens.

Validação, envio e estado continuam próprios.

Se essa responsabilidade não for desejada, uma biblioteca empacotada ou poucas primitives internas fazem mais sentido.

Revisar frontend gerado por IA

Há muitos exemplos de React, Next.js e shadcn/ui, mas a validação continua.

Um agente pode criar camadas Server/Client demais.

Pode aplicar cache incompatível com versão ou rota.

Pode ignorar tokens e estados de interação.

IA reduz digitação, não revisão de arquitetura, acessibilidade e visual.

Vários frameworks no mesmo produto

Astro para conteúdo e Next.js para painel deixam o limite claro, mas adicionam dependências, configuração e CI/CD para dois apps.

Também é preciso operar rotas como blog.example.com e app.example.com.

Ambos podem viver em monorepo. Produto focado em conteúdo fica majoritariamente em Astro; focado em app, em Next.js; equilibrado usa dois limites explícitos.

Próximos passos e leituras

Artigos publicados

Escolher framework de blog compara Hugo, Astro e Hexo.

Astro 5 e Lighthouse 100 trata collections, islands e desempenho.

Astro vs Next.js compara arquitetura e renderização.

React 19 Actions aprofunda formulários e operações assíncronas.

Série Next.js App Router

Routing, migração, Middleware, Auth e Dark Mode aparecem em artigos separados para painéis SaaS.

Próximos artigos da série

Este é o quinto artigo de Solo Founder Tech Stack. Os próximos comparam Node.js, Python, Go, Supabase e APIs próprias.

Também cobrem Cloudflare, Vercel, servidores próprios e contêineres.

Os bancos comparados incluem PostgreSQL, Supabase, PlanetScale e MongoDB.

A autenticação compara serviços gerenciados e soluções próprias.

Depois de classificar as páginas, backend e implantação devem sustentar o limite frontend escolhido.