Hoe ik een animatiebibliotheek koos voor mijn Solitaire-spel

Er is een overvloed aan zowel CSS- als JavaScript-bibliotheken voor animatiebibliotheken die er zijn. Zo veel zelfs dat het onmogelijk lijkt om de juiste voor uw project te kiezen. Dat is de situatie waarmee ik werd geconfronteerd toen ik besloot om een ​​?? online Solitaire-spel. Ik wist dat ik een animatiebibliotheek nodig had, maar welke was de juiste keuze?

In dit artikel zal ik doornemen welke overwegingen ik heb gemaakt, waar ik op moet letten en u enkele van de meest populaire beschikbare bibliotheken presenteren. Ik zal enkele praktijkvoorbeelden met je doornemen om mijn punten te illustreren, en hopelijk ben je uiteindelijk beter uitgerust dan ik toen ik voor het eerst een animatiebibliotheek moest kiezen.

Je kilometers met dit advies kunnen natuurlijk variëren. Alles wat ik hier deel, is specifiek voor een ding dat ik wilde bouwen. Uw project kan compleet andere eisen en prioriteiten hebben en dat is oké. Ik denk dat het hier belangrijk is om uit de eerste hand een verslag te krijgen van denken als een front-end ontwikkelaar met een bepaald doel.

Daarover gesproken, ik beschouw mezelf als een front-end ontwikkelaar, maar mijn achtergrond is superzwaar in ontwerp. Dus ik ken code, maar niet in de mate van iemand die een JavaScript-engineer is. Ik wilde dat even ophelderen, want ervaring kan zeker van invloed zijn op de uiteindelijke beslissing.

Hier is het doel

Voordat we een beslissing nemen, laten we eens kijken naar de soorten animaties die ik moest maken in deze CSS-Tricks-ified versie van het spel:

Best lief, toch? Er is niets triviaals aan deze animaties. Er gebeurt veel - soms tegelijkertijd - en er moet veel worden georkestreerd. Bovendien wordt een meerderheid van de animaties geactiveerd door gebruikersinteracties. Dus dat liet me met een paar prioriteiten op weg naar mijn beslissing:

• Vloeiende animaties: De manier waarop animaties worden toegepast, kan van grote invloed zijn op de vraag of ze soepel verlopen of een beetje schokkerig zijn.
• prestaties: Het adopteren van een bibliotheek zal gewicht toevoegen aan een project en ik wilde dat mijn spel zo slank mogelijk zou zijn.
• Gemak: Ik wilde een mooie, schone syntaxis die het schrijven en beheren van de animaties gemakkelijker maakt. Ik zou zelfs een beetje extra gemak inruilen voor een kleine prestatieprijs als het me in staat stelt betere, beter te onderhouden code te schrijven. Nogmaals, dit is een goed voorteken voor een ontwerper die ontwikkelaar is geworden.
• Browserondersteuning: Natuurlijk wilde ik dat mijn spel in elke moderne browser zou werken met een of andere vorm van progressieve verbetering om te voorkomen dat oudere browsers volledig gestoord werden. Bovendien wilde ik absoluut toekomstbestendig zijn.

Dat nam ik mee toen ik op zoek ging naar het juiste gereedschap voor deze specifieke klus.

Kiezen tussen CSS of JavaScript animatiebibliotheken

Het eerste waar ik aan dacht bij het kiezen van een animatiebibliotheek, was of ik zou kiezen voor een op CSS of JavaScript gebaseerde bibliotheek. Er zijn veel van geweldige CSS-bibliotheken, velen van hen met uitstekende prestaties die voor mij een hoge prioriteit hadden. Ik was op zoek naar een aantal zware animaties, zoals de mogelijkheid om animaties te sequencen en callbacks te krijgen bij het voltooien van animaties. Dat is allemaal volledig mogelijk met pure CSS - toch is het een stuk minder soepel dan wat de meeste JavaScript-bibliotheken bieden.

Laten we eens kijken hoe een eenvoudige animatie met sequenties eruitziet in CSS en deze vergelijken met jQuery, dat veel ingebouwde animatiehelpers heeft:

De animaties zien er hetzelfde uit, maar zijn anders gemaakt. Om de CSS-animatie te maken, moeten we eerst de keyframe-animatie in onze CSS definiëren en aan een klasse koppelen:

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

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

We voeren vervolgens de animatie uit met JavaScript en luisteren naar een CSS-callback op het element:

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

Dingen op verschillende plaatsen laten gebeuren is misschien prima in een eenvoudig voorbeeld als dit, maar het kan erg verwarrend worden als de zaken een beetje ingewikkelder worden. 

Vergelijk dit met hoe de animatie wordt gedaan met jQuery:

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

Hier gebeurt alles op dezelfde plek, wat de dingen vereenvoudigt als de animaties in de toekomst complexer worden.

Het leek duidelijk dat een JavaScript-bibliotheek de juiste keuze was, maar welke was de juiste keuze voor mijn Solitaire-spel? Ik bedoel, jQuery is geweldig en nog steeds veel gebruikt zelfs vandaag, maar daar wil ik mijn hoed niet aan hangen. Er zijn tal van JavaScript-animatiebibliotheken, dus ik wilde iets overwegen dat speciaal is gebouwd om het soort zware animaties aan te kunnen dat ik in gedachten had.

Een JavaScript-animatiebibliotheek kiezen

Het werd me al snel duidelijk dat er geen gebrek is aan JavaScript-animatiebibliotheken en nieuwe, opwindende technologieën. Ze hebben allemaal voor- en nadelen, dus laten we er een paar doornemen die ik heb overwogen en waarom.

De API voor webanimaties is zo'n geval dat in de toekomst veel JavaScript-animatiebibliotheken zou kunnen vervangen. Hiermee kun je complexe gespreide animaties maken zonder externe bibliotheken te laden en met dezelfde prestaties als CSS-animaties. Het enige nadeel is dat nog niet alle browsers ondersteunen het. 

De <canvas> element biedt nog een spannende kans. Daarin kunnen we dingen animeren met JavaScript, zoals we zouden doen met de DOM, maar de animatie wordt weergegeven als raster, wat betekent dat we enkele krachtige animaties kunnen maken. Het enige nadeel is dat het canvas-element in wezen wordt weergegeven als een afbeelding in de DOM, dus als we op zoek zijn naar pixelperfectie, hebben we misschien pech. Als iemand die acuut in harmonie is met design, was dit een dealbreaker voor mij.

Ik had iets beproefd en getest nodig, dus ik wist dat ik waarschijnlijk een van de vele JavaScript-bibliotheken moest gebruiken. Ik begon naar bibliotheken te kijken en beperkte mijn keuzes tot: Anime.js en GSAP. Ze leken allebei goed om te gaan met complexe animaties en hadden uitstekende opmerkingen over de prestaties. Anime is een goed onderhouden bibliotheek met meer dan 42.000 sterren op GitHub, terwijl GSAP een super populaire, beproefde bibliotheek is met een bloeiende gemeenschap.

Een actieve gemeenschap was van cruciaal belang voor mij, omdat ik een plek nodig had om om hulp te vragen, en ik geen gebruik wilde maken van een bibliotheek die later zou worden verlaten. Ik beschouwde dit als onderdeel van mijn gemakseisen.

Opeenvolging van animaties en callbacks

Toen ik mijn keuzes eenmaal had beperkt, was de volgende stap het implementeren van een complexe animatie met behulp van mijn twee bibliotheken. Een terugkerende animatie in een solitaire-spel is die van een kaart die ergens heen beweegt en dan omdraait, dus laten we eens kijken hoe dat eruit ziet:

Beide animaties zien er geweldig uit! Ze zijn soepel en het implementeren van beide was vrij eenvoudig. Beide bibliotheken hadden een tijdlijn functie dat maakte het maken van sequenties een fluitje van een cent. Zo ziet de implementatie eruit 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
})

Anime's timeline() functie is ingebouwd met callbacks bij het begin en einde van de animatie, en het maken van de reeks is net zo eenvoudig als het toevoegen van de opeenvolgende animaties. Eerst verplaats ik de kaart, dan draai ik mijn achterste afbeelding 90 graden, zodat hij uit het zicht verdwijnt, en dan draai ik mijn voorste afbeelding 90 graden, zodat hij in beeld komt.

Dezelfde implementatie met GSAP's timeline() functie lijkt erg op elkaar:

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

Beslissingstijd

Het belangrijkste verschil tussen Anime en GSAP lijkt de syntaxis te zijn, waar GSAP misschien iets uitgebreider is. Ik zat vast met twee geweldige bibliotheken die zeer vergelijkbare functionaliteit hadden, in staat waren om te gaan met complexe animaties en een bloeiende gemeenschap hadden. Het leek alsof ik een gelijkspel had!

Prioriteit	Anime	GSAP
Gladde animaties	✅	✅
Performance	✅	✅
Gemak	✅	✅
Browser ondersteuning	✅	✅

Dus waarom koos ik de ene bibliotheek boven de andere?

Ik was erg bezorgd over hoe de bibliotheek zou handelen onder druk. Het hebben van laggy animaties in een spel als Solitaire kan grote invloed hebben op hoe leuk het is om het spel te spelen. Ik wist dat ik niet volledig zou kunnen zien hoe de bibliotheek presteerde voordat ik de game maakte. Gelukkig had GSAP een stresstest die verschillende animatiebibliotheken met elkaar vergeleek, waaronder Anime.

Als je dat bekijkt, leek GSAP zeker de superieure bibliotheek te zijn voor het omgaan met heel veel complexe animaties. GSAP gaf me meer dan 26 frames per seconde op een zware animatie die Anime pas op 19 kon halen. Nadat ik meer had gelezen over GSAP en hun forums had bekeken, werd het duidelijk dat prestaties de hoogste prioriteit hadden voor de jongens achter GAP.

En hoewel zowel GSAP als Anime al een tijdje bestaan, heeft de repo van Anime een paar jaar een beetje sluimerend gelegen, terwijl GSAP de afgelopen maanden commits had gemaakt.

Ik heb uiteindelijk GSAP gebruikt en heb geen spijt van mijn beslissing!

En jij? Klopt dit met hoe u front-end tooling evalueert en vergelijkt? Zijn er andere prioriteiten die u zou kunnen overwegen (bijv. toegankelijkheid, enz.) in een project als dit? Of heb je een project waarbij je keuzes moest maken uit een heleboel verschillende opties? Deel het in de reacties, want ik wil het graag weten! 

Oh, en als je wilt zien hoe het eruit ziet als je een heel pak kaarten animeert, ga dan naar mijn site en speel een spelletje Solitaire. Veel plezier!