Ivan Bogachev

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

• Есть несколько секций с overflow: hidden
  
• Иконки дублируются в каждой секции, но с разными цветами
  
• В процессе скролла двигаем иконки, чтобы они оказывались на одном и том же месте относительно экрана
  

Прототип для изучения:

Вариант сделать это на position: fixed - не вариант, т.к. в сочетании с overflow: hidden может происходить неведомая магия.

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

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

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

Попробовал набросать свой вариант без jQuery:

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

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

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

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

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

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

result.hasOwnProperty(i) не может быть false. Во всяком случае я не придумал подходящего "кейса".

Может быть и false, если какое-то свойство определено в прототипе:

class Test {
    constructor() {
        this.foo = 'foo';
    }
};

Test.prototype.bar = 'bar';

const test = new Test();

console.log('foo' in test); // true
console.log('bar' in test); // true
console.log(test.hasOwnProperty('foo')); // true
console.log(test.hasOwnProperty('bar')); // false

Раз используется p5.js, то было бы логично взять функцию clear и в начале рисования кадра анимации очищать canvas:

function draw() {
    clear();
    // . . .
}

Если я все правильно понял:

function getRandoms(n, min, max, range) {
    let possibleNumbers = Array.from(
        Array(max - min + 1).keys(), x => x + min);
    
    let randoms = [];
    
    for (let i = 0; i < n; i++) {
        if (possibleNumbers.length === 0) {
            break;
        }
        
        const index = Math.floor(Math.random() * possibleNumbers.length);
        const value = possibleNumbers[index];
        
        randoms.push(value);
        
        for (let j = index + range; j > index - range; j--) {
            if (possibleNumbers[j] && Math.abs(possibleNumbers[j] - value) < range) {
                possibleNumbers.splice(j, 1);
            }
        }
    }
    
    return randoms;
}

$.ajax({
    type: 'POST',
    cache: false,
    url: '//woobl.ru/php/api/apiMusic/chat.php',
    success: function(data){
        console.log($.parseJSON(data.substr(1)));
    }
});

Можно округлить значение вручную:

format: {
    to: function (value) {
        return Math.ceil(value) + ' руб.';
    },
    // ...

В чем моя ошибка?

Вы изобретаете Array.slice:

function getPaginatedProducts(products, page) {
    const productsPerPage = 3;
    const begin = page * productsPerPage;
    const end = begin + productsPerPage;
    
    return products.slice(begin, end);
}

console.log(getPaginatedProducts(products, 0)); // 1,2,3
console.log(getPaginatedProducts(products, 1)); // 4,5,6
console.log(getPaginatedProducts(products, 2)); // 7,8,9

Перелопалит весь гугл - пусто.

Посмотрите примеры из этой статьи. К задаче так и напрашиваются SVG-маски.

Почему один код рабочий, другой нет?

Потому, что не blur, а onblur.

Например, если подключить так:

<link rel="stylesheet" href="http://evil.com/styles.css">

На CSS можно сделать недокейлоггер, который даст информацию о том, что пользователь начинает вводить (повторы одного и того же символа уже не срабатывают).

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

Можно издеваться над "отключением" кнопок (pointer-events к примеру поменять) или вообще скрыть какие-то важные блоки и пользователи не смогут нормально пользоваться сайтом. Для какого-нибудь магазина - это полный фейл как вы понимаете. Причем, в отличии от полного дефейса, пользователи могут даже не понять, что что-то не так.

Попробуйте добавить preserveAspectRatio="xMidYMid slice" к SVG с этими полигонами.

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

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

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