MÓDULO 2.2

⚖️ GSAP × Framer Motion

Controle preciso de timeline vs. física reativa. Uma comparação direta para você sempre escolher a ferramenta certa — e entender por que GSAP vence no contexto de vídeo renderizado.

6
Tópicos
~35
Minutos
Intermediário
⚖️
Comparativo
1

🎯 Dois paradigmas completamente diferentes

GSAP e Framer Motion não competem — eles servem a contextos opostos. Um é construído para controle máximo de tempo; o outro para reagir ao usuário. Entender essa diferença fundamental evita horas de frustração.

🟢 GSAP — paradigma de tempo

  • Baseado em timeline absoluta — t=0 sempre igual.
  • Seek() para qualquer ponto no tempo.
  • Frame renderizado ≡ frame no vídeo final.

⚛️ Framer Motion — paradigma de estado

  • Baseado em física — spring, inertia, drag.
  • Animações disparam em resposta a interações.
  • Resultado depende do timing do usuário — não determinístico.
GSAP
Tempo absoluto
Framer
Estado + física
Vídeo
GSAP vence
UI web
Framer brilha
2

📊 Matriz de decisão

Use esta tabela como referência rápida. Antes de escolher a biblioteca, identifique o contexto de consumo: vídeo renderizado (MP4) ou interface interativa (browser/app).

Critério GSAP Framer Motion
Vídeo renderizado (Remotion) ✓ Ideal ✗ Não funciona
Animação determinística ✓ Nativo ✗ Depende de interação
Hover / drag / gestos Possível, mas verboso ✓ Nativo e elegante
Prototipagem de UI Pode ser usado ✓ Muito mais rápido
Layout animations (reflow) Manual ✓ AnimatePresence
Seek em frame específico ✓ tl.seek() ✗ Não existe
Timeline coreografada ✓ Core feature Possível, mas limitado
Performance no browser ✓ Excelente ✓ Muito boa
Vídeo MP4
Sempre GSAP
App React
Framer ou ambos
Protótipo
Framer vence
Apresentação
Sempre GSAP
3

🎬 Demonstração lado a lado

À esquerda: timeline coreografada (GSAP) — A termina, B começa, C sobrepõe. À direita: card "reativo" (estilo Framer Motion) — loop de hover/scale que não faz sentido em vídeo renderizado, pois ninguém vai fazer hover num MP4.

demonstração ao vivo
GSAP — timeline A→B→C
A — título
entra da esquerda
B — subtítulo
sobe de baixo (0.3s depois)
C — CTA
escala in (sobrepõe B)

✓ Determinístico — mesmo resultado em qualquer render

Framer Motion — card reativo
🖱️
whileHover
scale: 1.06

✗ Hover não existe em MP4 — esse padrão não gera vídeo

💡 A regra de ouro

Se o seu produto final é um arquivo de vídeo, use GSAP. Se é uma interface que o usuário vai interagir, Framer Motion economiza código.

A→B→C
Timeline encadeada
whileHover
Requer interação
seek()
Salta para frame
spring
Físico, não linear
4

🔬 Por que GSAP é frame-based determinístico

O Remotion renderiza frames de forma headless: ele "congela" o tempo em cada frame, tira um screenshot e passa para o próximo. Para isso funcionar, o estado visual deve ser 100% dependente do número do frame — nunca do relógio do sistema.

🧠 O problema com requestAnimationFrame

CSS animations e Framer Motion usam requestAnimationFrame — elas dependem do relógio real. Quando o Remotion renderiza o frame 60, ele não "espera 2 segundos reais"; ele salta diretamente. CSS animations estariam sempre em t=0.

// ❌ CSS animation — ignora o frame atual do Remotion
@keyframes fade { from { opacity:0 } to { opacity:1 } }

// ✓ GSAP + seek — vai exatamente para o frame correto
tl.seek(frame / fps); // frame=60, fps=30 → seek(2.0)

✗ Não determinístico

  • CSS animation — clock-based
  • Framer Motion spring — física variável
  • setTimeout/setInterval — timing impreciso

✓ Determinístico para Remotion

  • GSAP com tl.seek()
  • interpolate(frame, [...]) nativo Remotion
  • Spring do Remotion (não do Framer)
headless
Render sem display
determinismo
Frame = estado único
seek()
Solução do GSAP
rAF
Problema do CSS
5

✅ Quando Framer Motion ainda faz sentido

Framer Motion não é inferior — é diferente. Há contextos onde ele economiza dias de trabalho. O segredo é não confundir o produto final.

Prototipagem rápida

Mostrar uma ideia de UI para o cliente em horas. Framer Motion + shadcn = protótipo em uma tarde.

Apps React com transições de rota

AnimatePresence torna enter/exit de componentes trivial. Impossível de replicar tão simplesmente com GSAP.

Drag e gestos

Dashboards arrastavéis, carousels com inertia, kanban boards. Framer torna trivial.

Vídeo Remotion renderizado

Aqui Framer Motion não funciona — sem seek(), spring physics é indeterminístico, resultado final é imprevisível.

Protótipos
Framer vence
Apps web
Framer vence
Vídeo MP4
GSAP é obrigatório
Apresentações
GSAP é obrigatório
6

💬 Como pedir ao Claude a ferramenta certa

Claude conhece ambas as bibliotecas, mas você precisa deixar explícito o contexto. Sem contexto, Claude pode gerar código Framer Motion para um vídeo Remotion — e isso não vai funcionar.

✗ Prompt vago

"Anima esses cards entrando na tela"

Claude pode usar CSS, Framer ou GSAP — sorte define o resultado.

✓ Prompt contextualizado

"Estou usando Remotion 4 com GSAP. Anima esses cards em stagger 0.2s, fade-up, usando tl.seek(frame/fps)"

Resultado garantido e correto.

💡 Template de prompt para GSAP + Remotion

"Crie uma composição Remotion com GSAP. Use tl.seek(frame/fps) para sincronizar. [descreva a animação]. FPS: 30, duração: [Ns]."

Contexto
Sempre especificar
Remotion
Mencionar versão
seek()
Pedir explicitamente
FPS
Informar sempre

📋 Resumo do módulo

O que aprendemos

  • GSAP e Framer servem paradigmas opostos
  • Vídeo renderizado exige determinismo — GSAP + seek()
  • Framer Motion brilha em prototipagem e UI interativa
  • CSS animations são incompatíveis com render headless
  • Contexto no prompt garante que Claude escolha a ferramenta certa

Próximo módulo

📊 2.3 — D3.js — o dado é o conteúdo

Quando o dado em si é a animação. Bar races, diagramas de arquitetura e visualizações que o Claude gera a partir de um CSV.