GSAP, Motion ou CSS: a árvore de decisão

Comece pelo CSS. Vá para o Motion quando precisar de física de mola ou animação de layout em React. Vá para o GSAP quando precisar orquestrar uma sequência com várias etapas coordenadas.

Essa ordem inverte a prática comum, que é escolher a biblioteca primeiro e usar CSS para o que sobrar. E ela mudou por três motivos que aconteceram nos últimos dois anos, não por preferência.

"GSAP ou Framer Motion" era a pergunta certa em 2024. Hoje ela pula a decisão que vem antes: você precisa de biblioteca?

Três coisas mudaram e nenhuma delas foi anunciada junto.

O CSS entrou na disputa. As scroll-driven animations chegaram ao Chrome 115 em julho de 2023 e ao Safari 26 em setembro de 2025. As View Transitions same-document viraram Baseline com o Firefox 144. Juntas, elas cobrem a maior parte do motion decorativo que se fazia com biblioteca.

O GSAP ficou gratuito, mas não virou open source. Desde 30 de abril de 2025 ele não custa nada, incluindo todos os plugins antes pagos. A licença, porém, é própria, chamada "No Charge": a Webflow detém toda a propriedade intelectual e há cláusula que proíbe uso em ferramenta concorrente do construtor visual dela.

O Motion assumiu o nome e a licença. Ex-Framer Motion, hoje importado de motion/react, e MIT confirmado no repositório oficial.

O resultado é que os eixos de decisão hoje são o que já é nativo, qual licença você aceita e como cada um executa — não qual anima mais bonito.

Comece por aqui, porque o que o CSS resolve não precisa de dependência.

Há uma vantagem estrutural que costuma decidir: as scroll-driven animations rodam no compositor thread, fora da main thread. Elas continuam suaves enquanto o resto da página está travado — que é exatamente o momento em que a versão em JavaScript engasga.

A ressalva de sempre: nem toda propriedade vai para o compositor. opacity e transform ficam lá; width, height e top forçam layout e devolvem o problema.

Os detalhes de suporte e o padrão de fallback estão em CSS scroll-driven: o que já dá para usar sem JS.

Este eixo não aparece em comparação de features e é o único que não muda com atualização.

Para quase todo mundo, a cláusula do GSAP é irrelevante — ela mira construtores visuais de animação, não desenvolvimento de software em geral. Site de cliente, SaaS, portfólio e e-commerce não se encaixam.

Mas o eixo continua real para dois perfis: quem constrói ferramenta no espaço de no-code, e quem precisa garantir que a dependência possa ser bifurcada se o mantenedor mudar de rumo. Nesses casos, MIT não é detalhe jurídico — é requisito de arquitetura.

A análise completa da licença está em GSAP grátis: o que a licença permite e o que não.

Três abordagens diferentes, e a diferença aparece quando a página está sob carga.

CSS com scroll-driven animations roda no compositor thread. É o único dos três que sai da main thread por padrão.

Motion se descreve como hybrid engine: JavaScript combinado com APIs nativas do browser, com o objetivo declarado de animação a 120fps acelerada por GPU. Na prática, ele delega ao browser o que dá para delegar e assume o controle onde precisa.

GSAP é orquestração em JavaScript. Roda na main thread e calcula os valores a cada frame. Isso é o que dá a ele o controle fino de timeline — e é também o que o torna sensível a página ocupada.

A leitura prática:

Não é ranking de qualidade. É onde o trabalho acontece.

Quatro casos em que nenhuma alternativa nativa chega perto.

Timeline com etapas coordenadas. Animar seis elementos em sequência, com sobreposição controlada e easing diferente por trecho, é o que a timeline do GSAP faz e o CSS não tem estrutura para expressar.

Pinning com scrub. Fixar uma seção e avançar a animação conforme o scroll é a técnica que sustenta praticamente todo site premium de agência. O ScrollTrigger não tem equivalente — e ele nunca foi um plugin pago, ao contrário do que muito texto repete. Os oito padrões que cobrem quase todo uso dele têm post próprio, com o código mínimo de cada um.

Morph de forma SVG. Transformar uma forma em outra. O MorphSVG, hoje gratuito, resolve o que CSS não resolve.

Split de texto com stagger preciso. O SplitText quebra em linhas, palavras ou caracteres e entrega os elementos prontos para animar em sequência. Também gratuito desde 2025.

Os dois últimos estavam atrás de assinatura até abril de 2025, o que mudou bastante o cálculo para orçamento pequeno.

Vale ver como isso aparece junto num site real: os padrões de motion que dissequei em sites de agência usam quase todos esses recursos em conjunto.

Dois casos, e os dois são específicos de React.

Animação de layout. Quando um elemento muda de posição porque o layout mudou (item que sai de uma lista, card que reordena, elemento que troca de container), o Motion anima a transição sozinho. Fazer isso na mão exige medir posições antes e depois e interpolar entre elas. É o problema que o Flip do GSAP também resolve, com a diferença de que no Motion isso é declarativo e integrado ao ciclo do React.

Física de mola. Animação com spring não tem duração fixa: ela tem rigidez, amortecimento e massa. O resultado parece mais natural em interação direta, como arrastar, soltar e elástico. O CSS tem linear() para aproximar curvas complexas, mas não simula física.

Some a isso a licença MIT e o encaixe idiomático em React, e o Motion vira a escolha padrão para interface — deixando o GSAP para o motion narrativo.

Um reveal ao entrar na viewport, o efeito mais comum do repertório. Compare o custo de cada abordagem.

CSS, sem dependência:

.card { opacity: 1; translate: none; }

@supports (animation-timeline: view()) {
  .card {
    animation: revelar linear both;
    animation-timeline: view();
    animation-range: entry 10% cover 35%;
  }
  @keyframes revelar {
    from { opacity: 0; translate: 0 1.5rem; }
    to   { opacity: 1; translate: 0 0; }
  }
}

Motion, em React:

import { motion } from 'motion/react'

<motion.div
  initial={{ opacity: 0, y: 24 }}
  whileInView={{ opacity: 1, y: 0 }}
  viewport={{ once: true, amount: 0.3 }}
  transition={{ duration: 0.5 }}
>
  {conteudo}
</motion.div>

GSAP, com ScrollTrigger:

import { gsap } from 'gsap'
import { ScrollTrigger } from 'gsap/ScrollTrigger'

gsap.registerPlugin(ScrollTrigger)

gsap.from('.card', {
  opacity: 0,
  y: 24,
  duration: 0.5,
  scrollTrigger: { trigger: '.card', start: 'top 85%' },
})

Os três produzem o mesmo resultado visual. As diferenças estão fora do código:

Note a linha da degradação. É a única em que a versão CSS depende de você ter escrito o @supports certo — e a única em que o efeito some sozinho num motor sem suporte, em vez de quebrar.

prefers-reduced-motion não é automático em nenhum dos três, e o esforço difere.

CSS é o mais barato: uma media query cobre tudo que você escreveu.

@media (prefers-reduced-motion: reduce) {
  .card { animation: none; opacity: 1; translate: none; }
}

Motion e GSAP exigem checagem em JavaScript e decisão por animação. Nos dois casos você precisa ler a preferência e ramificar — não existe interruptor global.

Vale a distinção que raramente aparece: nem todo movimento tem o mesmo risco. Slide direcional que atravessa a viewport é o gatilho mais comum de sensibilidade a movimento. Crossfade, morph e reveal por opacidade carregam risco bem menor, porque afetam área pequena ou dependem de opacidade em vez de posição.

A abordagem grosseira — zerar todas as durações — é melhor que ignorar, e pior que a refinada, que preserva opacidade e remove só o deslocamento posicional.

Isso é decisão editorial, não técnica, e ela não muda com a biblioteca escolhida.

Quatro perguntas, na ordem.

Note que o CSS aparece duas vezes, no começo e no fim. Isso é deliberado: na dúvida, a resposta é CSS, porque é a única opção sem custo de manutenção, sem licença para ler e sem bundle para carregar.

E os três convivem. A regra que sigo em projeto: CSS para o decorativo e reversível, Motion para interface reativa em React, GSAP para narrativa orquestrada. Assim cada biblioteca fica onde é insubstituível, e o resto do site não depende dela.

Nenhuma decisão é de graça.

Escolher CSS custa suporte de browser. Scroll-driven não roda no Firefox estável, e cross-document View Transitions também não. Degrada bem se você escrever o fallback certo, e some conteúdo se não escrever.

Escolher Motion custa bundle e acoplamento a React. Também custa a dependência de um mantenedor único, ainda que sob MIT — a licença garante o direito de bifurcar, não que alguém vá manter.

Escolher GSAP custa main thread e concentração de fornecedor. A biblioteca de animação mais usada da web pertence a uma empresa só, com licença própria que concede uso e não redistribuição.

E escolher os três custa o pior de todos: três formas diferentes de fazer a mesma coisa no mesmo projeto, e ninguém lembrando qual usar onde. Se você não tem regra escrita de quando usar cada um, provavelmente tem os três fazendo o trabalho que o CSS resolvia.

O caso de texto tem árvore própria, porque metade dos efeitos tipográficos não precisa de biblioteca nenhuma: veja animação de texto.

O GSAP virou obsoleto agora que o CSS faz scroll?

Não. O CSS cobriu o motion decorativo — reveal, parallax, progresso. Timeline com etapas coordenadas, pinning com scrub e morph de SVG continuam sem equivalente nativo. O que mudou é a fatia: metade do que exigia GSAP há dois anos hoje não exige.

Motion ou GSAP para um projeto React?

Depende do tipo de animação. Interface reativa, layout que reordena e física de mola vão melhor no Motion, que é MIT e idiomático em React. Motion narrativo, com sequência coordenada e scroll com scrub, vai melhor no GSAP. Os dois convivem no mesmo projeto sem conflito.

A licença do GSAP me impede de usar em produto comercial?

Não. A cláusula mira ferramentas que constroem animação por interface visual e competem com a Webflow nesse ponto. Site de cliente, SaaS que usa GSAP na própria interface, portfólio e e-commerce estão fora do alcance. Se você constrói editor visual de animação, aí sim vale procurar consentimento por escrito.

Dá para usar CSS scroll-driven e GSAP no mesmo projeto?

Dá, e é a combinação que eu recomendaria. CSS para o que é simples e reversível, GSAP onde há orquestração. O cuidado é ter regra escrita de qual usar onde, senão o projeto acumula duas soluções para o mesmo problema.

• GSAP — Licensing. Licença "No Charge", efetiva em 30/04/2025. Acesso em 20/08/2026.
• GSAP — Plugins. Acesso em 20/08/2026.
• Motion — Repositório oficial. Licença MIT. Acesso em 20/08/2026.
• Motion — Documentação. Acesso em 20/08/2026.
• MDN — CSS scroll-driven animations. Acesso em 19/08/2026.
• MDN — View Transition API. Acesso em 20/08/2026.
• WebKit — WebKit Features for Safari 26.5. Acesso em 20/08/2026.

Verificado em 20 de agosto de 2026.

Gatilho de reavaliação: revisar quando (a) o Firefox habilitar scroll-driven animations no release estável, o que muda a primeira pergunta da árvore, (b) a licença do GSAP for alterada, (c) o CSS ganhar primitiva de física de mola, ou (d) qualquer um dos três mudar o modelo de execução.