Vitaly Sivkov

Это задача терминации SSL, ее действительно можно отделять от бизнес-логики сервера, и терминировать при помощи nginx, специализированных аппаратных или программных решений или датацентры часто имеют такой отдельный сервис, как терминация SSL. Можно делать это и нодой, в некоторых случаях это предпочтительно, когда соединения держатся долго (вебсокеты или SSE), чтобы не держать много открытых TCP сокетов 2 раза, т.е. nginx держит и пробрасывает в ноду и выходит, что сокетов на сервере в 2 раза больше открыто, а значит памяти больше и скорость отклика у системы в целом хуже. Но вот так разделять это на два разных процесса - в этом не вижу ни малейшего смысла.

<label>
  %любой контент, будь то текст или всякие иконки%
  <input type="file"/>
</label>

Вас ведь это интересует?

После установки зависимостей в проект делаете

$ npm dedupe
$ npm shrinkwrap

dedupe приводит дерево npm-зависимостей к максимально плоскому виду

Шансов никаких, если целыми днями глупые вопросы на тостере задавать.

При отсутствии таланта к рисованию человек не видит гармонию в композиции и расцветке, но может ее зазубрить.
Лично я считаю, что для верстальщика иметь понимание в базовых вещах дизайна обязательно.

"Увидел клёвый курс" - лучше книги ничего быть не может. Рекомендую к прочтению: "Веб-дизайн: книга Стива Круга или "не заставляйте меня думать"

все эти "ненужные" свойства добавляются через прототип, следовательно нужно проверять:

for(var i in object) {
    if (!object.hasOwnProperty(i)) continue;

    // do stuff
}

в целом же для ваших задач лучше использовать старый добрый .map

var newCollection = collection.map(function (item) {
    return JSON.stringify(item);
});

Сколько угодно, тот же Pixi отлично рендерит 2D.

Помимо этого можно взять Unity и даже Unreal Engine, оба умеют собирать WebGL рендерер и транслировать код в JS, и конечно там можно слепить 2D картинку.

А в MMO (и вообще многопользовательских играх) проблематика вовсе не в рендеринге же. Графика это самый простой аспект такого проекта.

Идея/концепция к проектированию не относится, это отдельный предварительный этап. Для проектов побольше, и в общем случае, проектирование включает такие шаги, многие из которых, конечно, можно пропустить или сократить до минимума, если задача не сложная:
1. Системный анализ и изучение предметной области
2. Формирование требований к разрабатываемой системе
3. Архитектуная задача, которая сводится к простой формуле: разделять, называть и связывать подсистемы
3.1. Декомпозиция сложных задач
3.2. Слои (построение слоев абстракций)
3.3. Планирование топологии системы, программной и серверной инфраструктур
3.4. Решение вопроса интеграции подсистем, программные интерфейсы, контракты и связывание
3.5. Интеграция с унаследованными приложениями
3.6. Минимизация изменений, для случаев, когда постоянно происходят изменения в предметной области
4. Выбор инструментов решения
4.1. Выбор парадигм программирования и языков
4.2. Выбор технологий и платформ
4.3. Выбор моделей данных, алгоритмов и библиотек
4.4. Выбор топологий и протоколов
4.5. Выбор паттернов программирования
5. Предварительные исследования
5.1. Проверка гипотез, эксперименты
5.2. Изучение особенностей технологий
5.3. Прототипирование
6. Задачи обеспечения надежности
6.1. Планирование безопасности и защиты от несанкционированного доступа
6.2. Планирование отказоустойчивости
6.3. Планирование мер по обслуживанию системы в режиме эксплуатации
6.4. Задачи высоких нагрузок, балансировки и масштабирования, если таковые предполагаются
7. Организация процесса разработки
7.1. Жизненный цикл программной системы
7.2. Конвенции кода, соглашения и стандарты
7.3. Оценка необходимых временных и финансовых ресурсов для разработки системы
7.4. Календарный план
7.5. Анализ и минимизация рисков, выявление слабых мест технологий и коллектива
7.6. Закрепление принципов управления процессом разработки и корректировки задания в процессе
8. Сборка технического задания из результатов всех предыдущих пунктов