Como eu escolhi uma biblioteca de animação para o meu jogo de paciência

Há uma abundância de bibliotecas CSS e JavaScript para bibliotecas de animação por aí. Tantos, de fato, que escolher o certo para o seu projeto pode parecer impossível. Essa é a situação que enfrentei quando decidi construir um jogo de paciência online. Eu sabia que precisaria de uma biblioteca de animação, mas qual era a certa para escolher?

Neste artigo, analisarei as considerações que fiz, o que procurar e apresentarei algumas das bibliotecas mais populares disponíveis. Vou passar por alguns exemplos do mundo real com você para ilustrar meus pontos e, no final, espero que você esteja melhor equipado do que eu quando tive que escolher uma biblioteca de animação.

Sua milhagem com este conselho pode variar, é claro. Tudo o que estou compartilhando aqui é específico para uma coisa que eu queria construir. Seu projeto pode ter requisitos e prioridades completamente diferentes e tudo bem. Acho que o importante aqui é obter um relato em primeira mão pensando como um desenvolvedor front-end com um objetivo específico.

Falando nisso, eu me considero um desenvolvedor front-end, mas meu background é super pesado em design. Então eu sei código, mas não tanto quanto alguém que é um engenheiro de JavaScript. Só queria esclarecer isso porque a experiência certamente pode afetar a decisão final.

Aqui está o objetivo

Antes de entrarmos em qualquer tomada de decisão, vamos dar uma olhada nos tipos de animações que eu precisava fazer nesta versão do jogo com CSS-Tricks:

Bem doce, certo? Não há nada exatamente trivial sobre essas animações. Há muita coisa acontecendo – às vezes simultaneamente – e muito para orquestrar. Além disso, a maioria das animações são acionadas por interações do usuário. Então, isso me deixou com algumas prioridades em minha decisão:

• Animações suaves: A maneira como as animações são aplicadas pode ter um grande impacto sobre se elas funcionam sem problemas ou exibem um pouco de instabilidade.
• Atuação: Adotar qualquer biblioteca vai adicionar peso a um projeto e eu queria que meu jogo fosse o mais enxuto possível.
• Conveniência: Eu queria uma sintaxe agradável e limpa que tornasse mais fácil escrever e gerenciar as animações. Eu até trocaria um pouco de conveniência extra por um pequeno custo de desempenho se isso me permitisse escrever um código melhor e mais sustentável. Novamente, isso é um bom presságio para um designer que se tornou desenvolvedor.
• Suporte para navegador: É claro que eu queria que meu jogo funcionasse em qualquer navegador moderno usando alguma forma de aprimoramento progressivo para evitar que navegadores herdados ficassem completamente entediados. Além disso, eu definitivamente queria algo à prova de futuro.

Foi isso que levei comigo enquanto procurava a ferramenta certa para esse trabalho específico.

Escolhendo entre CSS ou JavaScript bibliotecas de animação

A primeira coisa que considerei ao escolher uma biblioteca de animação foi escolher uma biblioteca baseada em CSS ou JavaScript. Há muitos ótimas bibliotecas CSS, muitos deles com excelente desempenho que era uma alta prioridade para mim. Eu estava procurando fazer algumas animações pesadas, como a capacidade de sequenciar animações e obter retornos de chamada na conclusão da animação. Tudo isso é totalmente possível com CSS puro - ainda assim, é muito menos suave do que a maioria das bibliotecas JavaScript oferecem.

Vamos ver como uma animação sequenciada simples se parece em CSS e compará-la com jQuery, que possui muitos auxiliares de animação integrados:

As animações parecem as mesmas, mas são criadas de forma diferente. Para fazer a animação CSS, primeiro temos que definir a animação do keyframe em nosso CSS e anexá-la a uma classe:

.card.move {
  animation : move 2s;
}

@keyframes move {
  0% { left: 0 }
  50% { left: 100px }
  100% { left: 0 }
}

Em seguida, executamos a animação usando JavaScript e ouvimos um retorno de chamada CSS no elemento:

var cardElement = document.getElementsByClassName("card")[0];
var statusElement = document.getElementsByClassName("status")[0];

cardElement.classList.add("move");
statusElement.innerHTML = "Animating"

var animationEndCallback = function() {
  cardElement.classList.remove("move");
  statusElement.innerHTML = "Inactive"
}

cardElement.addEventListener("webkitAnimationEnd", animationEndCallback);
cardElement.addEventListener("oAnimationEnd", animationEndCallback); 
cardElement.addEventListener("antionend", animationEndCallback);

Ter coisas acontecendo em lugares diferentes pode ser bom em um exemplo simples como este, mas pode se tornar muito confuso quando as coisas ficam um pouco mais complexas. 

Compare isso com como a animação é feita com jQuery:

$(".status").text("Animating")
$( ".card" ).animate({
  left: "100px"
}, 1000);
$( ".card" ).animate({
  left: 0
}, 1000, function() {
  $(".status").text("Inactive")
});

Aqui, tudo acontece no mesmo lugar, simplificando as coisas caso as animações se tornem mais complexas no futuro.

Parecia claro que uma biblioteca JavaScript era o caminho certo a seguir, mas qual era o caminho certo para escolher para o meu jogo Solitaire? Quero dizer, jQuery é ótimo e ainda amplamente utilizado até hoje, mas isso não é algo que eu quero pendurar meu chapéu. Existem muitas bibliotecas de animação JavaScript, então eu queria considerar algo construído especificamente para lidar com o tipo de animações pesadas que eu tinha em mente.

Escolhendo uma biblioteca de animação JavaScript

Rapidamente ficou claro para mim que não faltam bibliotecas de animação JavaScript e tecnologias novas e excitantes. Todos eles têm vantagens e desvantagens, então vamos passar por alguns dos que considerei e por quê.

A API de animações da web é um caso que pode substituir muitas bibliotecas de animação JavaScript no futuro. Com ele, você poderá criar animações escalonadas complexas sem carregar nenhuma biblioteca externa e com o mesmo desempenho das animações CSS. O único inconveniente é que nem todos os navegadores o suportam ainda. 

A <canvas> elemento apresenta outra oportunidade emocionante. Nele, podemos animar coisas com JavaScript, como faríamos com o DOM, mas a animação é renderizada como raster, o que significa que podemos fazer algumas animações de alto desempenho. A única desvantagem é que o elemento canvas é essencialmente renderizado como uma imagem no DOM, então se estivermos procurando por pixel-perfeição, podemos estar sem sorte. Como alguém profundamente sintonizado com o design, isso foi um fator decisivo para mim.

Eu precisava de algo testado e comprovado, então sabia que provavelmente teria que usar uma das muitas bibliotecas JavaScript. Comecei a procurar bibliotecas e reduzi minhas escolhas para Anime.js e GSAP. Ambos pareciam lidar bem com animações complexas e tinham excelentes notas sobre o desempenho. Anime é uma biblioteca bem mantida com mais de 42.000 estrelas no GitHub, enquanto GSAP é uma biblioteca super popular e testada em batalha com uma comunidade próspera.

Uma comunidade ativa era fundamental para mim, pois precisava de um lugar para pedir ajuda e não queria usar uma biblioteca que poderia ser abandonada mais tarde. Eu considerei isso como parte dos meus requisitos de conveniência.

Sequenciando animações e retornos de chamada

Depois que minhas escolhas foram reduzidas, o próximo passo foi implementar uma animação complexa usando minhas duas bibliotecas. Uma animação recorrente em um jogo de paciência é a de uma carta se movendo em algum lugar e depois virando, então vamos ver como fica:

Ambas as animações estão ótimas! Eles são suaves e a implementação de ambos foi bastante simples. Ambas as bibliotecas tinham função de linha do tempo que facilitou a criação de sequências. É assim que a implementação fica no AnimeJS:

var timeline = anime.timeline({
  begin: function() {
    $(".status").text("Animating")
  },
  complete: function() {
    $(".status").text("Inactive")
  }
});

timeline.add({
  targets: '.card',
  left: [0, 300],
  easing: 'easeInOutSine',
  duration: 500
}).add({
  targets: '.card .back',
  rotateY: [0, 90],
  easing: 'easeInSine',
  duration: 200
}).add({
  targets: '.card .front',
  rotateY: [-90, 0],
  easing: 'easeOutSine',
  duration: 200
})

de anime timeline() função vem embutido com retornos de chamada no início e no final da animação, e criar a sequência é tão fácil quanto anexar as animações sequenciais. Primeiro, movo o cartão, depois giro minha imagem traseira 90 graus, para que ela fique fora de vista, e depois giro minha imagem frontal 90 graus, para que fique visível.

A mesma implementação usando GSAP's timeline() função parece muito semelhante:

var timeline = gsap.timeline({
  onStart: function() {
    $(".status").text("Animating")
  },
  onComplete: function() {
    $(".status").text("Inactive")
  }
});

timeline.fromTo(".card", {
  left: 0
}, {
  duration: 0.5,
  left: 300
}).fromTo(".card .back", {
  rotationY: 0
}, {
  rotationY: 90,
  ease: "power1.easeIn",
  duration: 0.2
}).fromTo(".card .front", {
  rotationY: -90
}, {
  rotationY: 0,
  ease: "power1.easeOut",
  duration: 0.2
})

Tempo de decisão

A principal diferença entre Anime e GSAP parece ser a sintaxe, onde GSAP pode ser um pouco mais elaborado. Eu estava preso a duas grandes bibliotecas que tinham funcionalidades muito semelhantes, eram capazes de lidar com animações complexas e tinham uma comunidade próspera. Parecia que eu tinha uma corrida de empate!

Prioridade	Anime	GSAP
Animações suaves	✅	✅
Performance	✅	✅
Conveniência	✅	✅
Suporte ao navegador	✅	✅

Então, o que me fez escolher uma biblioteca em detrimento da outra?

Eu estava muito preocupado sobre como a biblioteca agiria sob pressão. Ter animações lentas em um jogo como Solitaire pode afetar muito o quão divertido é jogar o jogo. Eu sabia que não seria capaz de ver completamente o desempenho da biblioteca antes de criar o jogo. Felizmente, GSAP tinha feito um Teste de stress que comparou diferentes bibliotecas de animação entre si, incluindo Anime.

Olhando para isso, o GSAP certamente parecia ser a biblioteca superior para lidar com muitas animações complexas. O GSAP estava me dando mais de 26 quadros por segundo em uma animação pesada que o Anime só conseguiu atingir aos 19. Depois de ler mais sobre o GSAP e pesquisar em seus fóruns, ficou claro que o desempenho era a maior prioridade para os caras atrás do GAP.

E mesmo que o GSAP e o Anime existam há algum tempo, o repositório do Anime está um tanto inativo há alguns anos, enquanto o GSAP fez commits nos últimos meses.

Acabei usando GSAP e não me arrependi da minha decisão!

E você? Isso se encaixa na forma como você avalia e compara as ferramentas de front-end? Existem outras prioridades que você poderia ter considerado (por exemplo, acessibilidade, etc.) em um projeto como este? Ou você tem um projeto em que teve que reduzir suas escolhas entre várias opções diferentes? Por favor, compartilhe nos comentários porque eu gostaria de saber! 

Ah, e se você quiser ver como fica ao animar um baralho inteiro de cartas, você pode ir ao meu site e jogar um jogo de paciência. Divirta-se!