Hvordan jeg valgte et animationsbibliotek til mit kabalespil

Der er en overflod af både CSS- og JavaScript-biblioteker til animationsbiblioteker derude. Så mange, faktisk, at det kan virke umuligt at vælge den rigtige til dit projekt. Det var den situation, jeg stod over for, da jeg besluttede at bygge en online Solitaire spil. Jeg vidste, at jeg skulle bruge et animationsbibliotek, men hvilket var det rigtige at vælge?

I denne artikel vil jeg gennemgå, hvilke overvejelser jeg gjorde, hvad du skal holde øje med og præsentere dig for nogle af de mest populære biblioteker, der findes. Jeg vil gennemgå nogle eksempler fra den virkelige verden med dig for at illustrere mine pointer, og i sidste ende vil du forhåbentlig være bedre rustet end mig, da jeg først skulle vælge et animationsbibliotek.

Dit kilometertal med dette råd kan naturligvis variere. Alt, hvad jeg deler her, er specifikt for en ting, jeg ville bygge. Dit projekt kan have helt andre krav og prioriteter, og det er ok. Jeg tror, ​​at det, der er vigtigt her, er at få en førstehåndsberetning om tænker som en frontend-udvikler med et bestemt mål.

Apropos det, jeg betragter mig selv som en frontend-udvikler, men min baggrund er super tung i designet. Så jeg kender kode, men ikke i omfanget af en, der er JavaScript-ingeniør. Ville bare lige præcisere det, fordi erfaring helt sikkert kan påvirke den endelige beslutning.

Her er målet

Før vi går ind i nogen beslutningstagning, lad os tage et kig på den slags animationer, jeg skulle lave i denne CSS-Tricks-ificerede version af spillet:

Ret sødt, ikke? Der er intet ligefrem trivielt ved disse animationer. Der sker meget - nogle gange samtidigt - og meget at orkestrere. Plus, et flertal af animationerne udløses af brugerinteraktioner. Så det efterlod mig med et par prioriteter på vej ind i min beslutning:

• Glatte animationer: Den måde, animationer anvendes på, kan have stor indflydelse på, om de kører problemfrit eller udviser en smule hakkende.
• Ydelse: At adoptere et hvilket som helst bibliotek vil lægge vægt på et projekt, og jeg ønskede, at mit spil skulle være så slankt som muligt.
• Convenience: Jeg ville have en pæn, ren syntaks, der gør det nemmere at skrive og administrere animationerne. Jeg ville endda bytte lidt ekstra bekvemmelighed for en lille ydeevne, hvis det giver mig mulighed for at skrive bedre, mere vedligeholdelsesvenlig kode. Igen, dette lover godt for en designer, der er blevet udviklet.
• Browser support: Selvfølgelig ville jeg have mit spil til at fungere på enhver moderne browser ved at bruge en form for progressiv forbedring for at forhindre helt borking ældre browsere. Derudover ville jeg bestemt have noget fremtidssikret.

Det var det, jeg tog med mig, da jeg gik på jagt efter det rigtige værktøj til netop dette job.

Vælg mellem CSS eller JavaScript animationsbiblioteker

Den første ting, jeg overvejede, da jeg valgte et animationsbibliotek, var, om jeg skulle bruge et CSS- eller JavaScript-baseret bibliotek. Der er mange gode CSS-biblioteker, mange af dem med fremragende præstationer, som var en høj prioritet for mig. Jeg ledte efter at lave nogle kraftige animationer, f.eks. evnen til at sekvensere animationer og få tilbagekald ved animationsafslutning. Det er alt sammen fuldstændig muligt med ren CSS - stadig er det meget mindre glat end hvad de fleste JavaScript-biblioteker tilbyder.

Lad os se, hvordan en simpel sekvenseret animation ser ud i CSS og sammenligne den med jQuery, som har masser af indbyggede animationshjælpere:

Animationerne ser ens ud, men er skabt anderledes. For at lave CSS-animationen skal vi først definere keyframe-animationen i vores CSS og vedhæfte den til en klasse:

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

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

Vi udfører derefter animationen ved hjælp af JavaScript og lytter efter et CSS-tilbagekald på elementet:

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);

At få ting til at ske forskellige steder kan være fint i et simpelt eksempel som dette, men det kan blive meget forvirrende, når tingene bliver lidt mere komplekse. 

Sammenlign dette med, hvordan animationen udføres med jQuery:

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

Her sker alt på samme sted, hvilket forenkler tingene, hvis animationerne skulle blive mere komplekse i fremtiden.

Det virkede klart, at et JavaScript-bibliotek var den rigtige vej at gå, men hvilken var den rigtige at vælge til mit Solitaire-spil? Jeg mener, jQuery er fantastisk og stadig meget brugt selv i dag, men det er ikke noget, jeg vil hænge min hat på. Der er masser af JavaScript-animationsbiblioteker, så jeg ville overveje noget, der er bygget specifikt til at håndtere den type tunge animationer, jeg havde i tankerne.

Valg af et JavaScript-animationsbibliotek

Det blev hurtigt klart for mig, at der ikke er mangel på JavaScript-animationsbiblioteker og nye, spændende teknologier. De har alle fordele og ulemper, så lad os gennemgå nogle af dem, jeg overvejede, og hvorfor.

Web Animations API er et sådant tilfælde, der kan erstatte mange JavaScript-animationsbiblioteker i fremtiden. Med det vil du være i stand til at skabe komplekse forskudte animationer uden at indlæse eksterne biblioteker og med samme ydeevne som CSS-animationer. Den eneste ulempe er det ikke alle browsere understøtter det endnu. 

<canvas> element giver endnu en spændende mulighed. I den kan vi animere ting med JavaScript, som vi ville med DOM, men animationen er gengivet som raster, hvilket betyder, at vi kan lave nogle højtydende animationer. Den eneste ulempe er, at lærredselementet i det væsentlige gengives som et billede i DOM, så hvis vi leder efter pixel-perfektion, kan vi være uheldige. Som en, der er meget i harmoni med design, var dette en dealbreaker for mig.

Jeg havde brug for noget afprøvet og afprøvet, så jeg vidste, at jeg nok skulle gå med et af de mange JavaScript-biblioteker. Jeg begyndte at kigge på biblioteker og indsnævrede mine valg til Anime.js , GSAP. De syntes begge at håndtere komplekse animationer godt og havde fremragende noter om ydeevne. Anime er et velholdt bibliotek med over 42.000 stjerner på GitHub, mens GSAP er et superpopulært, kamptestet bibliotek med et blomstrende fællesskab.

Et aktivt fællesskab var afgørende for mig, da jeg havde brug for et sted at bede om hjælp, og jeg ønskede ikke at bruge et bibliotek, der senere kunne blive forladt. Jeg betragtede dette som en del af mine bekvemmelighedskrav.

Sekventering af animationer og tilbagekald

Når jeg havde fået mine valg indsnævret, var næste skridt at implementere en kompleks animation ved hjælp af mine to biblioteker. En tilbagevendende animation i et kabalespil er, at et kort bevæger sig et sted hen og derefter vendes, så lad os se, hvordan det ser ud:

Begge animationer ser flotte ud! De er glatte, og implementeringen af ​​dem begge var ret ligetil. Begge biblioteker havde en tidslinje funktion der gjorde det til en leg at skabe sekvenser. Sådan ser implementeringen ud i 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
})

Anime's timeline() funktion kommer indbygget med tilbagekald ved start og afslutning af animationen, og det er lige så nemt at oprette sekvensen som at tilføje de sekventielle animationer. Først flytter jeg kortet, så vender jeg mit bagsidebillede 90 grader, så det bliver ude af syne, og så drejer jeg mit frontbillede 90 grader, så det kommer til syne.

Samme implementering ved hjælp af GSAP'er timeline() funktion ligner meget:

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
})

Beslutningstid

Den største forskel mellem Anime og GSAP ser ud til at være syntaksen, hvor GSAP måske er lidt mere udførlig. Jeg sad fast i to fantastiske biblioteker, der havde meget ens funktionalitet, var i stand til at håndtere kompleks animation og havde et blomstrende fællesskab. Det virkede som om jeg havde et uafgjort løb!

Prioritet	Anime	GSAP
Glatte animationer	✅	✅
Performance (Præstation)	✅	✅
Bekvemmelighed	✅	✅
Browser understøttelse	✅	✅

Så hvad fik mig til at vælge det ene bibliotek frem for det andet?

Jeg var meget bekymret for, hvordan biblioteket ville agere under pres. At have laggy animationer i et spil som Solitaire kan i høj grad påvirke, hvor sjovt det er at spille spillet. Jeg vidste, at jeg ikke helt ville være i stand til at se, hvordan biblioteket fungerede, før jeg oprettede spillet. Heldigvis havde GSAP lavet en stresstest der sammenlignede forskellige animationsbiblioteker med hinanden, inklusive Anime.

Når man ser på det, så GSAP bestemt ud til at være det overlegne bibliotek til at håndtere masser af komplekse animationer. GSAP gav mig op mod 26 billeder i sekundet på en tung animation, som Anime kun var i stand til at toppe ved 19. Efter at have læst mere om GSAP og kigget i deres fora, blev det klart, at ydeevne var af højeste prioritet for gutterne bag GSAP.

Og selvom både GSAP og Anime har eksisteret et stykke tid, har Animes repo ligget lidt i dvale et par år, mens GSAP havde indgået forpligtelser i de sidste par måneder.

Jeg endte med at bruge GSAP og har ikke fortrudt min beslutning!

Hvad med dig? Stemmer noget af dette med, hvordan du evaluerer og sammenligner frontend-værktøj? Er der andre prioriteter, du måske har overvejet (f.eks. tilgængelighed osv.) i et projekt som dette? Eller har du et projekt, hvor du skulle skære ned på dine valg fra en masse forskellige muligheder? Del venligst i kommentarerne, fordi jeg gerne vil vide det! 

Åh, og hvis du vil se, hvordan det ser ud, når du animerer et helt sæt kort, kan du gå over til min side og spille et spil Solitaire. Hav det sjovt!