А в чем минусы node.js?

Question

[WebDev]

Вот все говорят, что быстрый, хороший, асинхронный, а в чем его минусы? Почему реально серьезный проектов на нем очень мало?

Comments

[Антон Пискунов]

Итак,

он быстрый, хороший и асинхронный и ваще вы будете с него течь ЕСЛИ вы применяете node.js правильно. Суть инструмента в том что если у вас есть адовые задачи по риалтайм взаимодействию, то используйте node.js.

Я поясню: у вас есть онлайн игра и вы хотите знать чем живут ваши игроки. На каждый пук вы навешиваете события и, внимание спойлер, с траффиком в 300к игроков в день вам надо обрабатывать 300к * N событий действий игроков.

Вот здесь node.js тащит, прёт и разруливает т.к. это её полное предназначение - быстрый сбор и ответ на огромное количество запросов с выполнением минимальной логики под капотом.

Если же вы будете использовать node.js для написания бложека, то это полный ад и трэш, т.к. асинхронность вас убьет. Ну или не вас, а ваш мозг. А потом сверху придавит огромным количеством подкапотной логики, повторюсь что node.js,, а в частности JS, под это дело не заточены.

По поводу потоков: V8 (JS двигло на котором работает node.js) умеет в мульти-трединг, то бишь поддерживает многопоточность, но это всё таки сложные моменты и если вам нужно что-то распараллелить, то берите GOLang с его совершенно прекрасными goroutines.

По поводу почему нет серьезных проектов: их тьма, просто они не публичны. Как я уже показал выше, то node.js очень хорошо заходит для решения серьезных инженерных проблем под капотом публичных сервисов. То бишь сам сервис может быть написан на PHP, Python, C++, иврите, но для решения каких-то специфических проблем они используют node.js.

Такие дела. Спрашивайте, если что.

[webus]

Проекты есть. Последнее время очень много вижу проектов в связке AngularJS / NodeJS на oDesk

Answer 1

[Сергей Протько]

В том же в чем его и плюсы.

Асинхронность... ее там нет. Там есть event loop что позволяет писать крайне эффективные программы в плане работы с I/O (что для web очень неплохо) и не париться о таких вещях как потокобезопасность, блокировки и т.д. А если еще и несколько инстансов приложения запусть - по одному на ядро скажем, то утилизация вычислительных мощностей выйдет неплохой. Но распаралелить что-то в рамках одного процесса воркера мы уже не можем. Мы не можем посчитать что-то, проанализировать, заняться обработкой жирной картинки прямо при обработке запроса потому что наш процесс воркер так же обрабатываете еще пару десятков запросов, и пока мы будем удовлетворять нужды одного простаивать будут все. Нода хороша когда у нас все состоит из элементарных операций которые не занимают много времени, все жирное надо выносить из основного процесса и разруливать очередями и т.д. Эта проблема имеет массу решений на самом деле, но все уже усложняется и нода теряет свою красоту. Лучше взять Java/c#/Python для этого (и не надо тут вспоминать про шутки с многопоточностью в CPython).

callback-hell. Собственно наличие event loop диктует так же правила о том, как должна писаться программа. Кучи колбэков, невозможность дебажить нормально и получить четкий стэктрейс из ошибки. Да, есть промисы которые решают первую проблему, да есть либы вроде zone.js которые решают вторую и частично первую проблему... но все это не тривиальное дело.

Собственно... разработка больших и сложных проектов на ноде возможна... но требует от разработчика хорошие знания и понимание того, как работает его платформа. А это увеличивает стоимость разработки в то время как можно взять более эффективные в этом плане инструменты.

Comments

[lega]

> Асинхронность... ее там нет. Там есть event loop
Дак асинхронность обычно и делается на event loop, не придираясь к "терминам" node.js вполне можно назвать асинхронным, почему нет?

[Сергей Протько]

lega: Ну если не придираться к терминологии и реализации, если брать в расчет по большей части стиль написания кода и то, как это все работает, то в общем и целом да.

Но проблем от этого не меньше. С нодой все хорошо ровно тогда, когда блоки задач в очереди маленькие. А если там периодически возникают жирные штуки с циклами и т.д. то начинаются проблемы. И их приходится решать... и решать их на ноде не сильно удобно.

Я к этому вел.

[lega]

> Но проблем от этого не меньше.
С этим я согласен, сам "переболел" асинхронщину, после нескольких лет разработки крупных асинхронных проектов.

> если брать в расчет по большей части стиль написания кода и то, как это все работает
Я считаю это определяющим, т.к. термины каждый "Вася" по своему трактует, т.е. вроде как нет какого-то 100% источника с которым сверяются все остальные (это как споры на счет ООП и у каждого своя версия).

[Юрий Пузыня]

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

[Сергей Протько]

Юрий Пузыня: Новость замечательная, но а как на фронтэнде, если не секрет? Насколько я знаю там тоже все не так радужно. Мне понравилось как при помощи zone.js это можно хэндлить, но все же?

[Юрий Пузыня]

На фронтенде это вот так www.html5rocks.com/en/tutorials/developertools/asy...

[Сергей Протько]

Юрий Пузыня: а, вы об этом. Ну чтож, ждем.

[Тарас Лабяк]

Не вижу необходимости делать тяжелые вычисления на Node.js вообще. Для этой задачи хорошо подойдет Python, который будет брать свободные процессорное время задачи из очереди, а юзеру в интерфейсе будет показываться состояния задачи нодом, если нужно

[Сергей Протько]

Тарас Лабяк: нода быстрее питона, у него тут вообще преимуществ нет (кроме того что питон нежный язык). И если мы пишем что-то на ноде, записываем это что-то в очереди, то как бы... все остальное тоже можно на ноде сделать.

В целом же есть кучи вариантов. Например реализовать тяжелые операции на rust.

[Тарас Лабяк]

Сергей Протько: или Go?) Если можете сравнить

Answer 2

[Тарас Лабяк]

JavaScript недоразвит. С приходом ECMAScript 6 все может измениться

Comments

[sasha]

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

[sasha]

минусы*

[Тарас Лабяк]

sasha: взять хотя бы недо-ООП в виде прототипов. Говорят это собственная реализация ООП, но поробуйте сделать наследования.

[sasha]

Тарас Лабяк: я бы сказал что это не недостаток, это вариация. Комуто нравится желтый, комуто зеленый. Наследование происходит вполне себе просто, для понимания с ходу немного сложнее. https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D... все же комуто понадобилось делать прототипы на классах, вот это действительно изврат. Но в одном согласен, в браузерах нету альтернативы, как минимум нужно вникать в ооп через прототипы, нету возможности на все тех же классах. Я бы сказал что в ес6 добавят просто немного сахара, не более. Кому не нравятся прототипы тот учит кофе или ждет ес6

[Тарас Лабяк]

sasha: полагаю вы уже пробовали создать объект, this у всех методы которого указывают на него? Может знаете литературу по прототипно-ориентированому программированию и соответствующих паттернах?

[sasha]

Тарас Лабяк: Дэвид Флэнаган "JavaScript. Подробное руководство" (6-е издание). по js пока ничего лучшего нету

[Тарас Лабяк]

sasha: 20 лет языку, а по его парадигмах еще нет основательной литературы. Может потому что JavaScript - это "поделка на коленке", как PHP? На создание этих языков было потрачено слишком мало времени. Хотя, в отличии от похапе, JavaScript не вызывает у меня отвращения, больше того, он мне нравиться. И я верю, что отсуствие теоретических работ по прототипному программированию есть следсвие есть следствие того, что к JavaScript слишком уж долго относились не всерьез. Хотя, с другой стороны, почему к нему так относились?
Да и к динамическим языкам языкам пока все еще относяться с пренебреженим.
Да и в JavaScript убоги средства метапрограммирование. Proxy должно поддержываться в ECMAScript 6.
Если вы так скептически отниситесь к "синтаксическому сахару" так представте, как сохратит количество букоф в бесчисленых асинхронных вызовах стрелочный синтаксис.
Полагаю генераторы вы не используете?

Answer 3

[globuzer]

Node.js быстр, но существуют вещи, которые необходимо знать, чтобы использовать его правильно.
На самом деле нода, это мощная штука, специально заточенная под определенный круг задач, высоконагруженные системы и тому подобное. Любое не правильное или даже сказать не полностью правильное его использование оборачивается на больших проектах большим минусом, что собственно и спрашивалось в вопросе выше. Чтобы избежать всех таких минусов, нужно практиковаться и учиться на своих и чужих ошибках, и только со временем и опытом можно действительно понять насколько хорош этот инструмент.
Владение нодой в плюсах или минусах в большинстве случаев зависит от полноты его знания, теории, практики, владения и умения применить эту технологию в целом ко многим проектам.

Answer 4

[Вениамин Лыткин]

Node.js - является JavaScript библиотекой, а JavaScript является интерпретируемым языком, а не компилируемым. Так же JavaScript не типизированный, из-за чего сложно писать большие проекты. На сколько мне известно, JavaScript является Single thread (однопоточный) - то есть использует только 1 ядро процессора.

Answer 5

[lega]

Как выше сказали - большой проект разрабатывать на node.js не желательно из-за сложности (сравните 2 псевдо-примера), - будете иметь больше проблем, потратите в разы больше времени.

В большинстве случаев асинхронность нужна для 0-5% от проекта, поэтому не нужно из-за этих 5%, остальные 95% делать асинхронными.
Асинхронность нужна не везде.

Answer 6

[Александр Аксентьев]

Потому что он молодой и относительно медленно развивается(именно ядро)

habrahabr.ru/post/218147

Недавно вообще разделился на два проекта, так что, что будет дальше несовсем ясно

Comments

[Vlad Timofeev]

Будем надеяться что команда io.js сделает ноду в разы лучше... осталось пару дней и думаю все станет ясно по-поводу "медленно развивается "

Answer 7

[Александр Садовников]

на Node.js, мне кажется, сложно писать большие проекты. Ещё нет устоявшихся практик (хотя, возможно, это мне так кажется), спроектировать приложение так, чтобы его было поддерживать сложно. Асинхронность тоже может выйти боком (опять-таки в архитектурном плане). И нужна ли она типичному веб-проекту (условному бложику на вордпрессе)?