Ivan Bogachev

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

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

• Белый по светлому не читается. Белый по пестрому - тем более. Голубой по голубому - ох...
  
• Странное смешение шрифтов с засечками и без. Никакой системы в этом не наблюдается. Какую задачу эта разница решает - непонятно.
  
• Очень много разных размеров шрифтов и межбуквенных интервалов. Проблема та же - нет системы.
  
• Отступы везде разные. Внизу их вобще нет. Проблема та же.
  
• Местами намешана информация. Глаза разбегаются. Здесь явно прослеживается идея поэкранного скролла, или чего-то вроде него, но стоит подумать над тем, чтобы каждый экран был о чем-то одном. Первый про то, что это такое (зачем там какие-то характеристики про опыт и духов?), дальше описание сервера (зачем там реклама справа?), магазин вообще спрятался в куче рандомных фактов по краям, я его в первый раз даже не заметил.
  
• Не совсем понятно, как это должно адаптироваться под разные размеры экранов.
  

В целом докапываться можно много к чему, перечислять нет смысла, но общий посыл такой:

1. Обращайте внимание на систему в дизайне. Загуглите, что такое дизайн-система и почему простота и последовательность - это хорошо.
   
2. Думайте больше о доступности и адаптивности. Вы дизайн делаете для пользователей в первую очередь. Красочная картинка вторична.
   
3. Не нужно нагромождать все, как в газете. Это очень редко работает. Управляйте вниманием пользователей, не давайте ему растекаться во все стороны.
   

P.S.: Также в таких проектах всегда нужно быть готовым к диалогу с разработчиком и не допускать требований pixel-perfect по согласованным без него макетам. Это не так сложно сверстать, но вот эти штуки по краям с линиями и кубиками будут генерироваться на лету (для адаптивности). Они не будут 100% соответствовать нарисованному. Также тут так и напрашивается все эти картинки анимировать, как на текущем сайте mtg. Не знаю, как этот стиль называется, но WebGL - наше все. Да и эти кубики я бы сделал неспешно плывущими более-менее вниз с покачиваниями и поворотами... Но это уже следующий шаг. Первое - система в дизайне и доступность.

Мне стало интересно, это желательно или обязательно, то есть таскать с собой лицензию на каждый проект? Второе - да действительно первую версию я скачал из codepen и изменил код под себя, но в любом случае некоторые коды, название классов, прежний дизайн, остались прежними - автор в любом случае является тот, у кого я данный файл скачивал, изначально? то есть мои правки никак не влияют на то - кто автор?

В самом тексте лицензии написано, что она "shall be included in all copies or substantial portions of the Software". Так что да, включать ее нужно. Изначальный автор при этом остается автором изначального продукта. Вы - автор правок к нему. В рамках самого CodePen это принято обозначать в самой лицензии через понятие форка:

Copyright (c) 2020 by NEW_DEVELOPER_NAME (https://codepen.io/.....)
Fork of an original work ORIGINAL_WORK_NAME (https://codepen.io/.....)

Permission is hereby granted, free of charge, ...

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

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

...там работал обычный CSS, но был 3D объектом на который смотрит камера... Да, я видел всякие Three.js...

Как раз в Three.js есть такая штука как CSS 3D Renderer. Можно расположить условные div елементы в пространстве и работать с ними "в 3D".

task never defined: default

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

nmp

Ясное дело, что система не может найти nmp, когда он называется npm. Это сокращение от Node Package Manager.

Общая концепция будет примерно такая:

@keyframes custom-fade-in {
    0% {
        stroke-dasharray: 0 300;
        fill: transparent;
        animation-timing-function: ease-in;
    }
    50% {
        stroke-dasharray: 150 150;
        fill: transparent;
        animation-timing-function: ease-out;
    }
    100% {
        stroke-dasharray: 300 0;
        fill: #000;
    }
}

path {
    stroke: #000;
    fill: none;
    stroke-dasharray: 0 300;
    animation: custom-fade-in 2s ease-in-out infinite;
    animation-fill-mode: forwards;
}

Но если взять контуры как есть, то они будут заливаться не там, где нужно по дизайну. Нужно открыть эту SVG в векторном графическом редакторе и слегка порезать эти контуры. Нужно чтобы каждая буква была обрисована линией по кругу один раз, а не два, как сейчас. Тогда заливка будет по всей букве. А то сейчас заливается пространство между двумя почти продублированными контурами букв, т.к. технически именно оно является внутренной частью path. А еще будет удобно каждую букву делать отдельным контуром - проще будет подобрать значения для stroke-dasharray.

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

Если по типам файлов:

• Исходники с вашим кодом - однозначно да. Это самое главное.
  
• Все конфиги для сборки - да. Иначе без них проект не собрать. Исключение - какие-то ситуативно-локальные конфиги с ключами, паролями, и всем тем, что не должно попасть к другим людям. Но тогда это нужно описать в доках, что и где должно быть.
  
• Картинки - зависит от. SVG - скорее да, т.к. это текст. Растровые, особенно большие, может быть стоит хранить отдельно. Но это зависит от проекта и соглашений, главное избегать крайностей, чтобы репозиторий с лендингом не весил по пол гигабайта из-за исходников картинок или макетов. И это к любым бинарникам имеет отношение.
  
• node_modules - нет. Зависимости и зависимости зависимостей - это обычно тысячи файлов, которые вы никогда (ну почти никогда) не будете править своими руками. Они могут скачиваться при сборке проекта, в репозитории им делать нечего.
  
• Собранный и минифицированный проект - может быть. Зависит от применения. Обычно это не нужно хранить в системе контроля версий в том смысле, что минифицированные файлы мы все равно получаем при сборке и руками их не правим. Но иногда могут возникать ситуации вроде "хочу использовать репозиторий на GitHub как зеркало для моего NPM пакета" или "хочу захостить что-то на GitHub Pages", или "хочу, чтобы любая домохозяйка могла скопировать мой скрипт в свой бложик на wordpress и не парилась со сборкой", или еще что-то в этом духе. Иными словами, минифицированные файлы могут туда попасть, если вы понимаете, зачем это вам, какую задачу это решит. В общем случае пользы от этого никакой.
  

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

Не глядя в код, можно предположить использование следующих технологий:

1. Волны абстрактные и на фотографиях, шум на фоне - WebGL, шейдеры. Вода на первом экране - скорее всего моделируется как идеальная жидкость, волны на фотографиях - чисто геометрические.
   
2. Обведение текста в овал, трилистник с пунктиром, стрелки на карте - SVG, рисование линии по такому принципу.
   
3. Плавные переходы между экранами можно делать по-разному, даже забытый модными фронтендерами pjax будет к месту. Можно познакомиться с barba.js - это если не самый популярный, то один из популярных инструментов для работы с плавными переходами. Можно использовать роутеры из SPA-фреймворков, не принципиально. Самое сложное здесь - все синхронизировать.
   
4. Карта с персонажами - это может быть обычная верстка, подложенная под канвас с шумом. Самый простой вариант.
   
5. Есть небольшое покачивание элементов вслед за мышкой, логично предположить, что это банальная CSS-трансформация на mousemove.
   
6. Рисование дуг из точек - это может быть либо SVG, как в п.2, только эта линия будет маской, либо можно это строить как графики.
   
7. Ну и немного стандартных CSS-анимаций там тоже есть.
   

Дополнительные библиотеки здесь - дело вкуса, можно и на ванильном JS все сделать, разве что роутер я бы взял готовый. Вся соль в визуальных эффектах, а для них готовых решений не будет, если работа будет строиться по принципу "сначала придумать, потом сделать".

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

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

Можно заменить тень на фильтр:



Но такие штуки не отличаются хорошей кроссбраузерностью, а светлое будущее наступило еще не везде, так что в общем случае я бы рекомендовал использовать SVG-картинки.

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

Технически можно использовать практически все unicode символы, за исключением самых первых, управляющих. То есть это не только буквы, но и всевозможные символы вроде ∑∜♫ и.т.д. Они могут отсутствовать в каких-то шрифтах, но на функциональность CSS не повлияют. Как говорил Chris Coyier еще 10 лет назад: "yes-it-works-in-IE6™ & yes-it-validates™".

Другой вопрос - это практичность использования "альтернативных" селекторов. Тут есть несколько минусов:

• Есть устоявшиеся английские названия для всех стандартных элементов интерфейса и вспомогательных оберток. Использование других названий (в том числе на другом языке) приведет к потере скорости чтения кода, придется привыкать к новым именованиям.
  
• Придется постоянно переключаться между раскладками при написании кода. Минус к удобству.
  
• В любимой IDE вашего коллеги может быть шрифт, не поддерживающий ваши альтернативные non-ascii символы. Ему будет плохо.
  

Так что да, использовать можно, но как только у вас появятся коллеги, ваш код скорее всего начнут сравнивать с языком YoptaScript и вам придется переучиться на использование английского, чтобы "быть как все" и соответствовать общепринятым стандартам.

Поскольку мы видим неравномерные искажения картинки - варианты реализации этого на CSS и SVG отпадают. Единственный вариант - canvas и манипуляции с пикселями. С точки зрения производительности - лучше сразу смотреть в сторону WebGL и шейдеров. В этом контексте задача разделяется на четыре:

• Отобразить картинку на плоскости в WebGL контексте, оставив по краям немного прозрачности (чтобы был простор для искажений).
  
• Волны - это смещения пикселей. Характер может быть разным, но скорее всего будет что-то в духе "смещение пикселя = синус(положение пикселя + время)". Похожий пример есть вот в этой статье.
  
• Покраснение - при задании цвета пикселя во фрагментном шейдере увеличиваем значение R в рамках RGBA (в зависимости от времени).
  
• Дальше заменяем время на нужный нам параметр (скролл с верха страницы например, ну или что там вам нужно).
  

И да, GSAP к шейдерам не имеет никакого отношения. Он может быть применен для изменения упомянутого параметра (который заменяет время), но саму анимацию этот инструмент вам не сделает.