mr-troll

Основной принцип разработки - KISS - keep it simple .
Вы же сделали сами для гифку для примера, она вас не устраивает чем? Качество прекрасное, я вот с мобилки смотрю. Оптимизация проигрывания - во всех браузерах потрясающая. Даже coub.com долгое время используют гифки с аудиодорожкой (возможно сейчас для видео выдают, тем кто поддерживает, webp или webm, не суть). Лишнего оверхеда нет, блок рисуется браузером один раз, лишних репеинтов, и прочего, нет, памяти и процессора жрется, вы удивитесь, просто в разы меньше, чем любая анимация с блоками. Из минусов, понятно, не такой красочный мокап, как в пнг,всего 256 цветов и максимум 1 бит прозрачности.
Не хотите гиф, ну, тут вам уже сказали, что нет никаких проблем, в т.ч с адаптивной вёрсткой.
У вас есть блок мокапа, у которого всегда жесткое соотношение сторон (например 4x3). У вас есть блок "экран" с анимацией тоже жёстко заданного соотношения относительно мокапа. Не надо выдумывать, задайте размер и позиционирование абсолютно в процентах. Проценты всегда будут считаться от высоты и ширины родителя (мокапа). Проценты можно высчитать и задавать дробно. Например left:22.222222%.
Как верстать мокап адаптивно? Я бы использовал юнит vw. 1vw = 1% ширины всего экрана. Отличие в том что он применяется и к высоте. Хотите на всю ширину на мобиле мокап 4х3? Задайте width:100vw;height:75vw;.
И не надо js анимации использовать, всё равно не оптимизируете нормально - либо страшные интервалы, либо задолбаетесь рассчитывать requestaninationframe. Используйте css анимации, лонгскрин не надо делать картинкой, надо бекграундом.
2 блока (например сам див и :before), 2 файла изображения, от силы 15 строк css - примерно должно быть в итоге.
Если извратиться через background image - можно в 1 html элемент вообще, с анимацией и без скриптов, адаптивно, клёво.

Как писал Джоел Спольски 10 лет назад

В начале девяностых многие из нас полагали, что главная битва произойдет между процедурным и объектно-ориентированным стилем программирования, и воспринимали объектно-ориентированное программирование как средство резкого повышения продуктивности программистов. Я тоже так думал. Некоторые до сих пор так думают. Получается, мы ошибались. Объектно-ориентированное программирование прикольная штука, но не повышает продуктивность, как это обещалось. Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или «сборка мусора», это может быть Java, Lisp, Visual Basic (даже 1.0), Smalltalk или любой язык написания скриптов. Если ваш язык программирования позволяет выделять кусок памяти без раздумий о его последующем освобождении, то вы используете язык с управляемой памятью, и вы будете значительно эффективней программиста, использующего язык, где управление памятью производится в явном виде. Всякий раз, когда вы слышите чье-то хвастовство о том, насколько продуктивен их язык, вероятно, большую часть продуктивности они достигают за счет автоматического управления памятью, даже если не признаются в этом.

Сейчас процедурный стиль преподносят как модное "функциональное программирование". Я работал во многих конторах, и, ооп используется в меньшинстве проектов (если даже отмести языки без нормального ооп, типа перл и питона).
Объект - стоит использовать если у вас есть набор данных и методов для работы с ними. Если у вас просто объект представляет массив функции для работы с внешними данными, например объект математических функций (пример Math в Js) или объект/класс функций для работы с бд - это не ооп. Если ваша единственная цель например отделить логику от представления, или сгуппировать всё в объект как в модуль или в неймспейс, то это тоже не ооп. Есть ряд вещей в которых ооп полезно, но нет ничего того что вы не сможете сделать в функциональном стиле.

В первом случае присваивание к объявленной переменной, во втором случае к не объявленной.
Если использовать строгий режим ("use strict" или модули) то будет ошибка. В не строгом режиме попадёт в глобальную переменную, например window.x(), а y() будет локальной, в той области где находится.