Ivan Bogachev

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

Выбор видео в данном случае решает два вопроса - экономию бюджета и обеспечение качества:

• Все это может делать один дизайнер (+ опционально 3D-художник) в специализированных программах. Это быстрее, чем руками кодировать (быстро = дешево). Дальше мы просто вставляем результат в страницу. Соответственно не нужен фронтендер, понимающий в компьютерной графике (таких долго и дорого искать), не нужно воссоздавать визуально сложные и утвержденные заказчиком эффекты на фронтендерских технологиях (это просто боль, плюс сроки, и, опять же лишний бюджет).
  
• Вопросы производительности отсутствуют. В теории можно взять WebGL и рендерить все на устройстве пользователя. Но на самом деле рассчитывать хитрое освещение в реальном времени всегда проблематично - там куда ни плюнь будут вычислительно-сложные алгоритмы. Что делать с ноутбуками со встроенной графикой или с телефонами? Это вечный вопрос. Часто такие проекты горят именно на том, что на старте разработчики не осознают, насколько там на самом деле требовательные алгоритмы, и к дедлайну все безнадежно тормозит. Приходится сильно упрощать картинку, жертвовать качеством изображения в угоду производительности. Чтобы в это не вляпаться, презентации товаров рендерят заранее (можно несколько секунд презентации хоть всю ночь рендерить), сохраняют или в видео, или в набор картинок, и уже их показывают конечному пользователю. Это стандартная практика.
  

Ошибка importScripts is not defined не говорит о том, что файла не существует. Она говорит о том, что функции importScripts нет в том контексте, в котором все выполняется. В стандартном глобальном Window ее нет. В WorkerGlobalScope она есть. Нужно убедиться в том, в каком контексте выполняется ваш код. Что есть self в вашем коде. Тут многое зависит от того, как вы делаете свое приложение и как создаются эти воркеры (в некоторых фреймворках может своя локальная магия происходить). Есть неиллюзорная вероятность, что ваш код воркера загружается два раза. И запускается два раза. И первый раз он запускается в основном потоке, где self - это получается window. Если это так, то можно сделать запуск кода воркера из тупой проверки-заглушки, что-нибудь вроде:

if (typeof importScripts === 'function') {
    importScripts('......js');
    // и все остальное тут
}

Это сомнительная практика, т.к. по идее этот код должен запускаться один раз с нужным контекстом, и мы лечим симптомы, а не изначальную болезнь, но она может решить проблему.

Смешались в кучу кони, люди, GSAP, React, Three.js... Стоит немного систематизировать инструменты хотя бы по задачам, которые они решают. Не привязываясь к конкретным фреймворкам из большой троицы, у нас есть несколько классов инструментов в теме креативных сайтов:

• Про готовые CSS-анимации - animate.css, Wow.js, и.т.д. Там много динозавров из времен jQuery. Такие штуки часто бывают не в тему дизайна, но стоит посмотреть и забыть. Хотя для сайтов в духе дизайнерской дичи, вроде той, что успешно делают в студии Артемия Лебедева - может быть и ок.
  
• Про интерполяцию всего и вся. Тут обычно выбирают между GSAP и Anime.js. Первый вариант - более замороченный, есть полезные плагины, второй - попроще, но тоже хорош, в некоторых кругах даже более популярен. Для совсем простых задач - можно свой инструмент написать.
  
• Про скролл, в основном в контексте CSS-анимаций. Тут Locomotive Scroll рулит.
  
• Про переходы между экранами. Грубо говоря прокаченный роутер. Самый популярный - Barba.js. Раньше еще был Highway.js, но в последне время что-то про него мало говорят.
  
• Про экспорт готовых анимаций из софта для анимаций. Тут нужно отталкиваться от софта. Обычно вопрос возникает в контексте AE и простых мультиков - тут Lottie, говорят, неплох. Но нужно дизайнера заранее консультировать по теме, чтобы лишнего не намалевал.
  
• Про визуализацию данных. Тут полезно знать про d3.js, в основном ради готовых примеров.
  
• Про трехмерный WebGL, чтобы не писать все руками. Самый популярный вариант - Three.js, в основном за счет экосистемы и горы готовых решений, но есть и альтернативы на любой кус и цвет. Для 2D -эффектов вообще ничего не нужно в большинстве случаев.
  
• Плюс не стоит забывать про всякие вспомогательные штуки вроде WebFontLoader, Hammer.js, LeaderLine, и.т.д. К анимациям они не относятся, но в работе могут быть полезны, чтобы не писать все самому.
  

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

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

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

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

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

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

Большая часть ресурсов - ситуативные (в основном это документации к конкретным библиотекам). Из более-менее часто используемого могу вспомнить:
MDN, DevDocs и Schema.org, чтобы вспоминать забытое.
Can I use, чтобы смотреть поддержку браузерами (+ doiuse).
WAVE и regex101, чтобы проверять себя.
В Browserhacks иногда полезно заглянуть.
FontPair и Coolors - если нужно без дизайнера подобрать шрифты и цвета.
Snazzy Maps, чтобы брать готовые цветовые схемы для карт.
Cubic-bezier, чтобы наглядно делать кривые для простых анимаций.
Google - если затупил.
Noisli - для фонового шума.
Cross Browser Testing, чтобы тестировать результат.

Как вы прокачивались?

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

На что стоит сделать упор в обучении именно верстки и малого количества js-а?

Методы зависят от наличия времени и изначального уровня обучаемых. В целом для развития понимания CSS полезно "рисовать" на нем. Грубо говоря один автопортрет или зверушка, сделанная самостоятельно от начала и до конца, даст опыта как десяток лендингов. В таких песочницах концентрация хитрых задач на верстку в разы выше, чем на обычных сайтах, и обучение идет быстрее. Ну и просто прикольные штуки получаются, можно внести элементы игры с плюшками за успехи. В последние годы эта тема стала очень популярной на CodePen в виде ежедневных разминок для ума.

Как обучали людей? У меня нет опыта в обучении людей

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

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

Вариантов много. По-хорошему, если вы пишете много простых компонетнов руками на чистом JS, то очень имеет смысл организовать систему классов для них. Один компонент - один класс. Организовать их можно по-разному (мне вот такая структура нравится). Для вашего примера можно начать с простого:

class MySlider {
    constructor(element, options) {
        const manager = new Hammer.Manager(element);
        
        manager.add(new Hammer.Pan({ threshold: 0, pointers: 0 }));
        manager.on('pan', (e) => {
            const percentage = 100 / options.numberOfSlides * e.deltaX / window.innerWidth;
            
            element.style.transform = `translateX(${percentage}%)`;
        });
    }
}

[].forEach.call(document.querySelectorAll('.slider-wrapper'), (element) => {
    const slider = new MySlider(element, { numberOfSlides: 2 });
});

Затем, чтобы собрать все в одном месте, упростить отладку и избавиться от повторяющегося кода, имеет смысл организовать мини-фабрику по производству компонентов. Что-то вроде такого. Таким образом вы не только решите свою задачу, но и упростите жизнь себе и тем, кто будет ваш код потом поддерживать.

какие паттерны применяются чаще всего на практике и где

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

1. Модули (делим код на независимые части)
   
2. Фабрики (для компонентов интерфейса)
   
3. Синглтоны (для хранилищ, точек сбора полифиллов / утилит и.т.д.)
   
4. Адаптеры (для зависимостей и полифилов, которые могут измениться / выпилиться)
   
5. Наблюдатели (для сбора происходящих событий в одном месте)
   
6. Хранители (для сохранения действий пользователя и "Ctrl-Z")
   
7. Стратегии (если действуем в зависимости от прилетевших данных)
   

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

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

Видел я людей, которые называли себя программистами и при этом до жути боялись открыть консоль и что-то в ней сделать. Думаю вы встречали таких. Их еще обычно издалека можно опознать по стремлению извратиться как угодно и поставить 100500 плагинов в свою ide, только чтобы не запускать консольку. Они как будно боятся мигающего курсора. Обычно это сопровождается боязнью экспериментов и вообще изучения нового. В первую очередь требование уметь работать с linux отсеивает подобных кандидатов.

В моем окружении фраза "навыки работы в Linux-системах" подразумевает, что вы можете настроить свое рабочее окружение, можете управлять зависимостями, запускать сборку, тесты, и при этом не отвлекать коллег тупыми вопросами в духе "я вошел в vim и теперь не знаю, как из него выйти". Какое-то серьезное администрирование наша профессия не предполагает (в компаниях, где оно вообще есть, обычно есть и отдельный админ), а вот все, что связано с повседневными задачами вы должны делать сами.

...может это какая библиотека js... ...и с помощью js менять длину...

Не нужен тут никакой JS, только два псевдоэлемента, :hover и transform: scale - codepen