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

Как я понимаю в 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/en-US/docs/Web/API/H...
Нужно отслеживать change на select
option, на сколько помню, вообще не кидают событий

Генератор - это императивно управляемый итератор. Сами итераторы позволяют производить ленивые вычисления.

Практическое применение например в том, что можно построить высокоуровневые абстракции над итераторами:

function* counter() {
  let i = 0;
  while (true) {
    yield i++;
  }
}

function* map(innerIterator, f) {
  for (const value of innerIterator) {
    yield f(value);
  }
}

function* filter(innerIterator, f) {
  for (const value of innerIterator) {
    if (f(value)) {
      yield value;
    }
  }
}

function* take(innerIterator, count) {
  let i = 0;
  for (const value of innerIterator) {
    yield value;
    if (++i === count) { return }
  }
}

function* inspect(innerIterator) {
  for (const value of innerIterator) {
    console.log(value);
    yield value;
  }
}

console.log('Создаем итератор');
const iter = inspect(
  take(
    map(
      filter(
        counter(),
        v => v % 2 === 0
      ),
      v => v * 2
    ),
    30
  )
);
console.log('Итератор есть, но он еще ничего не считает: ', iter);
console.log('Вычисления будут по требованию:');
console.log([...iter]);

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

В JS Вам не нужно думать, о том сколько живут объекты, если у Вас есть ссылка - объект точно жив.

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

В JS у Вас никогда не будет Undefined Behavior.

В JS у Вас никогда не будет гонок данных, каждый поток (воркер) живет в своем пространстве памяти. И даже если Вы пошарите память, Вам не придется парится с атомиками/мьютексами и c memory order, все уже решили за Вас.

В C++ Вам придется об этом всем думать, если захотите написать что-то полезное.

const mediaQuery = window.matchMedia('(max-width: 992px)');
const handler = () => 
    $(document.body).toggleClass('lock', mediaQuery.matches);
mediaQuery.addListener(handler);
handler();

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

А вообще, такое спокойно через CSS можно делать:

@media (max-width: 992px) {
    body {
        /* тут то что у Вас в .lock было */
    }
}

Придется парсить ключи в обработчике submit:

const re = /(.+)\[(.+)\]\[(.+)\]/;
const formData = new FormData(drawingForm);
const result = {};
for (const [key, value] of Object.entries(formData)) {
    const matches = key.match(re);
    if (!matches) { continue }
    const [, k1, k2, k3] = matches;
    ((result[k1] ??= {})[k2] ??= {})[k3] = value;
}
console.log(result); // тут валидация

Стандарт VPAID описывает лишь интерфейс взаимодействия плеера с креативом.
Внутри может быть абсолютно любой код, который может делать все что угодно в рамках своего контекста, в том числе тоже быть плеером, который подгрузит рекламу по VAST/VPAID.

В VAST могут быть параметры для VPAID, но он не обязан их использовать. Он может сходить за рекламой на свой сервер, который ему заранее известен, или вообще воспроизводить рекламу, которая в него зашита.

А может и не рекламу крутить, я например как то делал в виде VPAID интерактивную вакансию и таргетировал ее на IT'шников через рекламные сети.