Что не так с Node.js?

Question

[Wilfnerd]

Я новичок в джаваскрипте, только недавно закончил его изучение. Меня пригласили поучаствовать в одном проекте, где я буду писать серверную часть на Node.js , так сказать набить руку и набраться хоть какой то практики в JS.
Рассказав эту новость своим друзьям, они стали плеваться на ноду и ругать ее. Говорили , что node.js медленный и вообще писать серверную часть на JS - унизительно. Один знакомый сказал про Node.js "Было им мало быдлокода на клиенте, они еще и на сервер его перетащить захотели".
Что с этим Node.js не так? Чего его так ругают? Что мне говорить в ответ на такие упреки? =)

Comments

[kotofey]

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

[Владимир]

Пускай плюются, тебе то что. Поработаешь, а дальше сам решишь надо ли оно тебе.

[Дмитрий Авилов]

Очень странные у вас друзья, между прочим. Асинхронное программирование ИДЕАЛЬНО для веб-разработки, где львиная доля времени тратится на ожидание ответа от сети/базы. Сами они быдлокодеры, с нодой всё хорошо, и она-таки может быть очень быстрой, даже с математикой может работать достаточно быстро.

[un1t]

Дмитрий Авилов: Асинхронное программирование идеально для специфических задач веб-разработки, типа написания чатиков, но для 95% задача, больше подходит синхронное. Для написания интернет магазина, никакая асинхронщина не нужна, более того она будет мешать. JS не быстрый, не знаю откуда вы это взяли. Он достаточно медленный, производительность сравнима с другими интерпритируемыми языками.

[Родион Шергин]

Миллион одновременных соединений на Node.js habrahabr.ru/post/123154

Answer 1

[un1t]

Высоконагруженные проекты пишут на любых языках, многие написаны на php или perl. Нельзя называть эти языки быстрыми.
То что он держит какую-то нагрузку это просто смешно. Никакую нагрузку он не держит, яваскрипт достаточно медленный, впрочем тоже можно сказать и о php.
Нагрузку держит асинхронный поход (не яваскрипт!) который искользуется в том случае если у вас IO bound сервис, т.е. большую часть веремени он ничего не делает, а просто ждет ответа от другого сервиса или БД.
Решать какие-нибудь задачи которые CPU bound на node.js ... ну вобщем это не подходящий инструмент, т.к. язык медленный, будет все работать медленнл.
У меня лично претензии к js, что язык этот имеет мало возможностей и много костылей, хотя он активно развивается и в ES6 видно много улучшений В node.js мало библиотек, они сырые и медленные. Я сравниваю с Python, но даже у PHP тут есть преимущества. На node.js нет полноценного веб-фреймворка, аля Django, RubyOnRails или Yii. Конечно это вопрос времени, но пока все сыро.

node.js и асинхронный подход.
На ноде большинство библиотек асинхронные, если ты захочешь написать что-то синхронное, то у тебя будут проблемы.
Асинхронный подход он не хороший и не плохой, это инструпент для решения определенных задач.
Люди же использующие ноду используют асинхронный подход везде, они вынуждены. Но это как забивать гвозди микроскопом - долго дорого, неудобно и ненадежно.
Асинхронный подход нужен для решения специфичесих задач. C# или Python имеют языковые конструкции упрощяющие асинхронное програмирование, но в ноде ничего подобного нет. Писать асинхронный код на JS это тот еще геморой. Всякие anync и promise немного улучшают ситуацию, но проблема остается.

Comments

[Тимофей]

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

Фреймворки есть. Sails, Meteor как минимум. Хотя на мой взгляд гораздо удобнее использовать express и только необходимые модули и обработчики запросов во всех случаях.

Естественно, коллбэк-макароны выглядят плохо, было бы глупо это отрицать. Но, во-первых, это цена, которую вы платите за возможность поделать что-то полезное, пока выполняется запрос к БД, а, во-вторых, "всякие async и promise" разрешают ситуацию достаточно изящно, чтобы асинхронный код хорошо писался и читался. Я говорю как человек, пересевший с PHP и Rails на Node.js. К этому просто нужно привыкнуть, как и ко всему новому.

[un1t]

>Никаких костылей в языке нет
Я конечно понимаю, что задокументированный баг является фичей, но язык магко говроря плохо продуманный. Не даром большинство старается не писать на голом js, а используют какой-нибудь coffee script. Компилировать интерпритируемый язык, это тоже сомнительная фича.

То что есть хорошие библиотеки на все случи жизни, это мягко говоря преувеличение. Зачастую после поисков приходится писать самому, т.к. подходящих нет.

Sails, ну я смотрел не него, сам не пробовал. Общался с парнями которые писали на нем проект, они долго плевались, матерились, сказали что он очень-очень сырой и лучше бы они писали на express. Про метеор сказать не могу, но во всяком случае это не аналог Django или Rails, кажется это спецефическая штука для определенных задач. Если у тебя другой опыт, расскажи.

express - это микрофреймворк, микрофреймоврк это как чемодан в котором одна отвертка, иногда этого достаточно, но в целом никаких возможностей он не предоставляет и приходится постоянно писать велосипеды.

> "всякие async и promise" разрешают ситуацию достаточно изящно, чтобы асинхронный код хорошо писался и читался.

это только в простых ситуациях, а если в появляется какая-то логика, то уже не спасают

> Но, во-первых, это цена, которую вы платите за возможность поделать что-то полезное, пока выполняется запрос к БД,

Во первых для многих проектов смысла писать асинхронно нет вообще. Синхронный код проще и надежней. А во-вторых нода не единстыенный способ писать асинхронный код. Есть языки в которых есть поддержка асинхронности на уровне языка, или какие-то языковые конструкции не предназначенные напрямую для асинхронности, но упрощающие написание такого кода. Там асинхронный код читать и писать проще, например Python.

Как в выше в комментах писали, на ноде редко пишут проект полностью, как правило это просто прослойка между бакендом и версткой. Во многих случаях ненужная. Я лично знаю такие весьма странные примеры когда в компании повялется любовь к ноде. Если реньше простой проект делелся силой двух разработчиков - бакенд и фронтэнд, то теперь нужно привлекать третьего человка который делает прослойку на node.js. Т.е. аналогичные проекты теперь делаются в полтора раза дороже. Весьма странный подход, но выбор языка это видимо вопрос моды/веры (нужное подчеркнуть), а не взвешенного подхода.

[Тимофей]

un1t:
Sails - на самом деле просто шаблон приложения с предустановленным набором модулей и заданной структурой, а не полноценный фреймворк. И да, метеор это не Rails или Django. Express - да, это микрофреймворк. Но особенность (я не говорю, что это явное преимущество, а именно особенность) ноды в том, что в ней не делается все так, как в привычных фреймворках. Просто берутся только те модули (отвертки, если хочешь), которые в данном случае нужны, их "долгая" логика запихивается в какой-нибудь async.parallel или как middleware в express и затем просто обрабатывается результат. Подход применим для любого сложного случая. Если попробуешь сам, то убедишься в этом. На самом деле очень сложно передать это текстом, нужно просто попробовать.

Я согласен, что не во всех проектах нужен асинхронный подход. Но то же верно и для любого другого подхода/шаблона. Это вообще очень философский вопрос - что и для чего больше подходит) Но асинхронная обработка, однозначно, хорошо вписывается в приложения, где есть много работы с данными, коими является большая часть интернета. И синхронный код не "проще и надежнее", а просто "привычнее".

Про прослойку я согласен, это как-то странно, но о такой форме извращения я не упоминаю)

[un1t]

elser: Про скорость работы это даже не смешно. Посмотрите скорость xml-парсеров написанных на чистом js, не сишные модули для ноды, а парсры написанные на js, сравните скорость работы, попробуйте распарсить файлик в 5ГБ. Скорость JS несмотря на любые заявления сраванима с другими интерпритируемыми языками, это минимум в 10-30 раз медленней чем плюсы, ну и до явы тоже очень далеко. Может быть он компилируется в байткод быстрее, но нас же не это интересует, а скорость исполнения.

[un1t]

Тимофей: микрофреймоврки это отдельная тема для холиваров, в том же питоне их полно flask, wergzeug, bottle.py, falcon и еще 100500. У них есть сторонники, с похожими на ваши аргументами. Лично я не сторонник микрофреймворков, можно и совсем тогда без фреймворков писать, будет еще "гибче" и "быстрее" а велоспипедов еще больше. Это похже на аргументы людей которые не используют стандартные библиотеки, а пишут свои функции. Написать микрофреймоврк времени много не надо, поэтому в питоне их такое огромное количество. А вот отсутствие полноценных фреймворков говорит о незрелости платформы node.js, хотя конечно лет через 5 я думаю они появятся. Ну и с npm есть свои приколы, когда зависимости подгуржаются внутрь зависимостей. В теории тут есть поределенные плюсы, но на практике получается какая-то раздутая жесть с зависимостями, вплоть до того как у нас на диске постоянно заканчиваются иноды.

[un1t]

elser: Гигабайтные файлы это не редкость, это выгрузка для Яндекс.Маркета например у крупных магазинов файлы замниают несколько гигов, даже по одной категории товаров. Не знаю откуда у вас такое впечатление, я говорю о тех вещах с чем сталкиваюсь. У меня куча проектов у которых требования к производительности 1000 rps с 4-8 процессоров. Только это не заслуга ноды, нода с этим не справляется. Приходится все кешировать. А закешированные результаты можно хоть на PHP отдавать с такой производительностью. Шаблонизация выполняется медленно, xml парсинг выполняется медленно, все что требует участия процессора выполняется медленно. От вас интересно услышать откуда у вас такие фантастические данные о производительности js?

[Тимофей]

un1t: Я не спорю, что микрофреймворки - это вполне себе тема для споров. Но не согласен с тем, что они заставляют что-то изобретать и писать заново. Если, конечно, подключение модуля и вызов ряда его функций не считать велосипедом. Отсутствие фреймворков (точнее их малое количество) - с одной стороны, да, это из-за незрелости - ведь все-таки нода куда моложе конкурентов - но, с другой стороны, в ноде сложились определенные хорошие практики, которые включают в себя как раз подход с модулями, асинхронностью и микрофреймворками. Опять-таки, я не берусь разводить по этому поводу холивар, но нужно понимать, что нет ничего однозначно плохого или хорошего. Ты же как-то однобоко смотришь на особенности технологии, пытаясь выставить их исключительно как недостатки. Согласись, довольно глупо ту же асинхронность описывать как никому ненужное говнище, без которого до сих пор люди обходились и которое только усложняет жизнь разработчику (хотя это не так). Есть и другая сторона этого подхода.

[un1t]

Тимофей: Моя мысль не в том что асинхронность это плохой инструмент, а в том что для решения аcинхронных задач, которые как-то решает нода, есть более подходящие инструменты. А для решения синхронных задач, тем более есть более подходящие инструменты. Я вижу одни только недостатки потому, что сравниваю с инфраструктурой Python, на мой взгляд он гораздо больше подходил для решения задач, которые пытается решать нода. Производительность для CPU bound задач у python лучше , т.к. куча библиотек для питона написана на сях. Производительность для IO bound задачь, такая же как в ноде. Поддержка асинхронности в python3 есть на уровне языка, а в python2, есть очень хорошие решние например в Торнаде, которое позоляет спрямлять лапшку колбэков, опять же за счет констуркции языка yield (хотя она изначально не связана с асинхронностью). Выбор готовых библиотек и фреймворков опять же в python гораздо больше. Если бы я сранивал node.js с Java, то наверное увидел бы у ноды какие-то плюсы, т.к. на JS писать все-таки проще чем на Java, хотя производительность тут опять же проигрывает. Но мой опыт это Python и я сравниваю все с ним, а перед питоном у ноды я никаких преимуществ не вижу. К популярному express.js, я уже написал пару библиотек для себя, потому, что нормальных готовых решений нет, хотя в любых полноценных фрейморках такие простые штуки есть из коробки.

[Тимофей]

un1t: Производительность у ноды хороша. Я бы не брался ее вот так вот просто с чем-то сравнивать, так как есть куча тестов с противоречивыми результатами, но нода во многих из них выглядит достаточно выгодно, в частности и по сравнению с python. Но все зависит от задач.
И я не понимаю, почему ты упорно пытаешься выставлять ноду как плохую реализацию асинхронного подхода, тогда как JS всегда был и будет языком, на котором все делается асинхронно и делается, как показывает практика, неплохо. К тому же, ничто не стоит на месте и с выходом версии, поддерживающей ES6, все станет только лучше.
Выбор библиотек тоже становится богаче с каждым днем, многие из них реализованы на сях. Но нода молодая технология, ей еще нужно догонять конкурентов, это да. Хотя, например, для фронтенд разработки на текущий момент инфраструктура ноды, пожалуй, самая богатая.
А что за библиотеки для express?

[un1t]

Тимофей:

>Производительность у ноды хороша.
Производительность достатачная для решения ряда задачь и все. Но утверждать что JS имеет производительность превосходящую python и тем более сравнимую с плюсами это не серьезно.

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

Прочитай про yield from и asyncio в питоне3 или документацию по Торнаде, или или async/await в C#? тогда возможно поймейшь о чем я говорю. В Go кажется тоже были какие-то хорошие штуки для асинхронщины, но сам Go менее удобен, т.к. более низкоуровневый чем JS. Но вот производительность у Go хорошоая, в отличе от JS.

> JS всегда был и будет языком, на котором все делается асинхронно и делается, как показывает практика, неплохо.

Никто не пишет языки компилируемые в python или ruby, потому что эти языки достаточно удобные, а с JS никто не хочет иметь дело, я лично понимаю почему. Поэтому появились CoffeeScript, .и еще 100500 разных -script, которые компилятся в JS. Это явный показатель, что язык как миниму довольно беден. ES6 это хорошо, но пересядут ли люди с CoffeScript на JS, думаю это будет показателем.

>Хотя, например, для фронтенд разработки на текущий момент инфраструктура ноды, пожалуй, самая богатая.
Ну да, на ноде есть такие штуки как grunt/gulp, но это инструменты для сбора верстки, это не имеет отношения к серверному программированию.

[Тимофей]

С плюсами я и не пытаюсь сравнивать, я только сказал, что есть модули, которые написаны на сях. А с питоном некоторые тесты показывают, что нода быстрее. Просто вбей в гугл "python vs node.js performance" и сам убедишься. Я не утверждаю, что нода однозначно быстрее чего-то, но то, что производительность ее слабое место, сказать тоже нельзя.

Одна инструкция yield не делает язык асинхронным. Async и await в C# - это, считай, синтаксический сахар для событий.

"Никто" слишком громкое слово. Многие любят JavaScript таким какой он есть. Не все его понимают после языков вроде C#, Java, Python, Ruby. Оно и понятно, JS местами фундаментально отличается от них, при этом синтаксически оставаясь похожим, что может запутать. Синтаксический сахар для JS как раз призван сделать его более привычным для тех, кто перешел с других языков. Не нужно путать это с бедностью языка. Я согласен, что JS не идеален, но раз уж на то пошло, то в питоне this зачем-то передается как первый параметр в каждый метод класса, это ли не извращение?) А ES6 решит чуть ли не все проблемы с JS, в частности добавит сахара для определения класса, сделает немногословные конструкции для анонимных функций.

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

P.S. На самом деле я вполне адекватно воспринимаю и ноду, и все остальное. И прекрасно понимаю, в частности, что питон крут. Просто и питон, и нода, и прочие языки и технологии имеют полное право на существование, так как все могут решать с переменным успехом разные задачи. Сколько бы мы не спорили, это факт) Нода как минимум очень активно занимает нишу веб-приложений. И ведь неспроста, ведь умные дядьки почему-то отдают предпочтение именно ноде, причем с каждым днем таких дядек все больше.

И что за библиотеки к экспрессу ты писал?

[un1t]

>Просто вбей в гугл "python vs node.js performance" и сам убедишься.
Да смотреля эти тесты, если ты погуглишль тесты по Java, то будешь уверен что она быстрее плюсов или по крайней мере почти такая же быстрая как плюсы. Но практика показывает, что это не так, а с потреблением оперативки дак вообще ад.
Специально подобранными тестами можно доказать все, что угодно.
В тестах сраниваются всякие hello world, это мягко говоря далеко от реальности.

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

>Одна инструкция yield не делает язык асинхронным. Async и await в C# - это, считай, синтаксический сахар для событий.

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

>И что за библиотеки к экспрессу ты писал?
Например csrf, в npm есть подобные модули, но они кривые.

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

[lega]

Опущу проблемы самого языка JS, у самого асинхронного подхода есть "проблема", разработчиков прет от асинхрона первые пару лет, но если делать на нем все подряд, то уже через несколько лет от этого начнет "тошнить", и вот тогда разработчик начинает использовать асинхрон тогда когда нужно, а не везде подряд. И без разницы node.js там или async.io. Это что-то из разряда "сложности" в разработке, что тяжело доказать, это нужно пережить.

Answer 2

[Денис Инешин]

У node.js своя ниша. Никто не пишет обычный сервер на нём, а пишут некий middle layer между server side и client side для работы на очень высоких нагрузках. Кроме того, давно минули те дни, когда node.js был еще совсем зеленым страдал кучей детских болезней. Сегодня это полноценная платформа для разработки, которая обросла кучей плагинов и фреймворков. Взгляните например на https://www.meteor.com/

Comments

[Yuri Shikanov]

то, что node.js решение для "высоких нагрузок" - это миф

[Денис Инешин]

Yuri Shikanov: ну допустим, скажем это еще один удобный уровень абстракции.

[Оптимус Пьян]

Yuri Shikanov: а миллион открытых соединений кроме ноды что ещё выдержит? (ну С-языки не берём)

[Yuri Shikanov]

Дмитрий: Go, Erlang, OpenResty, aiohttp - то что первое в голову пришло. В любом случае высокие нагрузки - это проблема архитектурная и решить ее использованием волшебной технологии не получится.

[bromzh]

Дмитрий: много кто: java/scala + netty, erlang, go, скорее всего даже питон с руби смогут, тут немаловажную роль играет железо.
В этом бенчмарке нода эпично сливает.

[Тимур Шемсединов]

Все, что нода даст, экспресс заберет

Answer 3

[Тимур Шемсединов]

Сперва пусть приведут аргументы, а то "плеваться" и "ругать" можно просто так, на ровном месте, говорить "медленный" и "унизительно" - это просто пустые пропагандистские слова. Спрашиваю недавно одного специалиста, почему ZeroMQ быстрый? Ответ: он же на стероидах, в доках так и написано. Так что, для объяснения явлений без фактов можно просто давать им умные названия. Почему предметы падают - гравитация, а... ну тут сразу все понятно. Почему нода плохая - потому, что это говнокод. Добавляю еще методические указания к холиварам: статья "Как распознать идиота во время дискуссии"