Como usamos o GSAP para dar vida aos nossos projetos

As transições em CSS chegam perfeitamente para estados de hover e fades simples, mas assim que uma animação precisa de ser sequenciada, interrompida ou comportar-se de forma diferente consoante o ecrã, ficam sem margem de manobra. O GSAP dá-nos uma única API de timeline que funciona da mesma forma em todos os navegadores para onde publicamos, além do gsap.matchMedia() para ramificar o comportamento de forma limpa — o mesmo menu que se abre em ecrã inteiro no desktop recolhe-se para algo mais discreto em mobile, e qualquer animação do site desaparece por completo quando um visitante tem o movimento reduzido ativado.

O que a maioria dos visitantes nota é o ScrollTrigger, combinado com o Lenis para scroll suave — textos e secções que se revelam ao entrar no ecrã, sincronizados para parecerem inevitáveis, não acionados. O SplitText divide os títulos em palavras para que possam animar-se individualmente, em vez de aparecerem como um bloco fixo. Em projetos mais interativos recorremos ao Flip e ao Observer — a mesma dupla que anima a galeria deste blog — para que mudanças de layout e navegação por swipe pareçam físicas, não instantâneas. As transições de página recebem o mesmo tratamento: um efeito de ecrã inteiro cobre a página antiga, a nova carrega por baixo, e a cobertura levanta-se — uma mudança de rota parece um movimento contínuo, não um corte seco.

Nada disto existe para se exibir. Cada animação é avaliada por tornar uma interface mais fácil de ler ou uma transição mais fácil de acompanhar — se não conseguir isso, é cortada, por muito bem que tenha ficado isoladamente. É essa contenção que os clientes realmente notam, mesmo que não conseguissem dizer o nome GSAP se lhes perguntassem: um site que parece pensado, que responde no momento em que se interage com ele, e que nunca se atravessa ao conteúdo que devia estar a apresentar.