Frontender Magazine

Состояние веб-анимации в 2014 году

Эру после Flash вряд ли можно назвать свободной от анимации. Анимации на CSS быстро стали краеугольным камнем дружественных к пользователю интерфейсов на мобильных устройствах и настольных компьютерах, и библиотеки на JavaScript уже осуществляют управление сложно взаимодействующими анимациями. Вследствие такого большого количества обсуждений в духе «анимации на CSS против JavaScript», новое API, созданное специально для веб-анимаций, выходит, чтобы объединить оба враждующих лагеря.

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

То, что вы прочитаете здесь, является чисто наблюдательной и непредвзятой точкой зрения на тему веб-анимации.

Может быть эра Flash закончилась, но эра веб-анимации только начинается

Со времён эры Flash, стало модным думать, что анимации это не более, чем декорация, кричащее дополнение, зачастую безвкусное, как, например, тэг blink. Но на деле, если мы хотим показать на экране что то, кроме текста, анимация — наш лучший друг.

Для дизайнеров пользовательских интерфейсов, анимация закрепляет иерархию элементов и отношения между ними, структуру и причинно-следственные связи. Исследования из ранних 90х демонстрируют, что анимация позволяет людям лучше понять, что же происходит на экране. Анимации соединяют вместе состояния приложения и избавляют от этой работы GPU человеческого мозга — зрительную кору.

Для разработчиков интерактива, сложные визуальные эффекты — от инфографики на странице со сводной информацией о проекте до видеоигр на планшете — невозможно представить без анимации, связующей все кусочки вместе. Если мы хотим использовать всё это в Интернет, то нам нужны анимации.

К сожалению мы остались позади в гонке анимированной графики. Продукты, использующие анимацию на благо своих пользователей, ждёт успех, в то время как их статичных или злоупотребляющих анимацией конкурентов ждёт провал. В нынешнем состоянии, нативные приложения наголову разбивают веб. Их разработчики с самого начала могли использовать анимацию в своих проектах, ввести её в рабочий процесс, и инструменты прототипирования, вроде Flinto и Mitya.

Но всё ещё может обернуться иначе. Команда разработчиков Safari под iOS протолкнула спецификации CSS-анимаций и переходов, так что веб-сайты смогли быть стилизованы не хуже, чем приложения для iOS. Даже Google поддержал это, поставив анимацию в центр своих рекомендаций по Material Design, позаботившись о том, что стоит и чего не стоит делать, применяя анимацию и переходы осмысленно, с определённой целью.

Анимация — это естественный шаг в эволюции экосистемы приложений и устройств. Она делает цифровой мир более интуитивным и интересным для пользователей всех возрастов. И до тех пор, пока наши девайсы разгоняют GPU, она никуда не денется.

Анимация всего на свете

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

Статическая анимация воспроизводится от начального положения к конечному, без ветвлений или логики. Она может выполнятся на одном лишь CSS, как свидетельствуют множественные анимации загрузки на CSS.

Статическая анимация

Анимация с учётом состояний в самой простой форме принимает булево значение — клик для раскрытия меню и клик, чтобы закрыть его, например — и анимирует между двумя состояниями. В настоящее время это достигается в JavaScript-фреймворках через применение и удаление классов, содержащих CSS-анимацию.

Анимация с учётом состояний

Динамическая анимация может иметь множество результирующих состояний в зависимости от человеческих действий и других условий. Она использует свою собственную логику для определения того, как происходящее будет анимироваться и какими будут конечные положения. Это может быть перетаскивание страницы вслед за вашими пальцами, зависящее от скорости вашего движения, или динамическая перестройка графика, как только были получены новые данные. Этот тип анимаций более сложный чем те, которые позволяют нам доступные сегодня инструменты. Для его создания не получится использовать только CSS.

Динамическая анимация

Больше состояний != Динамическая Анимация

Проницательный разработчик может заметить, что с достаточным количеством состояний, CSS-анимация сильно напоминает динамическую. До определенного момента это так. Но настоящая динамическая анимация имеет гораздо больше конечных состояний, чем вы можете предвидеть.

Больше состояний != Динамическая Анимация

Просто представьте небольшую полосу загрузки. Имея отдельный класс для каждой точки «заполненности», будет легко написать сотню строк на CSS, не упоминая, сколько раз JavaScript затронет DOM для обновления классов и браузерной перерисовки. Мы определённо можем написать более производительную динамическую полосу загрузки на чистом JavaScript.

CSS анимации декларативны: не касаясь горстки псевдо-классов, таких как :hover и :target, они не принимают контекста ни от пользователя, ни от пользовательского окружения. Они делают только то, что автор им велел делать и не реагируют на новые действия пользователя или изменение среды. Не существует способа задать для CSS-анимации следующее «Если ты находишься в середине страницы, делай это; иначе, делай то». CSS не содержит логики такого сорта.

Когда разработчики, предпочитающие использовать для решения задач CSS, нуждаются в логике, они часто начинают создавать классы, соответствующие нужным состояниям, определяя через JavaScript, когда следует применить тот или иной класс. Такие фреймворки, как AngularJS поддерживают состояния, и многие взаимодействия с UI легко к ним адаптируются, например к состояниям «загрузка», «открыто» или «выбрано». Кроме того, анимации мягко деградируют в старых браузерах, а в тех, которые поддерживают анимации и переходы, делают процесс использования интерфейса значительно более приятным.

Разработчик интерфейсов против разработчика интерактива

Вот только разработчики интерактивных процессов с этим не согласны. CSS анимации зачастую слишком декларативны для реализации того, что они хотят. Клиенты, которые за всё платят, требуют надёжной поддержки анимации в распространённых браузерах; так, многие из разработчиков интерактивных процессов и их студии делают то, что делают все умные разработчики: создают трудосберегающие библиотеки, оптимизированные под их собственные процессы. Некоторые из этих библиотек, такие как GSAP и Velocity, доступны и разрабатываются для общественного использования. Но многие другие так никогда и не будут опубликованы, потому что у людей и агентств, создающих их, нет времени, денег или желания поддерживать open-source проекты.

Про релиз

Это и есть задевающая за живое история, которую я слышала раз за разом. Она даёт повод предполагать, что множество разработчиков продолжат изобретать колесо, если веб не совершит существенный шаг вперёд. Легко наблюдать, как библиотеки вроде GSAP вынуждены становиться коммерческими в борьбе за выживание, или как библиотеки вроде Velocity поддерживаются за счёт спонсоров.

Flash властвует

И Flash был великодушным диктатором, давшим своим людям визуальную временную шкалу.

Flash сделал великую вещь, предоставив интерактивным разработчикам и дизайнерам UI универсальную среду, выполняющую анимации любого типа, и платформу для их редактирования. Но с тех пор, как Стив Джобс ещё в 2010 году объявил, что iPhone никогда не будет поддерживать Flash, множество бывших разработчиков на Flash тихо ушло в отставку, забрав свои нишевые знания с собой. Сейчас, целое поколение веб-дизайнеров приходит без знания возможностей и проблем, с которыми мы сталкиваемся лицом к лицу, когда возрастает сложность анимации.

Но ситуация начинает меняться к лучшему.

Web Animation API: Величайший API о котором вы никогда не слышали

Web Animation API — это спецификация W3C, которая устанавливает объединённый язык для CSS и SVG анимаций, и открывает браузерный анимационный движок для использования разработчиками. Она выполняет следующие функции:

Вот один из примеров того, что Web Animation API может, а чистый CSS нет:

Посмотрите пример того, как работает Web Animations API от Rachel Nabors (@rachelnabors) на CodePen.

Поддержка

Web Animation API находится в разработке уже более двух лет, и его фичи выкатываются в ночных сборках Chrome и Firefox в течение последних 6 месяцев. Mozilla является главной движущей силой спецификации, в то время как у команды Chrome в приоритете реализация функционала.

Microsoft держит API «на рассмотрении» для реализации в Internet Explorer. В Apple, на удивление, также заняли выжидательную позицию. И мы можем лишь фантазировать о том, когда поддержка API появится в веб-движках, построенных на старых форках опенсорсных браузеров.

Экспериментаторы, которые желают попробовать API, могут использовать полифил для Web Animations API, который заменяется на Web Animations Next (больше про полифил и API можно узнать на веб-сайте проекта Polymer). Однако, для браузеров не поддерживающих API, полифил всё ещё будет менее производительным, чем GSAP, абсолютный чемпион среди анимационных библиотек написанных на JavaScript. Таким образом, этот полифил не то, что разработчики интерактивных процессов хотели бы увидеть в своих высокопроизводительных проектах.

Должно будет пройти некоторое время, прежде чем этот API начнёт поддерживаться повсеместно. Часть производителей браузеров выжидает, желая увидеть, как разработчики будут его использовать, и большая часть разработчиков откладывает использование инструментов, пока они не начнут широко поддерживаться, так API испытывает на себе проблему «курицы и яйца». Однако, во время беседы с Полом Кинланом (Paul Kinlan) из Google на конференции Fronteers, я предположила, что если API будет полностью поддерживаться в закрытых и монетизированных системах для веб-приложений, вроде Google Play, разработчики смогут благополучно использовать его в этой песочнице, пока он не достигнет зрелости и широкой поддержки браузерами.

Производительность

Авторы и проектировщики API надеются, что разработчики анимационных библиотек начнут задумываться о поддержке API благодаря выгоде от его производительности. Так как Web Animation API использует движок рендеринга CSS, мы можем ожидать уровня производительности CSS. Анимации будут проигрываться в своём собственном потоке до тех самых пор, пока они независимы от чего-либо в основном потоке, например от JavaScript или разметки.

Говоря о лэйауте, рефлоу был и остаётся самым узким местом с точки зрения производительности. Ни CSS, ни JavaScript не могут его избежать, если конечно не отправлять всё используя WebGL непосредственно в GPU (как некоторые доморощенные умники, занимающиеся разработкой библиотек, собственно, и делают). Не считая opacity и transform, анимация большинства CSS-свойств вызовет перестроение и/или повторную отрисовку части страницы. CSS-свойство will-change немного облегчит задачу, позволив нам указать на что-то и сказать браузеру, «Вот, вот эта вещь будет меняться. Сделай что нужно, чтобы изменения прошли эффективно.» Остаётся надеяться, что пока браузеры учатся обращаться с графикой, они переносят эти элементы на отдельный слой или иначе оптимизируют обработку этой графики. Это первый шаг к освобождению от таких хаков как translateZ(0).

Такие «хаки производительности» часто используются в качестве магического фикса всякий раз, когда анимация проседает, но они вызывают проблемы с производительностью, если используются бездумно. В долгосрочной перспективе лучше всего действительно положиться на браузеры в вопросах производительности. К счастью, разработчики браузеров борются за то, чтобы как можно меньшее количество свойств затрагивало остальные элементы на странице, таким образом держа их в стороне от основного потока. Для разработчиков анимационных библиотек это означает, что Web Animation API станет выигрышным союзником в борьбе за производительность в ближайшем будущем.

Инструменты

Любому, кто работал с веб-анимацией, знакома тоска по соответствующим инструментам разработки: временной шкале, инспектору свойств, хорошим редакторам, и возможности поставить на паузу, перемотать и проинспектировать анимацию во время отладки. Web Animation API сделает доступным движок рендеринга CSS и разработчикам, и самим браузерным вендорам для создания таких инструментов. Chrome и Firefox готовят соответствующий функционал для своих инструментов разработки. API делает это возможным.

Сообщество

Не так много людей, помимо тех, кто работает над ним, знают про Web Animation API. Сообщество веб-стандартов жаждет получить реальные отзывы от разработчиков интерактивных процессов и анимационных библиотек. Однако, многим разработчикам кажется, будто авторы находятся за каменной стеной, далеко от суровой реальности, потребностей клиентов и уроков, полученных со времён Flash.

08-flash-exile-opt

Старого гвардейца отправили в ссылку те самые люди, которым он когда-то служил.

Если честно, разработчики стандартов и правда не очень-то стремятся к встрече со своей аудиторией. Для вступления в «официальное» сообщество Web Animation API, вам придётся приложить усилия, и пробиться в переписке с разработчиком, у которого и так переполнена вся почта. Кроме того, вы можете попытать счастья, подключившись к каналу в IRC — если предположить, что дизайнеры используют IRC. Беседа, которая должна состояться, вряд ли когда-нибудь состоится, если людей, которым есть что сказать, просто на ней не будет. Вендоры и авторы спецификации должны найти больше способов достучаться до своей аудитории, иначе существует риск создать API, у которого не будет аудитории совсем.

Но авторы стандарта не единственные, у кого проблемы с коммуникацией. Как сообщество, мы можем поверхностно и скоро высмеивать те вещи, которые кажутся нам неподходящими или не нравятся. Многие из нас вкладывают своё эго в наши инструменты и процессы. Но эти вещи не определяют нас. То, что мы создаём вместе, определяет нас.

Благодаря веб-анимации, мы имеем редкий шанс отложить наше эго в сторону и объединиться для создания инструментов с помощью которых будущие поколения дизайнеров и разработчиков смогут создавать грандиозные вещи. Ради них, я надеюсь мы сможем.

“Искусство бросает вызов технологиям, а технологии вдохновляют искусство.”

– Джон Лассетер (John Lasseter), CCO Pixar

Источники

У Рэйчел Нэйборс (Rachel Nabors) есть обновляемый список ресурсов по Web Animation API. Чтобы присоединиться к неофициальному обсуждению, поищите по хэштэгу #waapi везде, где вам хотелось бы общаться.

Присоединиться к обсуждению

Внести вклад

Люди которые имеют знакомство с C++ могут помочь воплощать API в Firefox. Брайан Бёртлс (Brian Birtles) возможно даже будет наставлять вас! Ещё Mozilla постоянно ищет людей, готовых помочь с написанием документации на MDN.

Незначительные корректировки в спецификации (грамматика, орфография, несогласованности, и т.п.) могут быть отправлены через пулл-реквест на GitHub.

Люди в Твиттере

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом Антону Немцеву в skype ravencry.

Rachel Nabors
Автор:
Rachel Nabors
GitHub:
rachelnabors
Twitter:
@rachelnabors
Сaйт:
http://rachelnabors.com/
Екатерина Юрина
Переводчик:
Екатерина Юрина
GitHub:
yukkat
Twitter:
@_yukkat
Facebook:
yukkate

Комментарии (1 комментарий, если быть точным)

Автар пользователя
lolmaus

Я фронтендщик в стартапе. Оба моих шефа -- дизайнеры. По их требованию, мы вставляем на сайт и в вэб-приложение canvas-анимации, экспортированные из Adobe Flash при помощи CreateJS (EaselJS). Эти анимации ужасно тормозят. :(

Я очень глубоко скорблю.