Ivan Bogachev

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

.items {
    .single-chart {
        .circular-chart {
            .circle {
                /* animation: progress 1s ease-out forwards; */
                transition: stroke-dasharray 1s ease-out;
            }
        }
    }
}

Prettier использует определенную логику для определения ситуаций, когда такие вещи должны быть разделены. Ее нельзя выключить. Этот инструмент в целом имеет очень мало настроек, он изначально очень строгий и нацелен на то, чтобы навязать свой стиль форматирования везде. В этом его философия. Не нужно спорить, как лучше форматировать. Робот все решит за нас.

Можно игнорировать какие-то конкретные штуки с помощью комментария // prettier-ignore. Но нужно ли?

если я перейду на визуализатор pixi то будет ли существенное повышение производительности?

Matter использует 2D канвас (если мы говорим про их стандартный рендерер). Pixi - WebGL. Ваш вопрос получается не про Pixi, как библиотеку, а про разницу технологий.

Когда-то было такое время, что 2D-канвас рендерился полностью на CPU, и тогда разница между ним и WebGL была в первую очередь обусловлена этим фактом. WebGL - это более низкоуровневый интерфейс с доступом к видеокарте. Много ядер, процессы хорошо распараллеливаются, при наличии прямых рук и понимания основ компьютерной графики все рендерится быстрее. Но в наше время и 2D-канвасы ускоряются видеокартой. Если очень грубо говорить, то сейчас 2D канвас - это тот же GL-канвас, но с более высокоуровневой обвязкой сверху. Чисто для удобства. Можно сказать, что разница в алгоритмах самого рендеринга с годами сводится к нулю, остается лишь разница в обвязке. Изначальная высокоуровневая структура вокруг 2D-канваса с кучей условно ненужного в конкретных случаях функционала не оптимизируются так эффективно, как бы нам хотелось. Она не умеет предсказывать наши намерения. Из-за этого переход от 2D к WebGL может дать прирост производительности. Но не столько за счет самого рендеринга, сколько за счет более умного переиспользования ресурсов и избавления от всех ненужных в конкретных случаях операций. Так что в целом идея взять двумерный рендерер на WebGL и делать в нем только то, что требуется, и ничего лишнего - все еще хорошая. Плюс у него будет сразу задел на использование своих кастомных шейдеров, что открывает целый мир визуальных эффектов, неподвластных 2D-канвасу.

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

В изначальных исходниках там TypeScript. Вы смотрите уже скомпилированный код. В исходниках местами все обернуто в разные условия, завязанные на__DEV__:

export function setExtraStackFrame(stack: null | string): void {
  if (__DEV__) {
    currentExtraStackFrame = stack;
  }
}

Когда происходила сборка кода, который вы смотрите, вероятно __DEV__ был true, условие было опущено, т.к. оно всегда выполняется, а скобки остались как артефакт. Скорее всего транспилятор TS не проверяет весь контекст, и чтобы ничего не сломать случайно, оставляет скобки на своих местах.

Никакой Three.js тут не нужен. Ну то есть, конечно, никто не мешает сделать все это на WebGL и прикрутить здоровенный фреймворк сверху, но все же это будет слегка избыточным решением в большинстве случаев. Такое можно аргументировать только если весь сайт изначально так и делается на WebGL и это просто "один из" эффектов, которые туда нужно интегрировать.

В 99% остальных случаев подобные штуки делаются одной svg-картинкой, одним path, который рисуется в зависимости от положения мышки и размеров контейнера. Немного школьной геометрии, ограничение диапазона возможных смещений всего этого - и дальше можно до посинения играть с алгоритмом расчета смещения, до тех пор, пока реакция на мышку не начнет нравится. Там уже нет универсального рецепта, все от дизайна зависит. Можно линейно привязать к положению мыши. Это обычно выглядит скучно. Можно использовать какую-то функцию от расстояния до центра, чтобы сделать движения менее равномерными. В каких-то случаях делают полноценный эффект инерции, как верно подмечено в соседнем ответе. Там получаются более естественные движения (обычно все это является развитием гравитационных моделей). Есть совсем замороченный подход, когда используется моделирование системы пружин (для общего развития можно загуглить силовые алгоритмы визуализации графов). Там можно получить целый ряд занятных эффектов, которые часто оказываются в тему как раз в таких фонах, где какие-то штуки связаны между собой прямыми линиями. Ну и можно просто вдохновиться какими-то физическими явлениями и сделать что-то "по мотивам".

В codepen я нашел интересный проект...

Это WebGL Fluid Simulation. И оригинальная ее версия на телефонах работает хорошо. Вы нашли какую-то из вариаций на тему этой штуки. Думаю для вас будет проще взять оригинал, а не отлаживать тот пример, который вы нашли.

через css хочу скрыть его, когда пуст

В такой формулировке можно обойтись без дополнительных классов:

.wishlist_products_counter_number:empty {
    display: none;
}

На этом сайте используется какая-то из версий WebGL Fluid Simulation.

var video = document.querySelector('video');

У вас в body нет ни одного тега video, соответственно с помощью querySelector не находится ничего, переменная video равна null, и дальше все ломается. Добавьте тег video и все заработает.

Вообще рисование линий обычно делается через изменение свойств stroke-dasharray и stroke-dashoffset у кривых в SVG. Это самый простой способ в рамках фронтенда, хотя и изначально эти вещи были для другого придуманы. Но в случае с ЭКГ нужна постоянная скорость рисования по горизонтали. Поэтому можно взять прямоугольную маску в рамках той же SVG, и двигать ее в сторону:

Плагин Dimensions замеряет расстояния через canvas. Реализация выглядит достаточно сложно...

Глаза боятся, а руки делают. Реализация не такая уж и сложная. Если на пальцах, то основной скрипт в основе dimensions берет данные по цветам всех пикселей картинки, координаты, откуда начать, а дальше просто ходит влево, вправо, вверх и вниз по пикселям и смотрит, насколько они отличаются по цвету. Если сильно отличаются - значит у нас нашлась граница между элементами. Сколько пикселей насчитал до границы - столько и показывает нам в ответ. И дальше весь вопрос в том, откуда взять картинку и координаты. В случае с расширением для браузера - он делает скриншот страницы и берет текущие координаты мышки. Но можно этот скрипт и отдельно от расширения использовать, просто скармливая ему свои картинки и координаты - это универсальная штука.

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

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

курсор смещается внутри квадрата(нужно чтобы он оставался в центре)

Если я правильно понял вопрос, то в JS:

// Там, где в двух местах есть работа с --x и --y
target.style.setProperty('--x', Math.floor(((e.clientX - rect.left) / rect.width * 100) * 100) / 100+'%');
target.style.setProperty('--y', Math.floor(((e.clientY - rect.top) / rect.height * 100) * 100) / 100+'%');
// нужна еще пара значений
target.style.setProperty('--new-x', e.clientX - rect.left + 'px');
target.style.setProperty('--new-y', e.clientY - rect.top + 'px');

и в CSS:

.image-zoom-block {
    /*
        left: var(--x);
        top: var(--y);
        transform: translateX(calc(var(--x) * -1)) translateY(calc(var(--y) * -1));
    */
    
    left: var(--new-x);
    top: var(--new-y);
    transform: translateX(-50%) translateY(-50%);
}

Можно ли как то совместить эти события, чтобы и слайды листать, и кнопки в плеере нажимать?

В том виде, в котором оно есть сейчас - нет. Проблема существует с 2013 года как минимум и будет решена примерно никогда, потому что обе стороны конфликта говорят, что проблема не на их стороне. Но можно вместо интерфейса от youtube прикрутить свой. То есть плеер оставить, но управление сделать свое, которое будет как-то сочетаться с имеющимся интерфейсом. Такой вот компромисс. Концептуально это будет выглядеть так, что мы убираем стандартный iframe, отключаем для плеера pointer-events:

<div class='swiper' id='my-slider'>
    <div class='swiper-wrapper'>
        <div class='swiper-slide'>Slide 1</div>
        <div class='swiper-slide' id='youtube-slide'>
            <div id='player'></div>
        </div>
        <div class='swiper-slide'>Slide 3</div>
        <div class='swiper-slide'>Slide 4</div>
    </div>
</div>
<style>
#player {
    pointer-events: none;
}
</style>

И переходим к API на js, чтобы сформировать свой плеер, который мы будем контролировать:

const youtubeScriptTag = document.createElement('script');
youtubeScriptTag.src = 'https://www.youtube.com/iframe_api';
document.body.appendChild(youtubeScriptTag);

window.onYouTubeIframeAPIReady = () => {
    const player = new YT.Player('player', {
        videoId: 'orbr-C3gYKk',
        playerVars: {
            controls: 0
        },
        events: {
            onReady: (event) => {
                const youtubeSlide = document.getElementById('youtube-slide');
                let isVideoPlaying = false;

                youtubeSlide.addEventListener('click', () => {
                    if (isVideoPlaying) {
                        event.target.stopVideo();
                    } else {
                        event.target.playVideo();
                    }

                    isVideoPlaying = !isVideoPlaying;
                });
            }
        }
    });
}

const swiper = new Swiper('#my-slider', {});

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

P.S.: На CodePen метод playVideo может не работать в Chrome-подобных браузерах из-за особенностей работы песочницы, но на обычной странице все должно быть ок.

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

// Тут, конечно, лучше какие-нибудь id сделать для однозначности
const circle = document.querySelector('.circle');
const arrow = document.querySelector('.arrow');

document.addEventListener('mousemove', (e) => {    
    const circleRect = circle.getBoundingClientRect();
    const circleCenterX = circleRect.left + circle.offsetWidth / 2;
    const circleCenterY = circleRect.top + circle.offsetHeight / 2;
    const deltaX = e.clientX - circleCenterX;
    const deltaY = e.clientY - circleCenterY;
    const angleInRadians = Math.atan2(deltaY, deltaX) - Math.PI / 2;
    const angleInDegrees = 180 * angleInRadians / Math.PI;
    const angleFrom0To360 = (angleInDegrees + 360) % 360;
    const shouldEffectBeApplied = deltaY < 0;
    
    if (shouldEffectBeApplied) {
        arrow.style.transform = `rotate(${angleFrom0To360}deg)`;
    }
});

И еще в таких штуках всегда хорошо добавить какой-нибудь transition в CSS:

.arrow {
    transition: transform .1s linear;
}

Имеете в виду что-то такое?