Иван В

Почему в реальном доме нельзя таким же образом менять только те узлы которые изменились?

Если меняешь только 1 узел, разницы практически не будет.
Если меняешь целое дерево - уже сложнее.
Если писать руками, то можно пойти двумя путями:
1. Снести всё (под)дерево в реальном доме, а потом построить новое заново
2. Руками пройтись по дереву в реальном доме и изменить только те узлы, в которых реально поменялись данные.

Второй вариант будет экономить на вставках, но тогда придётся все элементы вычитывать из дома, а если это будет происходить в цикле, или просто очень часто, то возникнут заметные тормоза.
По-хорошему надо сохранять и кэшировать элементы, чтобы их по 10 раз не вычитывать.

Вот этим virtual DOM и занимается вместо разработчика.

Много где читал что изменения в виртуальном доме вызывает изменение всего дом дерева так ли это?

Это плохой сценарий, если используется что-то неправильно, или если реально надо перестроить всё дерево.

В конечном результате всё-равно виртуальный дом сравнивается с реальным изменяет только некоторые узлы, так почему сразу не сравнивать узлы которые изменились с реальным домом?

Описал выше - получится тогда vdom, либо потеряешь очень много производительности из-за постоянных запросов к дому.

Почему обновление реального дома очень затратно И как так получилось что создание новой абстракции в виде виртуального дома сделала его только быстрее?

Затратно, тк это обращение к API браузера, которое медленнее, чем просто обратиться к объекту в JS.
А выигрыш из-за того что мало кто хочет самостоятельно писать такую абстракцию для эффективной работы с реальным DOM.

gulp плагин для конкретно этого действия.
gulp-inject-in-html

pug - препроцессор. Много всего в том числе и это

Работа это не про фреймворки это про общение с людьми. Так что стоит . А научитесь хотябы тому что не задавать такие вопросы

1. Для чего замыкание существуют?

Для инкапсуляции данных.
В ООП есть модификаторы доступа (private, protected), которые закрывают доступ к данным извне класса, но позволяют обращаться к ним из методов.
В ФП для этой задачи используют замыкания, закрывая данные внутри функции. Из вне данные недоступны, но вложенные функции имеют к ним доступ.

2. В каких условиях они создаются?

Когда вложенная функция обращается к переменным внешней функции.

Хоть и просили без примеров, но на примере показать проще:

// makeCounter - внешняя функция
function makeCounter(initialValue) {
  var value = +initialValue || 0;
  // counter - внутренняя функция
  // она использует переменную value из внешней функции
  // что-бы это было возможным, для counter создается замыкание,
  // в котором хранится переменная value
  // переменная initialValue функции counter не нужна, поэтому ее можно "забыть"
  return function counter() {
    return value++;
  };
}

// у нас 3 экземпляра функции counter
var counter1 = makeCounter();
var counter2 = makeCounter();
var counter3 = makeCounter(100);
// и для каждой есть своя переменная value
console.log(counter1()); // 0
console.log(counter1()); // 1
console.log(counter2()); // 0
console.log(counter1()); // 2
console.log(counter3()); // 100

// а вот получить как-то напрямую переменную value мы не можем
// инкапсуляция нам не дает поломать данные

оставь ребенка в покое, нефиг собственные комплексы реализовывать.

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

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

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

В этом случае, либо при изменении EULA твой работодатель продолжает платить, либо перестаёт пользоваться.
Соломку надо стелить заранее.

Обычно работодатель настаивает на передаче всех прав на код разработанный в рамках трудового соглашения.
И это правильно.
Есть правда ньюансы в обе стороны.
США - выплаты роялити авторам если код приносит много денег.
Россия - претензии к NGINX

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

Если коротко, то - нет.

Можно регуляркой, можно через includes или indexOf.