Come ho scelto una libreria di animazioni per il mio solitario

C'è un'abbondanza di librerie CSS e JavaScript per le librerie di animazioni là fuori. Tanti, infatti, che scegliere quello giusto per il tuo progetto può sembrare impossibile. Questa è la situazione che ho dovuto affrontare quando ho deciso di costruire un gioco solitario online. Sapevo di aver bisogno di una libreria di animazioni, ma quale era quella giusta da scegliere?

In questo articolo, esaminerò quali considerazioni ho fatto, cosa cercare e ti presenterò alcune delle librerie più popolari disponibili. Esaminerò alcuni esempi del mondo reale con te per illustrare i miei punti e alla fine, si spera, sarai meglio equipaggiato di me quando ho dovuto scegliere per la prima volta una libreria di animazioni.

Il tuo chilometraggio con questo consiglio può variare, ovviamente. Tutto ciò che condivido qui è specifico di una cosa che volevo costruire. Il tuo progetto potrebbe avere requisiti e priorità completamente diversi e va bene. Penso che l'importante qui sia avere un resoconto di prima mano pensando come uno sviluppatore front-end con un obiettivo particolare.

A proposito, mi considero uno sviluppatore front-end, ma il mio background è molto pesante nel design. Quindi conosco il codice, ma non nella misura di qualcuno che è un ingegnere JavaScript. Volevo solo chiarirlo perché l'esperienza può sicuramente influire sulla decisione finale.

Ecco l'obiettivo

Prima di entrare in qualsiasi processo decisionale, diamo un'occhiata al tipo di animazioni che dovevo realizzare in questa versione del gioco con trucchi CSS:

Abbastanza dolce, vero? Non c'è niente di esattamente banale in queste animazioni. C'è molto da fare, a volte simultaneamente, e molto da orchestrare. Inoltre, la maggior parte delle animazioni viene attivata dalle interazioni dell'utente. Quindi, questo mi ha lasciato alcune priorità nella mia decisione:

• Animazioni fluide: Il modo in cui vengono applicate le animazioni può avere un grande impatto sul fatto che funzionino senza intoppi o mostrino un po' di instabilità.
• Performance: L'adozione di qualsiasi libreria aggiungerà peso a un progetto e volevo che il mio gioco fosse il più snello possibile.
• Convenienza: Volevo una sintassi piacevole e pulita che rendesse più facile scrivere e gestire le animazioni. Scambiare anche un po' di comodità in più con un piccolo costo in termini di prestazioni se mi consente di scrivere codice migliore e più gestibile. Ancora una volta, questo fa ben sperare per un designer diventato sviluppatore.
• Supporto browser: Ovviamente volevo che il mio gioco funzionasse su qualsiasi browser moderno utilizzando una qualche forma di miglioramento progressivo per evitare il blocco completo dei browser legacy. Inoltre, volevo assolutamente un po' di futuro.

Questo è ciò che ho portato con me mentre andavo alla ricerca dello strumento giusto per questo particolare lavoro.

Scelta tra CSS o JavaScript librerie di animazione

La prima cosa che ho considerato quando ho scelto una libreria di animazioni è stata se scegliere una libreria basata su CSS o JavaScript. Ci sono molti ottime librerie CSS, molti dei quali con prestazioni eccellenti che erano una priorità per me. Stavo cercando di realizzare alcune animazioni pesanti, come la possibilità di mettere in sequenza le animazioni e ottenere callback al completamento dell'animazione. Tutto ciò è totalmente possibile con il puro CSS, tuttavia è molto meno fluido di quello che offre la maggior parte delle librerie JavaScript.

Vediamo come appare una semplice animazione in sequenza in CSS e confrontiamola con jQuery, che ha molti aiutanti di animazione integrati:

Le animazioni hanno lo stesso aspetto ma sono create in modo diverso. Per realizzare l'animazione CSS, per prima cosa, dobbiamo definire l'animazione del fotogramma chiave nel nostro CSS e allegarla a una classe:

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

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

Quindi eseguiamo l'animazione utilizzando JavaScript e ascoltiamo un callback CSS sull'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);

Avere cose che accadono in luoghi diversi potrebbe andare bene in un esempio semplice come questo, ma può diventare molto confuso una volta che le cose diventano un po' più complesse. 

Confronta questo con come viene eseguita l'animazione con jQuery:

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

Qui, tutto accade nello stesso posto, semplificando le cose nel caso in cui le animazioni dovessero diventare più complesse in futuro.

Sembrava chiaro che una libreria JavaScript fosse la strada giusta da percorrere, ma quale era quella giusta da scegliere per il mio solitario? Voglio dire, jQuery è fantastico e ancora ampiamente utilizzato anche oggi, ma non è qualcosa su cui voglio appendere il cappello. Ci sono molte librerie di animazioni JavaScript, quindi volevo prendere in considerazione qualcosa creato appositamente per gestire il tipo di animazioni pesanti che avevo in mente.

Scelta di una libreria di animazioni JavaScript

Mi è diventato subito chiaro che non mancano le librerie di animazioni JavaScript e nuove ed entusiasmanti tecnologie. Hanno tutti vantaggi e svantaggi, quindi esaminiamo alcuni di quelli che ho considerato e perché.

I API Animazioni Web è uno di questi casi che potrebbe sostituire molte librerie di animazioni JavaScript in futuro. Con esso, sarai in grado di creare animazioni sfalsate complesse senza caricare librerie esterne e con le stesse prestazioni delle animazioni CSS. L'unico inconveniente è quello non tutti i browser lo supportano ancora. 

I <canvas> l'elemento presenta un'altra entusiasmante opportunità. In esso, possiamo animare le cose con JavaScript, come faremmo con il DOM, ma l'animazione è resa come raster, il che significa che possiamo creare animazioni ad alte prestazioni. L'unico inconveniente è che l'elemento canvas è essenzialmente rappresentato come un'immagine nel DOM, quindi se stiamo cercando la perfezione dei pixel, potremmo essere sfortunati. Essendo una persona profondamente in sintonia con il design, questo è stato un rompicapo per me.

Avevo bisogno di qualcosa di provato e testato, quindi sapevo che probabilmente dovevo utilizzare una delle tante librerie JavaScript. Ho iniziato a guardare le biblioteche e ho ristretto le mie scelte a anime.js ed GSAP. Entrambi sembravano gestire bene le animazioni complesse e avevano ottime note sulle prestazioni. Anime è una libreria ben tenuta con oltre 42.000 stelle su GitHub, mentre GSAP è una libreria super popolare e testata in battaglia con una fiorente comunità.

Una comunità attiva era fondamentale per me poiché avevo bisogno di un posto dove chiedere aiuto e non volevo usare una biblioteca che avrebbe potuto essere abbandonata in seguito. Ho considerato questo come parte dei miei requisiti di convenienza.

Sequenza di animazioni e callback

Dopo aver ristretto le mie scelte, il passaggio successivo è stato implementare un'animazione complessa utilizzando le mie due librerie. Un'animazione ricorrente in un solitario è quella di una carta che si sposta da qualche parte e poi si gira, quindi vediamo come appare:

Entrambe le animazioni sono fantastiche! Sono fluidi e implementarli entrambi è stato piuttosto semplice. Entrambe le biblioteche avevano a funzione di sequenza temporale che ha reso la creazione di sequenze un gioco da ragazzi. Ecco come appare l'implementazione in 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
})

di anime timeline() function è integrato con callback all'inizio e alla fine dell'animazione e creare la sequenza è facile come aggiungere le animazioni sequenziali. Per prima cosa, sposto la scheda, quindi giro la mia immagine posteriore di 90 gradi, in modo che non sia visibile, quindi giro la mia immagine anteriore di 90 gradi, in modo che venga visualizzata.

La stessa implementazione utilizzando GSAP timeline() function sembra molto simile:

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 di decisione

La principale differenza tra Anime e GSAP sembra essere la sintassi, dove GSAP potrebbe essere un po' più elaborato. Ero bloccato con due grandi librerie che avevano funzionalità molto simili, erano in grado di gestire animazioni complesse e avevano una fiorente comunità. Sembrava che avessi una gara di pareggio!

Priorità	anime	GSAP
Animazioni lisce	✅	✅
Prestazione	✅	✅
Convenienza	✅	✅
Supporto browser	✅	✅

Quindi, cosa mi ha spinto a scegliere una libreria rispetto all'altra?

Ero molto preoccupato per come la biblioteca avrebbe agito sotto pressione. Avere animazioni ritardate in un gioco come Solitaire può influire notevolmente su quanto sia divertente giocare. Sapevo che non sarei stato in grado di vedere completamente come si comportava la libreria prima di creare il gioco. Fortunatamente, GSAP aveva creato un stress test che ha confrontato tra loro diverse librerie di animazioni, incluso Anime.

Considerando ciò, GSAP sembrava sicuramente la libreria superiore per gestire un sacco di animazioni complesse. GSAP mi stava dando più di 26 fotogrammi al secondo su un'animazione pesante che Anime è stato in grado di completare solo a 19. Dopo aver letto di più su GSAP e aver esaminato i loro forum, è diventato chiaro che le prestazioni erano la massima priorità per i ragazzi dietro GSAP.

E anche se sia GSAP che Anime sono in circolazione da un po' di tempo, il repository di Anime è rimasto in qualche modo dormiente per un paio d'anni mentre GSAP aveva effettuato commit negli ultimi due mesi.

Ho finito per usare GSAP e non mi sono pentito della mia decisione!

E tu? Qualcuna di queste corrisponde al modo in cui valuti e confronti gli strumenti front-end? Ci sono altre priorità che potresti aver considerato (es. accessibilità, ecc.) in un progetto come questo? O hai un progetto in cui hai dovuto ridurre le tue scelte da un mucchio di opzioni diverse? Si prega di condividere nei commenti perché mi piacerebbe sapere! 

Oh, e se vuoi vedere come appare quando si anima un intero mazzo di carte, puoi andare sul mio sito e gioca una partita a Solitario. Divertiti!