Дмитрий Беляев

Пройдите свой код по шагам и сразу увидите, что keys - пустой массив
А reduce на пустом массиве просто возвращает init значение, даже не заходя в колбэк

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

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

Еще один важный момент, функциональное выражение (а стрелочная функция - это тоже функциональное выражение) внутри цикла будет создавать по функции на каждой итерации цикла. Это очень плохо и по памяти и по производительности (такие функции еще и компилироваться и оптимизироваться будут раздельно). И если в случае с let внутри цикла функции хотя бы будут отличаться замыканием (каждая замкнет свою i), то в первом случае будет 5 абсолютно идентичных функций.
Тут можно очень хорошо показать себя, если помимо объяснения принципов работы вспомнить, что setTimeout умеет передавать аргументы в свой колбэк:

const f = i => {
  console.log(i);
};
for (let i = 0; i < 5; i++) {
  setTimeout(f, 1000, i);
}

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

mutation observer ловит изменения, делает проверку и заполняет массив потоми делает запрос. Но тут почему то ajax не ждёт пока заполнится массив и сразу выполняет запрос.

К тому же эту проблему синхронный запрос не решит, он ее наоборот усугубит, так как MutationObserver так же не сможет отработать пока не завершится запрос.

Существуют ли случаи, когда оправдано использование синхронных запросов

единственное оправданное применение - отправка данных перед закрытием вкладки на динозаврах без поддержки sendBeacon
Заметьте, в современном fetch api даже нет такой возможности, как отправка синхронного запроса, и не просто так.

логика хромает и лучше всего все переписать

к сожалению появление асинхронности в одном месте может привести к появлению асинхронности во многих других местах, по другому ни как. Так что да, придется переписать. Но это неизбежно, так как многие api в современно браузере (тот же MutationObserver) работают только асинхронно. К счастью есть промисы и async/await сахар над ними, что сильно упрощает такую задачу.

Если type и subtype - строки, то можно так:

type CreatureBasis = {
    People: {
        child: {
            age: number;
            school: string;
        };
        adult: {
            age: number;
            height: number;
            weight: number;
        };
    };
    Animal: {
        fish: {
            waterBody: string;
        };
        cat: {
            catchMouses: boolean;
        };
    };
};
type Creature = {
    [K0 in keyof CreatureBasis]: {
        [K1 in keyof CreatureBasis[K0]]: {
            type: K0;
            subtype: K1;
            params: CreatureBasis[K0][K1];
        };
    }[keyof CreatureBasis[K0]];
}[keyof CreatureBasis];

https://www.typescriptlang.org/play?#code/C4TwDgpg...
TypeScript создавался чтоб затипизировать любую дичь, которую можно встретить в динамическом мире JavaScript. Как следствие у него тьюринг полная система типов, из чего есть 2 следствия:
1. при должном усердии можно затипизировать любую хотелку
2. некоторые особо навороченные типы могут повесить тайпчекер

https://pm2.keymetrics.io/

пишет так "/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=slack --file-forwarding com.slack.Slack --enable-features=WebRTCPipeWireCapturer @@u %U @@"

1. Создаем файл /usr/bin/slack и открываем текстовым редактором
2. Пишем:

#!/bin/bash
/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=slack --file-forwarding com.slack.Slack --enable-features=WebRTCPipeWireCapturer @@u %U @@

3. выполняем sudo chmod +x /usr/bin/slack

Как я понимаю в js два основных типа данных

Согласно спеке в JS есть 8 типов данных:

• object - все объекты и функции (в реальности во всех имплементациях у функций свой тип function)
  
• string - строки
  
• boolean - логические значения (true и false)
  
• number - числа с плавающей запятой двойной точности (в других языках это double или float64)
  
• bigint - целые числа (int64) с поддержкой длинной арифметики
  
• symbol - спец тип, каждое значение которого уникально
  
• undefined - юнит тип с единственным значением undefined, значение по умолчанию во многих случаях
  
• null - юнит тип с единственным значением null (в реальности во всех имплементациях null имеет тип object), задумывался и используется как аналог null pointer/null reference в других языках
  

Что происходит с типом данных когда str конкатинируется со строкой 'Vova' ?

с типом данных ничего не происходит. Значение получается новое, по крайней мере так должно быть согласно спеке и так все выглядит для рядового js разработчика.
На самом деле самый распространенный js движок v8 именно со строками делает под капотом разную магию, зная, что строки никогда не меняются он умеет их представлять в виде массива срезов (множества кусочков лежащих в разных местах), избегая тем самым дорогого копирования памяти. В данном примере result будет состоять из двух срезов, которые указывают на представление кода в памяти, притом первый кусок будет указывать на ту же память что и str. Но если result "доживет" до момента, когда сборщик мусора будет делать дефрагментацию памяти, то после нее он уже будет указывать на целую самостоятельную строку.

Вопрос вот в чем, так ли примитивы перезаписываются если с ними выполняются какие-то операции? Меня интересует сам алгоритм создания, что происходит внутри

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

Являются ли примитивные типы объектами?

С точки зрения спеки - нет, не являются. У них должны появляться объектные обертки в момент обращения к их полям (через точку или квадратные скобки).
На деле, если сделать как в спеке - все будет жутко тормозить. Поэтому в v8 почти все является объектом (правда не совсем таким, как мы видим объекты со стороны js), а соблюдение спеки для примитивных типов достигается через иммутабельность.
Исключением являются null и undefined, у которых нет ни полей, ни прототипа. Для них хранится только информация о типе.
Так же после оптимизаций jit компилятора числа могут избавится от объектных оберток, когда оптимизируемый код их не использует, тем самым избавляясь от разыменовывания указателя, при этом bigint может превратится в int64, а number в float64 или int32 в зависимости от использования. Так же, массивы состоящие только из чисел одного типа могут быть сведены к настоящим массивам из чисел, но этого эффекта можно достичь и до оптимизаций, если использовать типизированные массивы.

https://developer.mozilla.org/ru/docs/Web/JavaScri...
https://developer.mozilla.org/ru/docs/Web/JavaScri...

Но это из стандарта 2020 года, для поддержки более старых браузеров понадобится babel + preset-env

https://developer.mozilla.org/ru/docs/Web/API/Even...

$event в Vue как раз прокидывает нативный объект события