RAX7

Для начала для нас важно осознать, что у разных фильтров разная вычислительная сложность. Они не все "плохие". Алгоритмы для brightness, grayscale, hue-rotate и других манипуляций с цветом выполняются за O(1) для каждого пикселя. Т.е. нагрузка на железо растет линейно в зависимости от площади элемента на экране. Это не так страшно. А вот фильтры размытия, blur или drop-shadow, имеют сложность где-то в районе O(R^2). Там есть разные варианты оптимизаций, но в среднем мы говорим именно о квадратичной зависимости от радиуса размытия. И это для каждого пикселя. Именно отсюда мы имеем сильные тормоза при попытке что-то большое размыть на пол экрана. Дохлые видеокарты телефонов и ноутбуков не вывозят. Браузеры не умеют такие вещи переиспользовать, так что это переразмытие происходит снова и снова, и мы имеем что имеем.

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

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

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

type ExtractGenerics<T extends readonly unknown[]> = T extends readonly []
  ? []
  : T extends readonly [G<infer V>, ...infer Next]
    ? [V, ...ExtractGenerics<Next>]
    : never;

function unwrap<C extends readonly G<unknown>[]>(containers: C) {
  return containers.map(container => container.value) as ExtractGenerics<C>
}

https://www.typescriptlang.org/play?#code/C4TwDgpg...

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

Может, вам поможет обычный css и селектор типа

:nth-child(3):last-child {
  тут стили, если третий является последним
}

Ограничение в фиксированных ширине и количестве табов.

Попробовать так и сяк

function func(mixedData) {
  const id = mixedData?.target?.id ?? mixedData;
  console.log(id);
}

func(123) // 123
func({target: {id: 456}}) // 456

Что это было?!
?. — optional chaining
?? — Nullish coalescing operator

Но это всё не фэн-шуёво, не аккуратненько как-то.
Лучше бы функции строго принимать один тип параметра — ожидать только id.
А что-то поменять при вызовах.

Сделана в After Effects.

Помимо озвученной критики, дополню: длина ролика ровно 10 секунд.

Повторяющийся момент, вычисление суммы последовательности от 0 до N с шагом — в функцию.

Сложить ряд с шагом 3, ряд с шагом 5 и вычесть места, где они пересекаются и значения двоятся: в кратных 15 – тоже ряд, с шагом 15.

const sum = number => {
  if (number < 0) return 0;

  // вспомогательная функция считает сумму ряда с шагом step
  const sequenceSum = step => {
    const q = Math.floor(number / step);
    return q * (q + 1) * step / 2;
  }

  return sequenceSum(3) + sequenceSum(5) - sequenceSum(3 * 5);
}

sum(18) // 78

Эта разметка абсолютно правильная в двух случаях:
1) Ваши `close` и `card` действительно нигде не переиспользуются;
2) Объём стилей блока `some-class` остаётся адекватным для восприятия.

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

Возьмём разметку посложнее (не надо в ней искать какого-то смысла, просто от фонаря что-то набрал для иллюстрации):

<div class="block">
  <!-- Header -->
  <div class="block__header">
    <h2 class="block__title">Title</h2>
    <div class="block__actions">
      <button type="button" class="block__action block__action--edit">
        <span class="block__action-icon"></span>
      </button>
    </div>
  </div>
  <!-- Content -->
  <div class="block__content">
    <p>...</p>
  </div>
  <!-- Footer -->
  <div class="block__footer">
    <div class="block__about">
      <div class="block__author"></div>
      <div class="block__date"></div>
    </div>
    <div class="block__awards">
      <div class="block__award">
        <div class="block__award-inner"></div>
        <div class="block__award-tooltip">
          <div class="block__award-tooltip-content"></div>
          <button type="button" class="block__award-tooltip-close"></button>
        </div>
      </div>
    </div>
  </div>
</div>

Положим, что весь контент этого блока уникальный и никак не переиспользуется.
Объём стилей `block` при такой структуре неизбежно станет некомфортным для восприятия, строк на 200-300.

В таком случае хорошо создать внутренний блок (или несколько) просто для того, чтобы размазать сложность.
`block-header`, `block-footer` или даже `block-footer-award`.

Самое главное здесь организовать файловую структуру / конфигурационный файл / чем вы там ещё собираете таким образом, чтобы было очевидно, что `block-footer` - это не самостоятельный блок, а внутренний блок `block`, нужный только для упрощения восприятия, и он не может / не должен использоваться в отрыве от него (в этом случае у него не должно быть в названии общего префикса с `block`, чтобы не создавать путаницу)

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

В прошлом тысячелетии были браузеры, которые не понимали тег <script> и отображали его содержимое на странице. Потому содержимое тегов <script> было принято комментировать, чтобы не пугать пользователя.
Зачем это продолжают делать в opencart в 2022 - неведомо, возможно дань традиции.

Я бы так сделал:
https://www.typescriptlang.org/play?#code/PTAEiQQR...

Во-первых, infer в самом предикате участвует как any
Во-вторых, функция с меньшим количеством аргументов является подтипом для функции с большим количеством аргументов (это позволяет, например, отдать в колбэк функцию, которая не использует всех переданных ей аргументов)

То есть тип () => void является потомком типа (param: any) => void, а значит Ваш предикат в типе A становится истинным и уходит в ветку, где Вы возвращаете R из infer, который выводится к вершине иерархии - типу unknown

То что Вы задумали, можно сделать так:

type A<T> = T extends (...param: infer P) => void
  ? P extends [infer R, ...unknown[]]
    ? R
    : string
  : string;

Лично я использую Coub Assistant.

не могу найти в поиске

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

Пример с SVG:


Пример с шейдерами (не совсем такой, но для передачи идеи пойдет):