Что выбрать для анимации: CSS или JavaScript библиотеку и почему

Что проверяют

Понимаете ли вы, как браузер рисует кадр, и выбираете ли инструмент по задаче. Вопрос кажется про вкус, а на деле проверяют знание конвейера рендеринга и умение назвать критерий выбора, а не предпочтение.

Как отвечать

Начать с главного: решает не язык, а какие свойства анимируются. transform и opacity обрабатываются на этапе композиции, без пересчёта геометрии и перерисовки. Всё остальное, включая width, top, margin и позиционирование, запускает раскладку или отрисовку в каждом кадре и одинаково тормозит, написано это на CSS или на JavaScript.

Дальше критерий выбора. CSS через transition и @keyframes берут, когда анимация декларативная, привязана к состоянию элемента и живёт короткой историей: наведение, появление, смена состояния. Кода мало, браузер сам управляет жизненным циклом.

JavaScript нужен, когда появляется управление: последовательности и таймлайны, прерывание на середине с плавным переходом к новой цели, зависимость от ввода или прокрутки, физика и пружины, анимация по вычисленным значениям. Web Animations API даёт такое управление без библиотеки и работает с теми же свойствами композиции, библиотеку стоит брать под сложные таймлайны.

Хорошо добавить два момента: измерять просадки в инструментах разработчика, а не на глаз, и уважать prefers-reduced-motion, иначе часть пользователей получит интерфейс, которым неприятно пользоваться.

Где спотыкаются

Заучили тезис «CSS всегда быстрее, потому что аппаратное ускорение». Анимация ширины или отступа на CSS тормозит ровно так же, ускорение касается только композиции.

Второе: двигают элемент вручную по таймеру. Шаг через setInterval не попадает в кадр и даёт рывки, а для покадровой анимации нужен requestAnimationFrame.

Третье: тянут тяжёлую библиотеку ради подсветки кнопки или расставляют will-change на всё подряд. Первое раздувает бандл, второе плодит лишние слои композиции и съедает память вместо того, чтобы ускорять.