Чем вызван такой ажиотаж вокруг языков, которые компилируются в машинные коды? Почему люди не пишут просто в машинных кодах? Ведь как не ругай машинные коды, но в итоге код скомпилируется из их базового функционала?
А в комментариях: Angular, энтерпрайз, angular, angular, энтерпрайз, angular, энтерпрайз и конечно же angular!
А так да, функциональщине уже более полувека, а срачи все не утихают. Автор говорит, что возрождение увидел, а может просто открыл что-то новое для себя недавно и стал адептом, в общем дело каждого.
Но лично для себя в статье увидел технологии интересные, такие как WebRTC, WebAssembly, QraphQL. Правда и до статьи за ними следил, и буду следить, и действительно интересно посмотреть, что принесет 2017 нам в этом плане.
Меня немного передернуло от фразы в самом начале статьи: "… этот факт понятен интуитивно, но мы должны просто-таки вбить его в свои головы и двигаться вперед". На первом собрании в университете, еще до начала учебы, заведующий кафедры нам сказал примерно такое: "Мы будем вас учить умению самостоятельно добывать знания и научим думать. Поэтому у вас будет математика, физика, множество различных теорий, история этих теорий, гуманитарные науки и все, все, все. А если вам нужны JavaScript+HTML+CSS+PHP, то в ПТУ скорей всего лучше этому научат.".
Мне показалось, что автор предлагает прижать задницу и зазубрить, грубо говоря, технологию за месяц. Выучить все ключевые слова из языка программирования, выучить все методы в библиотеке, выучить все шаблоны проектирования и так далее. В этом, конечно, ничего плохого нет, теорию надо знать, но добавит ли это какой-то конкурентоспособности большой вопрос (отсылка к статьям про собеседования). Лично для меня, понимание каких-то базовых вещей чаще помогает решать проблемы, чем знание чего-то конкретного в конкретных технологиях, и из базовых вещей я имею ввиду: алгебру, матан, теорию множеств, теорию графов, теорию алгоритмов и многое другое.
Допустим не нужно знать ни одного метода из связки React+Redux, чтобы понимать принципы работы этой связки, и кому-то будет достаточно схемы с потоком данных и списка методов, чтобы начать работать с этими библиотеками. Тоже касается и других технологий, возьмем что-нибудь по сложнее, допустим OpenGL, можно месяц читать обучающие материалы, но так и не осознавать до конца, за счет каких вычислений вращается треугольник в примере: какие-то матрицы, вектора, проекции, формулы, полигоны —, а можно знать аналитическую геометрию и линейную алгебру и достаточно быстро в этом всем разобраться. Или, чтобы далеко не ходить, CUDA, тут уже нужно знать почему и как алгоритмы можно распараллеливать, и еще было бы не плохо представлять как биты пересылаются на железном уровне. Вот пара технологий, которые без большой теоретической базы, как-то не особо получится освоить за месяц, не говоря уже про большое множество других. Знания должны быть в первую очередь в областях, а не в конкретных технологиях. Конечно, и в конкретных технологиях всегда есть множество моментов, которые ты просто не узнаешь без изучения, но посыл в том индуктивное мышление всегда создает больше вопросов, чем ответов.
Еще немного проясню свою точку зрения. Вот конкретно в статье, автор предлагает отфильтровать технологии для изучения, на основе востребованности, известности авторов, публикаций в блогах, и, по моему мнению, это не осознаное решение, а поедание маркетингового говна. Но мои мысли сейчас даже немного про другое. Понятно, что программирование уже очень далеко от науки. Но вот с точки зрения ведения просветительской деятельности, зачем призывать людей еще больше удаляться? Нужно не технологии изучать, а то какие проблемы эти технологии решают и как, чем были вызваны проблемы, что решение таким способом даст, какие еще способы есть, а какие истоки у тех способов и так далее, это касательно конкретных вещей, а в целом нужно призывать всех максимально расширять свой кругозор и думать. А не учить на какой стул сесть, потому что это интуитивно понятно. Мы так дальше споров, о том какой js-фреймворк быстрее, какая методология/парадигма/технология/бд/яп/<подставь_свое> лучше, мы не уйдем. Накипело немного и идеалист во мне проснулся, но все равно чуть большего мнения о Mail.ru был до этого момента.
Я использовал. Решил взять его, когда только-только вышел первый релиз. Первое, почему его выбрал — это документация: она действительна очень качественная, и после прочтения официального гайда у меня не появилось ни одного вопроса, что и как делать. А это уже наверное вторая его особенность — простота, именно, простота использования. Еще сильно меня подкупил момент с использованием DOM на прямую: пример, и это же позволяет легко работать с анимацией элементов, плюсом есть и встроенная поддержка работы с анимациями, это был достаточно важный критерий при принятие решения.
Хотя с другой стороны, я совсем немного знаком с React или Angular, на уровне создания нескольких примеров, но даже в этих примерах появлялось множество вопросов. А здесь я взял привычный стек: jade (pug) и coffee, и все стало получаться само собой, без исследования подводных камней. Можно в этом плане еще посмотреть на количество звезд допустим на Гитхабе у библиотек Angular/React/Vue, чтобы оценить популярность, и количество статей на Хабре или вопросов на SO, чтобы оценить проблемность библиотеки. Метрика, конечно, далеко не объективная, но мои впечатления сходятся с таким экспериментом.
В Вашем примере системы отсчета действительно становятся не равноправны при ускорении и замедлении корабля. А первый постулат распространяется только на инерциальные системы отсчета, то есть на такие системы, в которых на тела не действуют силы. Если еще популярнее подходить к этому примеру, то во время ускорения/замедления и происходит рассинхронизация времени. Во время движения корабля со скоростью близкой к скорости света обе системы равноправны, то есть время на корабле будет идти точно также, как и в системе на планете.
А вот что происходит в моменты ускорения/замедления, если в кратце, то там будет происходить ускорение/замедление времени в одной СО относительно времени в другой, причем с зависимостью от расстояния между СО. То есть: когда корабль будет набирать скорость по направлению к планете, находясь далеко от нее — на планете время будет тикать очень быстро, относительно времени на корабле. Когда наберет скорость и успокоится — время будет тикать одинаково. А когда будет тормозить — на корабле время будет тикать медленнее, но в силу того, что расстояние между системами будет небольшим, то и эффект замедления времени при торможении будет не особо заметен.
Есть подобный мысленный эксперимент — парадокс близнецов.
Скрытый текст
Несколько не серьезный совет, но рекомендую на lurkmore.org про СТО [почитать](https://lurkmore.to/СТО).
Нет, как мне кажется, никто не рассчитывает минусами в Ваш адрес улучшить технологии. А вот уменьшить таким способом количество ненавистников, с голословными заявлениями, наверное, можно.
Ну реально — это же самое дно из всего что есть вообще
Достаточно аргументировано. Могу предположить, что найдется часть людей, которые будут скидывать статью в аргументы, так как тоже поверят, но не проверят.
Скрытый текст
95% НОДЫ ДЕЛАЮТ КОНЧЕННЫЕ МАЛОЛЕТКИ-ИДИОТЫ 95% ПОТРЕБИТЕЛЕЙ НОДЫ ЖРУТ ГАВНО НОДА САМОЕ ДНО — НУ РЕАЛЬНО РЕАААЛЬНOOО000!!!!111
Вот сейчас сложно было. Если WebAssembly разрабатывается как язык, который выполняется в браузере, о какой нативности идет речь? И что в данном контексте нормальность?
В плане функциональности, собственно про что и говорил, сейчас они делают Apollo, который будет использоваться в метеоре. Да и в целом они движутся по поставленным задачам, которые предполагают большие изменения и параллельно улучшают качество продукта: изменяются в лучшую сторону стабильность, производительность, документация, появляются какие-то дочерние проекты и т. д. И все это с какой-то проработкой делается, с учетом предыдущих ошибок.
По крайней у меня есть некоторая уверенность в этом проекте и текущий путь развития мне нравится. А я именно на нем пишу уже в течение пары лет, наверное, различные внутренние решения для компании, с возможностью совместной работы. Начинал еще с версии 0.8.3 вроде и собственно отслеживал путь развития проекта, с тех времен. Возможно я ошибаюсь, конечно, но достойных аналогов в этой нише пока не вижу.
Возможно я не совсем ясно выразился про DOM, поэтому пример конкретный привел, где мало что будет зависеть от производительности непосредственно js, по моему мнению.
И вы сами же написали:
Те же Polymer и React ускоряют работу страницы именно аккуратным обращением к DOM
Я собственно про обращения к API движка и говорил, и про то, что производительность зачастую упирается именно в это, по крайней мере в этих библиотеках.
Мне кажется, тут смотря что с чем сравнивать. В данном посте нет сравнения, конечно, но в одну кучу запихано как сладкое так и зеленое, и создается впечатление, что все эти фреймворки/библиотеки про одно и тоже. Если конкретно про Meteor, то все вышеперечисленное можно использовать вместе с ним. И, мне кажется, искать корреляцию между популярностью Meteor и, например, React, будет не верно. Есть даже и подобные решения, а можно и что-то свое сделать, но в любом случае Meteor занял свою нишу, и чувствует себя там комфортно.
Слежу за Meteor постоянно и мне нравится как развивается проект в последнее время, становится более взрослым что ли. Также интересно будет посмотреть на Apollo. И какого-то прекращения разработки Meteor, отказа от поддержки или вообще умирания тоже не вижу в ближайшем будущем.
Но проблема останется в медленной работе с DOM и прочими интерфейсами, предоставляемыми браузером, которые никуда не денутся с приходом WebAssembly, или я чего-то не понимаю? Если, например, нужно отобразить 10 000 строк таблицы, данные для которых были получены по сети, а потом их изменять, перерисовывать и все такое, как тут поможет WebAssembly? В данный момент я вижу области применения этой технологии, там где нужны вычисления, например: обработка изображений, видео, звука, игровая физика и т. д. На счет не быстрого js, у меня тоже есть сомнения как ни странно.
1.5) ln -s ../node_modules node_modules (не говоря про то, что npm может пару вариантов для решения еще предложить, типа линковки пакетов, выбора источника и так далее)
2) npm install
Но если у вас требование все делать на чистую и при этом быстро, то тут не проблема того что пакеты много весят, а что-то еще. Потому что для чистоты можно и ноду каждый раз ставить, со всеми зависимостями, а лучше всю систему в целом.
Мне кажется любой язык не может предложить чего-то исключительного, везде есть плюсы/минусы и подходящие/неподходящие области применения.
Например, есть задача с кучей операций ввода-вывода, допустим сложная бизнес-логика завязанная на десятках таблиц, и каждую таблицу нужно чуть ли не по хаотичным правилам читать/писать в зависимости от запросов. Стандартная история вроде. И я бы не стал в данном случае выбирать ноду, если нет каких-то еще более специфичных требований, например, по производительности. Но подобную логику чаще всего больно писать в асинхронном стиле и очень больно поддерживать.
Или например есть ситуация, где нужна очень простая логика ввода-вывода, типа считал-обработал-записал, и все это для одной записи в монговской коллекции и каждый запрос так, но видов запросов большое множество, и одновременно ломятся тысячи, десятки, сотни тысяч запросов, и в данном случае я бы тоже хорошо подумал прежде чем не взять ноду.
Я скорее это имел ввиду: автор выбирал инструмент, не потому что он подходил для решения задачи, а потому что так захотелось. Иначе он бы был готов ко всем проблемам.
Вебпак позволяет за милисекунды билдить проект и на горячую подменять стили, а при опрелеленных условиях и код, и шаблоны, и все что угодно. То есть можно добиться того, что после нажатия на ctrl+s все применится до того как вы успеете взгляд на монитор с браузером перевести. А Ваши претензии сводятся к медленной обратной связи?
А поповоду выкачивания, чтобы не юзать версии из кеша, во избежание сайд-эффектов, это по-моему на уровне паранойи. Нет, стандарты по сборке и тестированию могут быть разными, но тогда чем обусловленно недоверие именно к системе кеширования в npm, при условии использования 120мб стороннего кода?
Зафиксировать версии, один раз проверить сборку после очередного коммита, при смене версий еще раз проверить, все ли подтянулось, обновилось, либо даже автоматический тест написать. Тоже не ваш путь?
Но в этом же и прелесть. Если для человека не достаточно авторитетны стандарты от гугла, или проект входящий в топ 15 по количеству звезд на гитхабе, и он не может сделать свой выбор, или сделать свои гайдлайны с блекджеком и прочими вещами (благо инструментов валом), а предпочитает только от производителя, то это уже идеологические проблемы.
Человек после прочтения тутора по экспресс считает себя уже находящимся "в теме". И инструмент судя по всему он выбирал не для решения какой-то проблемы, а потому что стильно, модно, молодежно. Для таких целей было бы верно написать какой-нибудь микросервис, как мне кажется, и поиграться хватило бы, и оценить возможность применения в дальнейшем.
По моему мнению, в первую очередь ноду нужно выбирать из-за асинхронности, и того, что это дает, а потом уже остальное. Но люди почему-то выбирают из-за моды, пилят достаточно большие проекты, типа другие же делают, а потом ноют.
Можно писать на чем хочешь, но все равно вселенная будет оперировать квантами. Существует ли выбор в принципе?
У JavaScript монополия, так сказать, в вебе.
Тоже подумал, что "взломщик" как-то так действовал:
А в комментариях:
Angular, энтерпрайз, angular, angular, энтерпрайз, angular, энтерпрайз и конечно же angular!
А так да, функциональщине уже более полувека, а срачи все не утихают. Автор говорит, что возрождение увидел, а может просто открыл что-то новое для себя недавно и стал адептом, в общем дело каждого.
Но лично для себя в статье увидел технологии интересные, такие как WebRTC, WebAssembly, QraphQL. Правда и до статьи за ними следил, и буду следить, и действительно интересно посмотреть, что принесет 2017 нам в этом плане.
Меня немного передернуло от фразы в самом начале статьи: "… этот факт понятен интуитивно, но мы должны просто-таки вбить его в свои головы и двигаться вперед". На первом собрании в университете, еще до начала учебы, заведующий кафедры нам сказал примерно такое: "Мы будем вас учить умению самостоятельно добывать знания и научим думать. Поэтому у вас будет математика, физика, множество различных теорий, история этих теорий, гуманитарные науки и все, все, все. А если вам нужны JavaScript+HTML+CSS+PHP, то в ПТУ скорей всего лучше этому научат.".
Мне показалось, что автор предлагает прижать задницу и зазубрить, грубо говоря, технологию за месяц. Выучить все ключевые слова из языка программирования, выучить все методы в библиотеке, выучить все шаблоны проектирования и так далее. В этом, конечно, ничего плохого нет, теорию надо знать, но добавит ли это какой-то конкурентоспособности большой вопрос (отсылка к статьям про собеседования). Лично для меня, понимание каких-то базовых вещей чаще помогает решать проблемы, чем знание чего-то конкретного в конкретных технологиях, и из базовых вещей я имею ввиду: алгебру, матан, теорию множеств, теорию графов, теорию алгоритмов и многое другое.
Допустим не нужно знать ни одного метода из связки React+Redux, чтобы понимать принципы работы этой связки, и кому-то будет достаточно схемы с потоком данных и списка методов, чтобы начать работать с этими библиотеками. Тоже касается и других технологий, возьмем что-нибудь по сложнее, допустим OpenGL, можно месяц читать обучающие материалы, но так и не осознавать до конца, за счет каких вычислений вращается треугольник в примере: какие-то матрицы, вектора, проекции, формулы, полигоны —, а можно знать аналитическую геометрию и линейную алгебру и достаточно быстро в этом всем разобраться. Или, чтобы далеко не ходить, CUDA, тут уже нужно знать почему и как алгоритмы можно распараллеливать, и еще было бы не плохо представлять как биты пересылаются на железном уровне. Вот пара технологий, которые без большой теоретической базы, как-то не особо получится освоить за месяц, не говоря уже про большое множество других. Знания должны быть в первую очередь в областях, а не в конкретных технологиях. Конечно, и в конкретных технологиях всегда есть множество моментов, которые ты просто не узнаешь без изучения, но посыл в том индуктивное мышление всегда создает больше вопросов, чем ответов.
Еще немного проясню свою точку зрения. Вот конкретно в статье, автор предлагает отфильтровать технологии для изучения, на основе востребованности, известности авторов, публикаций в блогах, и, по моему мнению, это не осознаное решение, а поедание маркетингового говна. Но мои мысли сейчас даже немного про другое. Понятно, что программирование уже очень далеко от науки. Но вот с точки зрения ведения просветительской деятельности, зачем призывать людей еще больше удаляться? Нужно не технологии изучать, а то какие проблемы эти технологии решают и как, чем были вызваны проблемы, что решение таким способом даст, какие еще способы есть, а какие истоки у тех способов и так далее, это касательно конкретных вещей, а в целом нужно призывать всех максимально расширять свой кругозор и думать. А не учить на какой стул сесть, потому что это интуитивно понятно. Мы так дальше споров, о том какой js-фреймворк быстрее, какая методология/парадигма/технология/бд/яп/<подставь_свое> лучше, мы не уйдем. Накипело немного и идеалист во мне проснулся, но все равно чуть большего мнения о Mail.ru был до этого момента.
Я использовал. Решил взять его, когда только-только вышел первый релиз. Первое, почему его выбрал — это документация: она действительна очень качественная, и после прочтения официального гайда у меня не появилось ни одного вопроса, что и как делать. А это уже наверное вторая его особенность — простота, именно, простота использования. Еще сильно меня подкупил момент с использованием DOM на прямую: пример, и это же позволяет легко работать с анимацией элементов, плюсом есть и встроенная поддержка работы с анимациями, это был достаточно важный критерий при принятие решения.
Хотя с другой стороны, я совсем немного знаком с React или Angular, на уровне создания нескольких примеров, но даже в этих примерах появлялось множество вопросов. А здесь я взял привычный стек: jade (pug) и coffee, и все стало получаться само собой, без исследования подводных камней. Можно в этом плане еще посмотреть на количество звезд допустим на Гитхабе у библиотек Angular/React/Vue, чтобы оценить популярность, и количество статей на Хабре или вопросов на SO, чтобы оценить проблемность библиотеки. Метрика, конечно, далеко не объективная, но мои впечатления сходятся с таким экспериментом.
В Вашем примере системы отсчета действительно становятся не равноправны при ускорении и замедлении корабля. А первый постулат распространяется только на инерциальные системы отсчета, то есть на такие системы, в которых на тела не действуют силы. Если еще популярнее подходить к этому примеру, то во время ускорения/замедления и происходит рассинхронизация времени. Во время движения корабля со скоростью близкой к скорости света обе системы равноправны, то есть время на корабле будет идти точно также, как и в системе на планете.
А вот что происходит в моменты ускорения/замедления, если в кратце, то там будет происходить ускорение/замедление времени в одной СО относительно времени в другой, причем с зависимостью от расстояния между СО. То есть: когда корабль будет набирать скорость по направлению к планете, находясь далеко от нее — на планете время будет тикать очень быстро, относительно времени на корабле. Когда наберет скорость и успокоится — время будет тикать одинаково. А когда будет тормозить — на корабле время будет тикать медленнее, но в силу того, что расстояние между системами будет небольшим, то и эффект замедления времени при торможении будет не особо заметен.
Есть подобный мысленный эксперимент — парадокс близнецов.
Нет, как мне кажется, никто не рассчитывает минусами в Ваш адрес улучшить технологии. А вот уменьшить таким способом количество ненавистников, с голословными заявлениями, наверное, можно.
Достаточно аргументировано. Могу предположить, что найдется часть людей, которые будут скидывать статью в аргументы, так как тоже поверят, но не проверят.
95% НОДЫ ДЕЛАЮТ КОНЧЕННЫЕ МАЛОЛЕТКИ-ИДИОТЫ
95% ПОТРЕБИТЕЛЕЙ НОДЫ ЖРУТ ГАВНО
НОДА САМОЕ ДНО — НУ РЕАЛЬНО
РЕАААЛЬНOOО000!!!!111
Вот сейчас сложно было. Если WebAssembly разрабатывается как язык, который выполняется в браузере, о какой нативности идет речь? И что в данном контексте нормальность?
В плане функциональности, собственно про что и говорил, сейчас они делают Apollo, который будет использоваться в метеоре. Да и в целом они движутся по поставленным задачам, которые предполагают большие изменения и параллельно улучшают качество продукта: изменяются в лучшую сторону стабильность, производительность, документация, появляются какие-то дочерние проекты и т. д. И все это с какой-то проработкой делается, с учетом предыдущих ошибок.
По крайней у меня есть некоторая уверенность в этом проекте и текущий путь развития мне нравится. А я именно на нем пишу уже в течение пары лет, наверное, различные внутренние решения для компании, с возможностью совместной работы. Начинал еще с версии 0.8.3 вроде и собственно отслеживал путь развития проекта, с тех времен. Возможно я ошибаюсь, конечно, но достойных аналогов в этой нише пока не вижу.
Возможно я не совсем ясно выразился про DOM, поэтому пример конкретный привел, где мало что будет зависеть от производительности непосредственно js, по моему мнению.
И вы сами же написали:
Я собственно про обращения к API движка и говорил, и про то, что производительность зачастую упирается именно в это, по крайней мере в этих библиотеках.
Мне кажется, тут смотря что с чем сравнивать. В данном посте нет сравнения, конечно, но в одну кучу запихано как сладкое так и зеленое, и создается впечатление, что все эти фреймворки/библиотеки про одно и тоже. Если конкретно про Meteor, то все вышеперечисленное можно использовать вместе с ним. И, мне кажется, искать корреляцию между популярностью Meteor и, например, React, будет не верно. Есть даже и подобные решения, а можно и что-то свое сделать, но в любом случае Meteor занял свою нишу, и чувствует себя там комфортно.
Слежу за Meteor постоянно и мне нравится как развивается проект в последнее время, становится более взрослым что ли. Также интересно будет посмотреть на Apollo. И какого-то прекращения разработки Meteor, отказа от поддержки или вообще умирания тоже не вижу в ближайшем будущем.
Но проблема останется в медленной работе с DOM и прочими интерфейсами, предоставляемыми браузером, которые никуда не денутся с приходом WebAssembly, или я чего-то не понимаю? Если, например, нужно отобразить 10 000 строк таблицы, данные для которых были получены по сети, а потом их изменять, перерисовывать и все такое, как тут поможет WebAssembly? В данный момент я вижу области применения этой технологии, там где нужны вычисления, например: обработка изображений, видео, звука, игровая физика и т. д. На счет не быстрого js, у меня тоже есть сомнения как ни странно.
1.5) ln -s ../node_modules node_modules (не говоря про то, что npm может пару вариантов для решения еще предложить, типа линковки пакетов, выбора источника и так далее)
2) npm install
Но если у вас требование все делать на чистую и при этом быстро, то тут не проблема того что пакеты много весят, а что-то еще. Потому что для чистоты можно и ноду каждый раз ставить, со всеми зависимостями, а лучше всю систему в целом.
Мне кажется любой язык не может предложить чего-то исключительного, везде есть плюсы/минусы и подходящие/неподходящие области применения.
Например, есть задача с кучей операций ввода-вывода, допустим сложная бизнес-логика завязанная на десятках таблиц, и каждую таблицу нужно чуть ли не по хаотичным правилам читать/писать в зависимости от запросов. Стандартная история вроде. И я бы не стал в данном случае выбирать ноду, если нет каких-то еще более специфичных требований, например, по производительности. Но подобную логику чаще всего больно писать в асинхронном стиле и очень больно поддерживать.
Или например есть ситуация, где нужна очень простая логика ввода-вывода, типа считал-обработал-записал, и все это для одной записи в монговской коллекции и каждый запрос так, но видов запросов большое множество, и одновременно ломятся тысячи, десятки, сотни тысяч запросов, и в данном случае я бы тоже хорошо подумал прежде чем не взять ноду.
Я скорее это имел ввиду: автор выбирал инструмент, не потому что он подходил для решения задачи, а потому что так захотелось. Иначе он бы был готов ко всем проблемам.
Вебпак позволяет за милисекунды билдить проект и на горячую подменять стили, а при опрелеленных условиях и код, и шаблоны, и все что угодно. То есть можно добиться того, что после нажатия на ctrl+s все применится до того как вы успеете взгляд на монитор с браузером перевести. А Ваши претензии сводятся к медленной обратной связи?
А поповоду выкачивания, чтобы не юзать версии из кеша, во избежание сайд-эффектов, это по-моему на уровне паранойи. Нет, стандарты по сборке и тестированию могут быть разными, но тогда чем обусловленно недоверие именно к системе кеширования в npm, при условии использования 120мб стороннего кода?
Зафиксировать версии, один раз проверить сборку после очередного коммита, при смене версий еще раз проверить, все ли подтянулось, обновилось, либо даже автоматический тест написать. Тоже не ваш путь?
Но в этом же и прелесть. Если для человека не достаточно авторитетны стандарты от гугла, или проект входящий в топ 15 по количеству звезд на гитхабе, и он не может сделать свой выбор, или сделать свои гайдлайны с блекджеком и прочими вещами (благо инструментов валом), а предпочитает только от производителя, то это уже идеологические проблемы.
Человек после прочтения тутора по экспресс считает себя уже находящимся "в теме". И инструмент судя по всему он выбирал не для решения какой-то проблемы, а потому что стильно, модно, молодежно. Для таких целей было бы верно написать какой-нибудь микросервис, как мне кажется, и поиграться хватило бы, и оценить возможность применения в дальнейшем.
По моему мнению, в первую очередь ноду нужно выбирать из-за асинхронности, и того, что это дает, а потом уже остальное. Но люди почему-то выбирают из-за моды, пилят достаточно большие проекты, типа другие же делают, а потом ноют.