-
Framework: Next.js vs Vite vs Remix vs TanStack Start
- Next.js: escolha para SSR/SSG, apps críticos para SEO ou quando você deseja uma configuração full-stack "tudo incluído" com App Router e React Server Components.
- Vite: escolha para SPAs puras, ferramentas internas ou dashboards onde o HMR rápido de desenvolvimento é mais importante que o SSR.
- Remix: escolha quando você deseja roteamento aninhado com foco em fundamentos web, loaders/actions e melhoria progressiva integradas.
- TanStack Start: escolha quando você deseja roteamento type-safe com SSR, mas com mais flexibilidade que o Next.js.
-
Estratégia de Renderização: SSR vs SSG vs CSR vs ISR
- SSR: páginas voltadas para o público com personalização por requisição ou dados que mudam frequentemente.
- SSG: sites de marketing, docs ou blogs onde o conteúdo muda raramente e você deseja hospedagem barata em CDN.
- CSR: shells de aplicativos autenticados atrás de um login onde o SEO não importa.
- ISR: sites híbridos com conteúdo majoritariamente estático, mas com revalidação ocasional em segundo plano (ex: catálogos de e-commerce).
-
Linguagem: TypeScript vs JavaScript
- TypeScript: padrão para qualquer equipe ou app não trivial; captura bugs no tempo de compilação e torna refatorações mais seguras.
- JavaScript: apenas para protótipos minúsculos, demos descartáveis ou quando os contribuidores não têm familiaridade com TS.
-
Gerenciador de Pacotes: pnpm vs npm vs yarn vs bun
- pnpm: monorepos e projetos sensíveis ao espaço em disco e velocidade de instalação, graças ao seu store baseado em conteúdo endereçável.
- npm: zero configuração, vem com o Node, compatibilidade máxima com tutoriais e exemplos de CI.
- yarn: configurações existentes de yarn berry (PnP) ou equipes já comprometidas com yarn workspaces.
- bun: projetos greenfield que priorizam velocidade bruta de instalação/execução e estão dispostos a aceitar um ecossistema mais jovem.
-
Estrutura do Repositório: Monorepo (Turborepo/Nx) vs Polyrepo
- Monorepo: múltiplos apps compartilhando componentes de UI, tipos ou utilitários (web + mobile + dashboard de administração).
- Polyrepo: app único, equipe pequena ou limites de propriedade estritos entre serviços.
-
Roteamento: Baseado em Arquivo vs React Router vs TanStack Router
- Baseado em Arquivo (Next/TanStack): convenção sobre configuração; rotas mapeiam para o sistema de arquivos, ótimo para padronização.
- React Router: SPAs onde você deseja controle programático total e uma API madura e familiar.
- TanStack Router: você precisa de rotas totalmente type-safe com validação de parâmetros de busca e busca de dados baseada em loader.
-
Gerenciamento de Estado do Cliente: Zustand vs Redux Toolkit vs Jotai vs Context API
- Zustand: boilerplate mínimo, bom padrão para a maioria dos apps que precisam de estado compartilhado.
- Redux Toolkit: apps grandes com máquinas de estado complexas, depuração time-travel ou memória muscular Redux existente.
- Jotai: estado que é naturalmente atômico e derivado - bom para formulários complexos ou estado semelhante a um grafo.
- Context API: valores verdadeiramente globais, que mudam raramente, como tema ou usuário de autenticação; evite para qualquer coisa que atualiza com frequência.
-
Estado do Servidor / Busca de Dados: TanStack Query vs SWR vs RTK Query vs Apollo
- TanStack Query: padrão para REST - caching, mutations, devtools, agnóstico de framework.
- SWR: API mais simples, leve, fortemente integrado se você estiver no ecossistema Vercel.
- RTK Query: já usando Redux Toolkit e deseja busca de dados na mesma store.
- Apollo: GraphQL com caching normalizado, atualizações otimistas e subscriptions.
-
Abordagem de Estilização: Tailwind vs CSS Modules vs styled-components vs vanilla-extract
- Tailwind: iteração rápida, tokens de design consistentes, combina bem com shadcn/ui.
- CSS Modules: você deseja CSS simples com escopo, sem runtime e sem novo DSL para aprender.
- styled-components: temas dinâmicos e CSS-in-JS co-localizado, aceitando o custo de runtime.
- vanilla-extract: CSS-in-TS type-safe, sem runtime para autores de design systems.
-
Biblioteca de Componentes: shadcn/ui vs MUI vs Chakra vs Radix + custom
- shadcn/ui: você deseja componentes totalmente de sua propriedade, copiados e colados, construídos sobre Radix + Tailwind.
- MUI: apps corporativos que precisam de componentes abrangentes no estilo Material "out of the box".
- Chakra: componentes acessíveis e temáticos com uma API amigável baseada em props.
- Radix + custom: você deseja primitivas headless e acessíveis e uma identidade visual totalmente personalizada.
-
Formulários: React Hook Form vs TanStack Form vs Formik
- React Hook Form: escolha padrão - performático, não controlado, combina bem com resolvedores Zod.
- TanStack Form: profundamente type-safe com validação de campos de primeira classe assíncrona e arrays de campos.
- Formik: apenas para projetos legados que já o utilizam; geralmente não recomendado para novos trabalhos.
-
Validação de Schema: Zod vs Valibot vs Yup
- Zod: padrão de fato; ótima inferência de TS, ampla integração com ecossistema (RHF, tRPC, etc.).
- Valibot: apps sensíveis ao tamanho do bundle - modular e tree-shakable com ergonomia semelhante ao Zod.
- Yup: projetos Formik existentes ou se você prefere seu estilo de validação "async-first".
-
Camada de API: REST vs GraphQL vs tRPC
- REST: APIs públicas, compatibilidade máxima com clientes, ou necessidades simples de CRUD.
- GraphQL: múltiplos clientes com necessidades de dados divergentes e queries aninhadas complexas.
- tRPC: projeto TypeScript full-stack onde a API é consumida apenas por seus próprios clientes.
-
Autenticação: Auth.js vs Clerk vs Auth0 vs custom
- Auth.js (NextAuth): open-source, auto-hospedado, muitos provedores OAuth "out of the box" para Next.js.
- Clerk: UI drop-in, dashboards de gerenciamento de usuários, e você está feliz em pagar pela velocidade.
- Auth0: SSO corporativo, SAML e requisitos de conformidade.
- Custom: fluxos de autenticação incomuns ou requisitos estritos de residência de dados que excluem terceiros.
-
Testes Unitários/Integração: Vitest vs Jest
- Vitest: projetos baseados em Vite e qualquer um que queira um runner mais rápido, nativo de ESM, com API compatível com Jest.
- Jest: grandes suítes de testes existentes, Next.js sem Vite, ou ferramentas que especificamente assumem Jest.
-
Testes E2E: Playwright vs Cypress
- Playwright: cobertura multi-browser (WebKit/Firefox), paralelismo e DX moderno - recomendação padrão.
- Cypress: depuração time-travel intensiva e uma UI mais rica para diagnóstico de testes instáveis.
-
Linting & Formatação: ESLint + Prettier vs Biome
- ESLint + Prettier: ecossistema maduro com plugins para todos os frameworks e regras imagináveis.
- Biome: projetos greenfield que desejam uma única ferramenta rápida baseada em Rust para linting e formatação.
-
Estrutura de Pastas: Baseada em Feature vs Baseada em Tipo vs Atomic Design
- Baseada em Feature: co-localiza todo o código por feature de domínio - escala melhor à medida que os apps crescem.
- Baseada em Tipo (components/, hooks/, etc.): serve para apps pequenos, mas doloroso após ~20 features.
- Atomic Design: apps com forte foco em design system onde primitivas de UI reutilizáveis são a preocupação principal.
-
Estratégia de Code Splitting: Carregamento lazy por nível de rota vs por nível de componente
- Nível de rota: padrão; divide nas fronteiras das páginas para os melhores ganhos de TTI com esforço mínimo.
- Nível de componente: widgets pesados específicos (gráficos, editores ricos, mapas) que são renderizados condicionalmente.
-
Monitoramento de Erros: Sentry vs LogRocket vs Datadog
- Sentry: rastreamento de erros "best-in-class" com source maps, releases e monitoramento de performance.
- LogRocket: você precisa de replay de sessão junto com erros para depurar problemas de UX.
- Datadog: você já está padronizado nele para observabilidade de backend e deseja um painel único.
-
Análises: PostHog vs Google Analytics vs Plausible vs Mixpanel
- PostHog: análises de produto com feature flags, replay de sessão e opção de auto-hospedagem.
- Google Analytics: gratuito, ubíquo e suficiente para métricas de marketing/tráfego.
- Plausible: leve, focado em privacidade, sem cookies - bom para conformidade com a UE.
- Mixpanel: análise de funis e coortes para equipes de produto que vivem em dados de eventos.
-
CI/CD: GitHub Actions vs GitLab CI vs CircleCI
- GitHub Actions: padrão se seu repositório estiver no GitHub - integração profunda e um enorme marketplace.
- GitLab CI: sua origem está no GitLab; integração Auto DevOps profunda.
- CircleCI: equipes que desejam primitivas de paralelismo poderosas e caching maduro "out of the box".
-
Hospedagem / Deploy: Vercel vs Netlify vs AWS vs Cloudflare Pages
- Vercel: apps Next.js - suporte de primeira parte, edge runtime, deploys de preview.
- Netlify: sites Jamstack, serverless functions e um generoso tier gratuito.
- AWS: você precisa de controle total, VPCs personalizadas ou já vive na AWS.
- Cloudflare Pages: apps "edge-first", preços agressivos e integração profunda com Workers.
-
Gerenciamento de Variáveis de Ambiente: arquivos .env vs Doppler vs AWS Secrets Manager
- arquivos .env: projetos simples com poucos segredos e desenvolvedores confiáveis.
- Doppler: equipes que precisam de sincronização de segredos compartilhados e auditados entre ambientes sem a complexidade da AWS.
- AWS Secrets Manager: stacks nativas da AWS com rotação, políticas IAM e necessidades de conformidade.
-
Internacionalização (i18n): next-intl vs react-i18next vs Lingui
- next-intl: Next.js App Router com suporte de primeira classe para RSC.
- react-i18next: maduro, agnóstico de framework, enorme ecossistema de plugins.
- Lingui: extração de mensagens em tempo de compilação e um runtime menor, baseado em ICU.
-
Animação: Framer Motion vs React Spring vs CSS/Tailwind
- Framer Motion: animações declarativas, gestos e animações de layout com código mínimo.
- React Spring: animações baseadas em física e controle granular.
- CSS/Tailwind: transições simples e efeitos hover - sem custo de runtime de JS.
-
Sistema de Ícones: Lucide vs Heroicons vs sprites SVG customizados
- Lucide: o maior conjunto de ícones modernos com componentes React tree-shakable.
- Heroicons: limpo, alinhado com Tailwind, combina bem com shadcn/ui.
- Sprites SVG customizados: iconografia específica da marca ou orçamentos de tamanho de bundle estritos.
-
Manipulação de Data/Hora: date-fns vs Day.js vs Luxon vs Temporal
- date-fns: utilitários funcionais tree-shakable; escolha padrão para a maioria dos apps.
- Day.js: API semelhante ao Moment em um bundle minúsculo - bom para migrações rápidas do Moment.
- Luxon: necessidades pesadas de fuso horário e calendário, construído sobre Intl.
- Temporal (polyfill): você quer o padrão futuro hoje e está ok em enviar o polyfill.
-
Documentação de Componentes: Storybook vs Ladle vs nenhum
- Storybook: design system ou biblioteca de componentes compartilhada consumida por múltiplas equipes.
- Ladle: alternativa mais rápida baseada em Vite para catálogos de componentes mais simples.
- Nenhum: produtos em estágio inicial onde os componentes mudam diariamente e a documentação decai mais rápido do que ajuda.
-
Otimização de Imagens: next/image vs Cloudinary vs custom (Sharp + CDN)
- next/image: projetos Next.js - redimensionamento automático, carregamento lazy e negociação de formato.
- Cloudinary: você precisa de transformações "on-the-fly", entrega via CDN e trabalha em frameworks não-Next.
- Custom (Sharp + CDN): controle total, sensível a custos em escala, ou pipelines de imagem altamente específicos.