Банально потому, что примерно с таким успехом твое приложение, если выйдет из mvp, как правило, будет неизбежно обрастать функционалом и выделение всех абстракций в определенные сущности, которые можно будет порезать на сервисы - задачка на старте та еще, это как резать пирог на всех гостей, когда ты не знаешь сколько их будет то, и ты либо режешь больше чем надо, либо меньше, в надежде, что кто-то не придет, и все это очень напоминает одну плохую штуку под названием преждевременная оптимизация, а это, как мы все знаем, то еще зло)

Можно шарить память и оборачивать ее в объекты с геттерамт и сеттерами, что работает таа же

@murzilka17 cheat sheet:
The plural of "index" is "indices"
The plural of "vertex" is "vertices"
The plural of "mutex" is "deadlocks"

Ну так в npm нет пакетов, вот все сидят и ждут, когда выйдет "готовое решение"))

использовать зависимости вообще дурной тон

а если я сразу знаю примерную функциональность приложения?
кто вообще придумал выходить из mvp не зная ситуации и не имея планов?
я не понимаю, это только мне так везло все эти годы, что я работал в компаниях со вполне внятными целями, где были продуктологи, анализ рынка, пилоты, сбор обратной связи, планы на развитие?
другим везёт не так, и их компании как слепые котята тычутся своим монолитом в разные отверстия, подгоняя размер под оные?
как по мне, ерунда какая-то

кроме того, с микросервисной архитектурой наращивать функциональность банально проще
надо либо добавлять что-то новое в небольшие проекты, что заведомо проще добавления нового в большие проекты, либо писать новый микросервис, что опять-таки проще, чем допиливать монолит

кстати кроме всем известного правила "не оптимизируйте преждевременно" есть ещё одно, которое почему-то вспоминают реже: "не пессимизируйте преждевременно"
я не призываю везде использовать микросервисную архитектуру
но вот везде использовать монолит точно не стоит

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

Выглядит круто

Раз уж зашла шарманка об архитектурах
Что можно о них почитать?

Раз уж про другие языки зашла шарманка
На какой второй язык посмотреть для расширения кругозора?

Речь шла об областях применения Node.js не как языка JavaScript с парочкой бедных библиотек, а как платформы для быстрой разработки, без необходимости писать кучу своих велосипедов. Ведь именно так Node.js преподносят кастомерам. Вот мой список: REST API для быстрых ответов, чаты и чат-боты, стриминг, онлайн игры, back-end for front-end / mobile, gateway для back-end микросервисов на других языках, GraphQL, Serverless решения, узкоспециализиированные микросервисы. Вроде список вполне достойный. Дальше ваши варианты.

максимально общий вопрос
зависит от цели использования этого языка
если общего типа - раст или плюсы
если бек - го (или жава, или си шарп)
если мобильная разработка - жава, котлин или свифт

ну или тайпскрипт/дарт/elm, если вообще нет планов менять стек

Елм? На беке?

Понял, спасибо за развернутый ответ

про бек у меня отдельная строчка

Ладно

golang классный ЯП, мне нравится
я на нем пописал для себя, разобрался на каком-то уровне
единственный минус - все вакансии на нем на 5+ лет опыта и еще год и больше коммерческого опыта на этом языке

Все же хотелось бы услышать ответ про литературу про архитектуры

Чистая архитекура дяди Боба, Enterprise patterns, DDD - это с ходу что пришло в голову