Ivan Bogachev

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

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

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

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

...там работал обычный 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 к шейдерам не имеет никакого отношения. Он может быть применен для изменения упомянутого параметра (который заменяет время), но саму анимацию этот инструмент вам не сделает.

Есть три варианта:

const a = '"#512534"';   // <-- Другие кавычки
const b = "\"#512534\""; // <-- Экранизация
const c = `"#512534"`;   // <-- Шаблонные строки

Вы не указали % у первого фрейма. Безразмерное значение "0" некорректно. Умные браузеры могут добавить символ процента за вас, или могут просто пропустить "дефектный" фрейм, из-за чего будет казаться, что все работает, но полагаться на это не стоит.