Hur jag valde ett animationsbibliotek för mitt patiensspel

Det finns ett överflöd av både CSS- och JavaScript-bibliotek för animationsbibliotek där ute. Så många faktiskt att det kan verka omöjligt att välja rätt för ditt projekt. Det var den situationen jag stod inför när jag bestämde mig för att bygga en online Solitaire spel. Jag visste att jag skulle behöva ett animationsbibliotek, men vilket var det rätta att välja?

I den här artikeln ska jag gå igenom vilka överväganden jag gjorde, vad jag ska hålla utkik efter och presentera några av de mest populära biblioteken som finns. Jag ska gå igenom några verkliga exempel med dig för att illustrera mina poänger, och i slutändan kommer du förhoppningsvis vara bättre rustad än jag när jag först var tvungen att välja ett animationsbibliotek.

Din körsträcka med detta råd kan naturligtvis variera. Allt jag delar här är specifikt för en sak jag ville bygga. Ditt projekt kan ha helt andra krav och prioriteringar och det är okej. Jag tror att det som är viktigt här är att få en förstahandsredovisning av tänker som en frontend-utvecklare med ett särskilt mål.

På tal om det, jag ser mig själv som en frontend-utvecklare men min bakgrund är supertung i design. Så jag kan kod, men inte i den utsträckning som någon som är JavaScript-ingenjör. Ville bara klargöra det eftersom erfarenhet kan säkert påverka det slutliga beslutet.

Här är målet

Innan vi går in på något beslutsfattande låt oss ta en titt på de typer av animationer jag behövde göra i denna CSS-Tricks-ifierade version av spelet:

Ganska söt, eller hur? Det finns inget riktigt trivialt med dessa animationer. Det händer mycket - ibland samtidigt - och mycket att orkestrera. Plus, en majoritet av animationerna utlöses av användarinteraktioner. Så det lämnade mig med några prioriteringar inför mitt beslut:

• Smidiga animationer: Sättet som animationer appliceras på kan ha stor inverkan på om de fungerar smidigt eller om de är lite hackiga.
• Prestanda: Att adoptera vilket bibliotek som helst kommer att lägga vikt till ett projekt och jag ville att mitt spel skulle vara så magert som möjligt.
• Bekvämlighet: Jag ville ha en snygg, ren syntax som gör det lättare att skriva och hantera animationerna. Jag skulle till och med byta ut lite extra bekvämlighet för en liten prestandakostnad om det tillåter mig att skriva bättre, mer underhållbar kod. Återigen bådar detta gott för en designer som blivit utvecklare.
• Webbläsarstöd: Naturligtvis ville jag att mitt spel skulle fungera på alla moderna webbläsare som använder någon form av progressiv förbättring för att förhindra helt tråkiga äldre webbläsare. Dessutom ville jag definitivt ha lite framtidssäkring.

Det var det jag tog med mig när jag letade efter rätt verktyg för just det här jobbet.

Välj mellan CSS eller JavaScript animationsbibliotek

Det första jag tänkte på när jag valde ett animationsbibliotek var om jag skulle använda ett CSS- eller JavaScript-baserat bibliotek. Det finns många bra CSS-bibliotek, många av dem med utmärkt prestanda vilket var högt prioriterat för mig. Jag tänkte göra några tunga animationer, som möjligheten att sekvensera animeringar och få återuppringningar när animeringen är klar. Det är allt fullt möjligt med ren CSS - ändå är det mycket mindre smidigt än vad de flesta JavaScript-bibliotek erbjuder.

Låt oss se hur en enkel sekvenserad animation ser ut i CSS och jämför den med jQuery, som har massor av inbyggda animationshjälpmedel:

Animationerna ser likadana ut men skapas på olika sätt. För att göra CSS-animeringen måste vi först definiera keyframe-animeringen i vår CSS och bifoga den till en klass:

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

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

Vi kör sedan animeringen med JavaScript och lyssnar efter en CSS-återuppringning 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);

Att få saker att hända på olika platser kan vara bra i ett enkelt exempel som detta, men det kan bli väldigt förvirrande när saker och ting blir lite mer komplexa. 

Jämför detta med hur animeringen görs med jQuery:

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

Här händer allt på samma ställe, vilket förenklar om animationerna skulle bli mer komplexa i framtiden.

Det verkade tydligt att ett JavaScript-bibliotek var rätt väg att gå, men vilket var det rätta att välja för mitt Solitaire-spel? Jag menar, jQuery är bra och används fortfarande i stor utsträckning än idag, men det är inget jag vill hänga min hatt på. Det finns gott om JavaScript-animationsbibliotek, så jag ville överväga något byggt specifikt för att hantera den typ av tunga animationer jag hade i åtanke.

Att välja ett JavaScript-animationsbibliotek

Det blev snabbt uppenbart för mig att det inte finns någon brist på JavaScript-animationsbibliotek och nya spännande tekniker. De har alla fördelar och nackdelar, så låt oss gå igenom några av de jag funderade på och varför.

Smakämnen Web Animations API är ett sådant fall som kan ersätta många JavaScript-animationsbibliotek i framtiden. Med den kommer du att kunna skapa komplexa förskjutna animationer utan att ladda några externa bibliotek och med samma prestanda som CSS-animationer. Den enda nackdelen är det inte alla webbläsare stöder det ännu. 

Smakämnen <canvas> element ger ytterligare en spännande möjlighet. I den kan vi animera saker med JavaScript, som vi skulle göra med DOM, men animeringen renderas som raster, vilket betyder att vi kan göra några högpresterande animationer. Den enda nackdelen är att canvaselementet i huvudsak renderas som en bild i DOM, så om vi letar efter pixelperfektion kan vi ha tur. Som någon som är mycket i samklang med design, var detta en dealbreaker för mig.

Jag behövde något beprövat och testat, så jag visste att jag förmodligen var tvungen att gå med ett av de många JavaScript-biblioteken. Jag började titta på bibliotek och begränsade mina val till Anime.js och GSAP. De verkade båda hantera komplexa animationer bra och hade utmärkta anteckningar om prestanda. Anime är ett välskött bibliotek med över 42.000 XNUMX stjärnor på GitHub, medan GSAP är ett superpopulärt, stridstestat bibliotek med en blomstrande community.

En aktiv gemenskap var avgörande för mig eftersom jag behövde en plats att be om hjälp och jag ville inte använda ett bibliotek som senare skulle kunna överges. Jag ansåg detta som en del av mina bekvämlighetskrav.

Sekvensering av animationer och återuppringningar

När jag väl hade begränsat mina val var nästa steg att implementera en komplex animation med mina två bibliotek. En återkommande animation i ett patiensspel är att ett kort rör sig någonstans och sedan vänder sig, så låt oss se hur det ser ut:

Båda animationerna ser bra ut! De är smidiga och att implementera båda var ganska okomplicerat. Båda biblioteken hade en tidslinjefunktion som gjorde det enkelt att skapa sekvenser. Så här ser implementeringen ut 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
})

Animes timeline() fungera kommer inbyggt med återuppringningar vid början och avslutar animeringen, och att skapa sekvensen är lika enkelt som att lägga till de sekventiella animationerna. Först flyttar jag kortet, sedan vänder jag min bakre bild 90 grader, så att den försvinner, och sedan vänder jag min främre bild 90 grader, så att den syns.

Samma implementering med GSAP timeline() fungera ser väldigt lika ut:

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

Beslutstid

Den största skillnaden mellan Anime och GSAP verkar vara syntaxen, där GSAP kan vara lite mer utarbetad. Jag hade fastnat med två fantastiska bibliotek som hade mycket liknande funktionalitet, kunde hantera komplex animering och hade en blomstrande gemenskap. Det verkade som om jag hade ett oavgjort race!

Budget	Anime	GSAP
Smidiga animationer	✅	✅
prestanda	✅	✅
Convenience	✅	✅
Webbläsarstöd	✅	✅

Så vad fick mig att välja det ena biblioteket framför det andra?

Jag var mycket oroad över hur biblioteket skulle agera under press. Att ha laggy animationer i ett spel som Solitaire kan i hög grad påverka hur roligt det är att spela spelet. Jag visste att jag inte helt skulle kunna se hur biblioteket presterade innan jag skapade spelet. Lyckligtvis hade GSAP gjort en stresstest som jämförde olika animationsbibliotek med varandra, inklusive Anime.

När man tittar på det såg GSAP verkligen ut att vara det överlägsna biblioteket för att hantera mängder av komplexa animationer. GSAP gav mig uppemot 26 bilder per sekund på en tung animering som Anime bara kunde toppa vid 19. Efter att ha läst på GSAP mer och tittat in i deras forum stod det klart att prestanda var av högsta prioritet för killarna bakom GSAP.

Och även om både GSAP och Anime har funnits ett tag, har Animes repo suttit något vilande ett par år medan GSAP hade gjort åtaganden under de senaste månaderna.

Det slutade med att jag använde GSAP och har inte ångrat mitt beslut!

Och du då? Stämmer något av detta överens med hur du utvärderar och jämför front-end-verktyg? Finns det andra prioriteringar som du kanske har tänkt på (t.ex. tillgänglighet etc.) i ett projekt som detta? Eller har du ett projekt där du var tvungen att minska dina val från en massa olika alternativ? Dela gärna i kommentarerna för jag skulle vilja veta! 

Åh, och om du vill se hur det ser ut när du animerar en hel kortlek kan du gå till min sida och spela en omgång Solitaire. Ha så kul!