Алексей Ярков

• типы запросов (POST, GET, PUT, UPDATE, DELETE, OPTIONS и т.д.),
  
• заголовки запроса, ответа
  
• коды состояний
  
• редиректы (location)
  
• кэширование
  
• и т.п.
  

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

JS мультипарадигмальный язык. Object.create это, более характерная прототипному программированию, альтернатива оператора new:

const human = {
  planet: 'Earth',
}

const tom = Object.create(human);
tom.name = 'Tom';
tom.age = 32;
tom.country = 'UK';

console.log(tom.planet);

// => Earth

Ключ planet при этом не создается в новом объекте, а берется при вызове tom.planet из прототипа human, пока не будет переназначен в tom.

И если мы изменим прототип human после создания tom, то:

const human = {
  planet: 'Earth',
}

const tom = Object.create(human);
tom.name = 'Tom';
tom.age = 32;
tom.country = 'UK';

human.planet = 'Mars';

console.log(tom.planet);

// => Mars

но если мы переназначим tom.palnet, то:

const human = {
  planet: 'Earth',
}

const tom = Object.create(human);
tom.name = 'Tom';
tom.age = 32;
tom.country = 'UK';

tom.planet = 'Jupiter';
human.planet = 'Mars';

console.log(tom.planet);

// => Jupiter

console.log(human.planet);

// => Mars

$.extend в свою очередь при вызове:

const human = {
  planet: 'Earth',
}

const tom = $.extend({}, human);
tom.name = 'Tom';
tom.age = 32;
tom.country = 'UK';

создаст новый объект tom включающий в себя ключи human без прототипирования.

Надеюсь разница понятна.

Paypal и Netflix используют Node.js. У обоих нагрузки очень даже приличные.
В плане масштабируемости думайте об архитектуре. Можно и на perl написать приложение, которое за секунду будет обслуживать миллион клиентов.
Node.js будет прекрасно работать в качестве движка для типичного веб-приложения вроде магазина, чата или CRM. Если у вас очень много компонентов, например тысячи, логичнее приложение разбить на модули и сделать вместо одного приложения несколько, которые можно запускать по-отдельности (здесь уместно упоминание микросервисной архитектуры). Разумеется запросы нужно распределять с помощью балансировщика.
Есть еще такая вот штука https://serverless.com/ - ее можно масштабировать практически до бесконечности. Были бы деньги.
Node.js будет плохо работать в области процессинга данных, например генерация картинок, потоковая обработка видео, нейронные сети и т.д. Здесь лидеры C, C++, Go, Rust, Java.
Можно даже создать гибридное приложение - большую часть выполнить на Node.js, а критичную по производительности на другом языке. Например генерация миллиона прайсов в сутки в старый xls или векторный pdf, упаковка в архив и рассылка - не самая лучшая идея для Node..JS. То же C++ здесь будет вне конкуренции.

Для монги есть тулзы mongorestore и mongoexport. Robomongo - всего лишь гуй для mongo-консоли

arr = arr.filter(n => n.id !== ID);

Или, если не хотите создавать новый массив:

arr.splice(arr.findIndex(n => n.id === ID), 1);

Это, конечно, если вы уверены, что элемент с таким id действительно есть. В противном случае перед удалением надо проверить, чем является индекс:

const index = arr.findIndex(n => n.id === ID);
if (index !== -1) {
  arr.splice(index, 1);
}

Бекенд - делает серверную логику,
Фронтенд - делает клиентскую логику,
Верстальщик - верстает сервис, по макету, нарисованному дизайнером
Дизайнер - рисует дизайн сервиса

По 1му каждый. Можно убрать верстальщика и оставить только фронтенд разработчика, при условии, что тот умеет верстать(хотя, он должен уметь верстать, но, некоторые уже не любят этим заниматься).

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

Порядок действий.
1) Описали всю логику сервиса, ПОЛНОСТЬЮ, до мельчайших деталей, прям каждую писечку!!!! Всё всё всё. После прочитать раза 3 от начала до конца, 100% появятся правки или дополнения. Все функции по монетизации, тарифы, личные кабинеты, конструктор самого окна, функционал вставки этого окна и всё всё всё. Ибо никто не станет вам на добром слове вносить изменения в созданную прогерами архитектуру проекта, потому что вы, не удосужились вписать новое требование в тз. С вам, что логично, потребуют доп плату уже к той, что была оговорена в начале.

2) Ищите дизайнера. Нашли? Отлично! Тогда:
1.1) По вашему тз делается прототип, того, что и как будет расположено на сайте, где какие элементы. Это как первые наброски, чертёж, если угодно.
1.2) На основе этих набросков рисуется макет, утверждается дизайн сервиса.
1.3) Утвердили все страницы, все элементы, все всё всё. У вас уже есть то, как выглядит ваш сервис.

3) Берём фронтенд разработчика + бекенд разработчика
Тут нужно подойти ответственно. Хорошего разработчика порой трудно найти, часто, хорошие стоят дорого, дешёвые сделают тяп ляп и ваш сервис станет очень сложно менять и дополнять в будущем.

Нашли? Отлично!
Обсуждаете с ними, что и как будет, и что вы вообще хотите. Показываете им 2м тз, макеты. Они между собой, на основе этого тз, распишут план работ, сроки, вёрстку, а так же, как и что будут реализовывать и что им может понадобиться. Как будут работать эти всплывающие окна, куда какие данные будут отправлять и т.п.

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

На основе того, что они решат, вам нужно выбрать хостинг. Все хостинги разные, у всей свой функционал, вместе с ними(так как вы наверняка не шарите) нужно выбрать хороший хостинг, т.к. ваш сервис предпологает размещение своих окон на чужих сайтах, а значит, в теории, что разместив таких окон около тысячи, на ваш сервер пойдёт некая нагрузка. Этот вопрос нужно учесть, что бы он в ненужный момент не упал от нагрузки. Скажу сразу, может стоить дорого, но это ваши заботы)))

4) Тестирование
Все всё сделали, ура. Дальше, начинаем тестировать сервис на его функционал. Ошибки и баги будут 100%. Все мы люди, все можем ошибиться, нужно эти ошибки исключить.

5) Выкатка приложения:
Т.к. сайт делался на дев(там, где разрабатывают) версии, осталось выложить сайт на основной домен(Который вы должны ещё приобрести). Выложили, всё настроили, ура. Приложение готово. Далее, реклама, маркетинг, сео и прочая чушь.

P.S. Так как всё это пахнет фрилансом, то будьте готовы, что вас могут кинуть, игнорить, пропадать не известно куда. Не забудьте составить договора с прогерами, где будут описаны все нюансы. А так же, что бы под конец все права принадлежали вам и только, получение всех доступов, данных и т.п. Иначе потом, можете всё похерить и никто вам уже не поможет.

Примерно так))

v-model

При необходимости обновить значение путём записи свойства value у поля ввода, после собственно установки значения, надо будет отправить ему событие input, которое слушает v-model:

input.value = какое-то значение;
input.dispatchEvent(new Event('input'));

У вас вроде все ок с иерархией компонентов, просто используйте vuex для централизованного хранения данных и тяните их где угодно. При изменении их в vuex store эффект будет везде и на странице и в компонентах.

А что Вы хотите? Вы вызываете new Clock с одним аргументом, а в теле используете два. Поэтому options принимает значение переданного объекта с полями template и name, а sub -- undefined.

Скажите, чему, по Вашему желанию, должны равняться options и sub в этом примере.

Попробуйте написать обычную функцию, а не стрелочную.
И вдобавок почитайте, в каких случаях следует применять стрелочные функции.

Не слушайте тех, кто говорит про говнокод, ребята либо нигилисты, либо мамкины революционеры и "не такие как фсе". Как удобно, так и пишите. Просто прочитайте главу про прототипы, поймите это и то, что JS основан на прототипах и вперед. Все нормальные компании используют новые приемы и не стоят на месте.

class Rectangle {
  constructor(height, width) {
    this.height = height;
    this.width = width;
  }
  
  get area() {
    return this.calcArea();
  }

  calcArea() {
    return this.height * this.width;
  }
}

Классы ES6

methods: {
  logout() {
    localStorage.removeItem('token');
    this.$store.commit('changeUserData', {});
    this.$store.commit('changeAuth', false);
  }
}

Если не заметили, что изменилось, то мы убрали стрелочную функцию и заменили ее на метод (короткий синтаксис es6). И собственно, после этой замены контекст this не будет теряться.
Было:
logout: () => {
Стало:
logout() {

Из документации:

Стрелочные функции не создают собственный контекст this, а используют значение this окружающего контекста.