Як я вибрав бібліотеку анімації для мого пасьянса

Існує велика кількість бібліотек CSS і JavaScript для бібліотек анімації. Насправді їх так багато, що вибрати правильний для свого проекту може здатися неможливим. Саме з такою ситуацією я зіткнувся, коли вирішив побудувати онлайн пасьянс. Я знав, що мені знадобиться бібліотека анімації, але яку вибрати?

У цій статті я розповім, які міркування я взяв, на що слід звернути увагу, і покажу вам деякі з найпопулярніших доступних бібліотек. Я пройду з вами кілька реальних прикладів, щоб проілюструвати свої думки, і врешті-решт, сподіваюся, ви будете краще підготовлені, ніж я, коли мені вперше довелося вибрати бібліотеку анімації.

Ваш пробіг з цією порадою, звичайно, може відрізнятися. Усе, чим я тут ділюся, стосується речі, яку я хотів створити. Ваш проект може мати зовсім інші вимоги та пріоритети, і це нормально. Я думаю, що тут важливо отримати інформацію з перших вуст мислення як інтерфейсний розробник з конкретною метою.

Говорячи про це, я справді вважаю себе фронтенд-розробником, але мій досвід надзвичайно важкий у дизайні. Тож я знаю код, але не настільки, як той, хто є інженером JavaScript. Просто хотів прояснити це, оскільки досвід, безперечно, може вплинути на остаточне рішення.

Ось ціль

Перш ніж ми приступимо до прийняття будь-яких рішень, давайте подивимося на типи анімацій, які мені потрібно було створити в цій версії гри з CSS-Tricks:

Досить мило, правда? У цих анімаціях немає нічого тривіального. Багато чого відбувається — інколи одночасно — і багато чого потрібно оркеструвати. Крім того, більшість анімацій викликаються взаємодією користувача. Отже, це залишило для мене кілька пріоритетів, які ґрунтувалися на моєму прийнятті рішення:

• Плавна анімація: Спосіб застосування анімації може сильно вплинути на те, чи буде вона працювати плавно чи відображатиметься трохи переривчасто.
• Продуктивність: Прийняття будь-якої бібліотеки додасть ваги проекту, і я хотів, щоб моя гра була якомога меншою.
• Зручність: Мені потрібен гарний, чистий синтаксис, який полегшить написання анімації та керування нею. Я навіть проміняв би невелику додаткову зручність на невелику вартість продуктивності, якщо це дозволить мені писати кращий, зручніший код. Знову ж таки, це добре для дизайнера, який став розробником.
• Підтримка браузера: Звичайно, я хотів, щоб моя гра працювала в будь-якому сучасному браузері з використанням певної форми прогресивного вдосконалення, щоб запобігти повному руйнуванню застарілих браузерів. Крім того, я безперечно хотів бути готовим до майбутнього.

Це те, що я взяв із собою, коли вирушив на пошуки потрібного інструменту для цієї конкретної роботи.

Вибір між CSS або JavaScript бібліотеки анімації

Перше, що я розглянув, коли вибирав бібліотеку анімації, це вибрати CSS чи бібліотеку на основі JavaScript. Є багато чудові бібліотеки CSS, багато з них із чудовою продуктивністю, що було для мене високим пріоритетом. Я хотів створити кілька важких анімацій, як-от можливість послідовності анімацій і отримання зворотних викликів після завершення анімації. Все це цілком можливо з чистим CSS — все ж він набагато менш гладкий, ніж те, що пропонують більшість бібліотек JavaScript.

Давайте подивимося, як виглядає проста послідовна анімація в CSS, і порівняємо її з jQuery, який має багато вбудованих помічників анімації:

Анімації виглядають однаково, але створюються по-різному. Щоб створити CSS-анімацію, спочатку ми повинні визначити анімацію ключового кадру в нашому CSS і приєднати її до класу:

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

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

Потім ми виконуємо анімацію за допомогою JavaScript і прослуховуємо зворотний виклик CSS для елемента:

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

Якщо речі відбуваються в різних місцях, це може бути добре в такому простому прикладі, як цей, але це може стати дуже заплутаним, коли все стане трохи складнішим. 

Порівняйте це з тим, як виконується анімація за допомогою jQuery:

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

Тут все відбувається в тому самому місці, що спрощує речі, якщо анімація стане складнішою в майбутньому.

Здавалося очевидним, що бібліотека JavaScript — це правильний шлях, але яку з них краще вибрати для пасьянсів? Я маю на увазі, що jQuery чудовий і все ще широко використовується навіть сьогодні, але це не те, на що я хочу повісити свій капелюх. Існує багато бібліотек анімації JavaScript, тому я хотів розглянути щось, створене спеціально для роботи з типом важкої анімації, який я мав на увазі.

Вибір бібліотеки анімації JavaScript

Мені швидко стало зрозуміло, що анімаційних бібліотек JavaScript не бракує нові, захоплюючі технології. Усі вони мають переваги та недоліки, тому давайте розглянемо деякі з них, які я розглянув, і чому.

Команда API веб-анімації є одним із таких випадків, який може замінити багато бібліотек анімації JavaScript у майбутньому. З ним ви зможете створювати складні анімації в шаховому порядку без завантаження будь-яких зовнішніх бібліотек і з тією ж продуктивністю, що й анімації CSS. Єдиний недолік полягає в тому, що ще не всі браузери підтримують це. 

Команда <canvas> елемент дає ще одну захоплюючу можливість. У ньому ми можемо анімувати речі за допомогою JavaScript, як і з DOM, але анімація відтворюється як растрова, що означає, що ми можемо створювати деякі високопродуктивні анімації. Єдиним недоліком є ​​те, що елемент canvas по суті рендериться як зображення в DOM, тому, якщо ми шукаємо піксельну досконалість, нам може не пощастити. Для мене, як для людини, яка глибоко відповідає дизайну, це порушило справу.

Мені потрібно було щось перевірене, тож я знав, що, ймовірно, доведеться скористатися однією з багатьох бібліотек JavaScript. Я почав шукати бібліотеки та звузив свій вибір до Anime.js та GSAP. Здавалося, вони обидва добре справлялися зі складною анімацією та мали чудові зауваження щодо продуктивності. Anime — це добре підтримувана бібліотека з понад 42.000 XNUMX зірок на GitHub, тоді як GSAP — це надпопулярна, перевірена в боях бібліотека з процвітаючою спільнотою.

Активна спільнота була для мене критично важливою, оскільки мені потрібно було місце, щоб попросити про допомогу, і я не хотів користуватися бібліотекою, яку пізніше могли б покинути. Я вважав це частиною своїх вимог щодо зручності.

Послідовність анімацій і зворотних викликів

Коли я звузив вибір, наступним кроком стала реалізація складної анімації за допомогою двох моїх бібліотек. Повторювана анімація в пасьянсі — це анімація карти, яка кудись рухається, а потім перевертається, тому давайте подивимося, як це виглядає:

Обидві анімації виглядають чудово! Вони плавні, і впровадження обох було досить простим. Обидві бібліотеки мали а функція шкали часу що зробило створення послідовностей простою справою. Ось як реалізація виглядає в 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
})

Аніме timeline() функція вбудовані зворотні виклики на початку та в кінці анімації, а створення послідовності так само просто, як додавання послідовних анімацій. Спочатку я пересуваю картку, потім повертаю своє заднє зображення на 90 градусів, щоб воно вийшло з поля зору, а потім повертаю своє переднє зображення на 90 градусів, щоб воно з’явилося в полі зору.

Така сама реалізація з використанням GSAP timeline() функція виглядає дуже схоже:

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

Час прийняття рішення

Основна відмінність між Anime і GSAP полягає в синтаксисі, де GSAP може бути трохи складнішим. Я застряг із двома чудовими бібліотеками, які мали дуже схожу функціональність, могли працювати зі складною анімацією та мали процвітаючу спільноту. Здавалося, у мене нічия!

Пріоритет	Аніме	GSAP
Гладка анімація	✅	✅
продуктивність	✅	✅
Зручність	✅	✅
Підтримка браузерів	✅	✅

Отже, що змусило мене вибрати одну бібліотеку замість іншої?

Мене дуже хвилювало, як бібліотека діятиме під тиском. Наявність затримки анімації в такій грі, як Solitaire, може значно вплинути на те, наскільки весело грати в гру. Я знав, що не зможу повністю побачити, як працює бібліотека, до того як створив гру. На щастя, GSAP зробив a стрес-тест який порівнював різні бібліотеки анімації одна з одною, включаючи Anime.

Дивлячись на це, GSAP, безсумнівно, виглядала як найкраща бібліотека для роботи з великою кількістю складних анімацій. GSAP давав мені понад 26 кадрів на секунду на важкій анімації, яку Anime вдалося перевищити лише на 19. Після того, як я прочитав більше про GSAP і заглянув на їхні форуми, стало зрозуміло, що продуктивність є найвищим пріоритетом для хлопців. за GSAP.

І незважаючи на те, що і GSAP, і Anime існують вже деякий час, репозиторій Anime кілька років перебував у стані бездіяльності, у той час як GSAP взяв зобов’язання за останні пару місяців.

Я закінчив використовувати GSAP і не пошкодував про своє рішення!

Як щодо тебе? Чи збігається щось із цього з тим, як ви оцінюєте та порівнюєте зовнішні інструменти? Чи є інші пріоритети, які ви, можливо, розглядали (наприклад, доступність тощо) у подібному проекті? Або у вас є проект, де вам довелося скоротити свій вибір із купи різних варіантів? Будь ласка, поділіться в коментарях, тому що я хочу знати! 

О, і якщо ви хочете побачити, як це виглядає під час анімації цілої колоди карт, ви можете зайти на мій сайт і зіграти в пасьянс, Отримуйте задоволення!