Ivan Bogachev

Могу предположить что что-то на подобии gsap

Если рассматривать эту задачу в целом, без привязки к конкретному сайту, то это задача по созданию мультиков, в больших количествах, на потоке, в рамках сформированной дизайнерской системы. Делать это за счет фронтендеров - такая себе идея. Сложно всех синхронизировать, очень много накладных расходов. Это будет реально дорогая разработка. И разработчики нужны очень прошаренные по части анимаций, чтобы они были со всей командой дизайнеров на одной волне. Таких днем с огнем не найдешь. Более простой и дешевый подход состоит в том, чтобы этим всем занимались моушен-дизайнеры в рамках экосистемы Lottie. А со стороны разработки мы только интегрировали готовые сценки в сайт или приложение. В последние годы обычно все так и делают. Наш стек здесь не имеет значения, равно как и умения разработчиков.

Неоднородные плавные искривления никак не получится сделать в рамках CSS или SVG. Плюс волна трехмерная, поэтому изобретать что-то в 2d-канвасе будет непрактично и скорее всего сложно в плане производительности. Поэтому использование WebGL - это естественный выбор. Конкретные библиотеки/фреймворки не имеют значения, в конечном счете все такие волны сводятся к простой схеме:

1. Берем плоскость
   
2. На плоскость накладываем какую-нибудь красивую текстуру
   
3. Добавляем вершин побольше
   
4. В вершинном шейдере делаем какой-то генератор шума и используем значения из него чтобы двигать вершины туда-сюда в направлении, перпендикулярном плоскости
   
5. Опционально там же рассчитываем нормали для освещения
   
6. Играемся с коэффициентами до посинения, пока результат не начнет нравиться
   

В соседнем ответе все верно написали. CSS-трансформации - это именно то, что нужно в такой ситуации. Технически вся красота возникает из-за параллакса - там несколько слоев движутся с разной скоростью. Так что здесь не обязательно именно слайдер использовать - это может быть любой инструмент для построения кастомного скролла (с инерцией). При желании можно свой написать, это не так сложно, нужен лишь школьный справочник по физике, но можно и готовый инструмент взять. Тот же Locomotive Scroll вполне сгодится.

В этом примере как раз что-то похожее (только нужно открыть на CodePen - горизонтальный скролл не очень дружит с iframe-вставками):

У вас неправильный синтаксис keyframes - двоеточия и лишние скобки. Должно быть как-то так:

@keyframes load {
    0% {
        width: 0%;
        background: #f00;
    }
    50% {
        width: 70%;
        background: #00f;
    }
    100% {
        width: 100%;
        background: #0f0;
    }
}

Явно задайте элементу svg размер (width, height) в CSS. Проблема связана с тем, что браузеры могут по-разному определять размер элемента svg, когда он находится во flex-контейнере.

Скажите, насколько реально сделать эти два варианта с помощью CSS, или для этого нужно использовать другие какие-то технологии/программы?

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

Запустить крутиться планету

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

запустить надпись "Мир принадлежит тебе", тоже с прокруткой в левую сторону вокруг планеты

Юрий Артюх в одном из стримов делал как раз такую вращающуюся надпись. Очень прикольно получилось, стоит посмотреть.

P.S.: А еще всегда есть ход сусликом (про которого все забывают, но он есть) - сделать гифку и использовать ее, а не приплетать кучу скриптов для одной маленькой анимированной штучки.

Эта штука нынче затмила по популярности particles.js. Постоянно все о ней спрашивают, в том числе и на тостере:
Можно ли использовать чужой js код?
Как правильно вытащить код? с этой страницы...

Задача разделяется на две:
1. Анимировать саму линию
2. Перемещать огонь по ней

Под первую задачу так и напрашивается SVG (статья про пунктирные вау-эффекты). Ну а решение второй вытекает из первой, достаточно загуглить "перемещение объекта по path" или еще что-то в этом духе. Получаем что-то такое (код немного странен, я другой пример перевернул вверх дном, но идея должна быть понятна):


Остается только приделать монитор нарисовать огонь, но это уже другой вопрос.

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

Каких-то конкретных преимуществ этого подхода по сравнению с одним кадром на все я не вижу. Использовать ли для этого WebGL? Ну можно. Точно также, как и обычный canvas. Как выводить картинки на него вы легко загуглите, остается только посчитать координаты расположения кадров в картинке (по идее дизайнер должен их там аккуратно по сеточке расставлять) и выводить их по очереди.

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

Сама линия делается по вот такому принципу с помощью SVG:

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

Является ли желтая квадратная форма в конце анимации видоизмененной кнопкой или же это совершенно другой элемент разметки?

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


С такими анимациями можно долго играться, самое главное - проверить в конечном итоге кроссбраузерность. А то в хроме и FF работает, а в каком-нибудь IE всякое может случиться.

P.S.: Но в целом - я голосую за реализацию таких вещей целиком на JS. Практика показывает, что в проектах с такими анимациями очень быстро собирается большое количество одновременно анимирующихся значений у большого количества элементов, которые нужно синхронизировать между собой. На CSS голова лопнет все это делать. И да, чем больше всего меняется в CSS-анимациях в единицу времени, тем выше шанс найти какой-нибудь редкий баг и долго ломать себе голову в поисках проблемы. Лучше уж взять какую-нибудь библиотеку вроде anime.js или любимый многими GSAP и использовать их.

но которую можно реализовать и с помощью css, и с помощью javascript...
ваше мнение хотел услышать

Мне самому нравится делать все на CSS, но... Если анимация должна быть интерактивной и нужно ее останавливать в процессе, откатывать в изначальное положение и.т.д., или некоторые ее части зависят от данных (в широком смысле - это и движение по сложной траектории, и построение графиков и.т.д.) и их проще рассчитать скриптом, чем подбирать коэффициенты в CSS keyframes, то JS будет лучшим выбором. Если это последовательность мало связанных между собой изменений, то опять же скрипты почти всегда будет проще реализовать. Если речь идет о CSS-анимациях с фильтрами (особенно SVG-фильтрами), то можно влететь в очень сильные проблемы с производительностью на слабом железе. И никакие хаки с GPU тут не помогут - все равно будет тормозить. В такой ситуации может иметь смысл не просто писать на JS, но и подключить WebGL и все делать руками на шейдерах.

В остальных случаях стоит смотреть по ситуации - разные :hover / :focus эффекты обычно легко реализуются на CSS, и, если это так, то зачем что-то придумывать? CSS в последнее время очень даже неплох. Но если, например, в проекте вся анимация делается на JS, то может иметь смысл продолжать делать так же, сохраняя единообразие в коде.