Есть ли веская причина избегать node.js для веб-приложений не в реальном времени?

29

Я видел много разговоров о том, насколько классным является Node.js для веб-приложений реального времени - вещи, для которых нужны сокеты, Comet, AJAX-интенсивная связь и так далее. Я знаю, что его асинхронная, управляемая событиями модель, управляемая событиями, также хороша для параллелизма с низкими издержками.

Я также видел учебники по Node.js для более простых, «традиционных» приложений не в реальном времени (например, стандартный пример блога, который кажется стандартным «Hello World» для людей, изучающих разработку приложений). И я также знаю, что node-static позволяет вам обслуживать статические ресурсы.

Мой вопрос: есть ли веская причина избегать Node.js для традиционных веб-приложений, таких как объявления, форумы, пример вышеупомянутого блога, или для того, чтобы создавать приложения CRUD для внутренних бизнес-приложений? Только потому, что он превосходит все интересные вещи в реальном времени, это противопоказано для более уравновешенного использования?

Единственное, о чем я могу подумать, это отсутствие зрелых библиотек (хотя это меняется).

(Причина, по которой я спрашиваю, заключается в том, что я рассматриваю возможность отключения PHP для Node.js, в основном, чтобы преодолеть несоответствие импеданса при переключении между языками, но также и для того, чтобы я мог повторно использовать проверочный код и еще много чего. Мой суперэго убеждает меня выбрать лучший инструмент для работы , однако у меня не так много времени, чтобы выучить пятнадцать языков и все их пользовательские библиотеки только для того, чтобы иметь полный арсенал. Также обнадеживает то, что Node.js может дать мне более простой путь оптимизации, чем PHP / Apache в будущем, когда я должен начать думать о интенсивном движении.)

[РЕДАКТИРОВАТЬ] Спасибо за ответы, ребята; Я просто хочу посмотреть, будет ли кто-нибудь еще взвешиваться, прежде чем я выберу ответ. Ответ @Raynos вроде подтверждает то, что я думаю, и ссылки от комментаторов предоставили хорошую пищу для размышлений, но я хочу посмотреть, есть ли у кого-нибудь еще какие-либо специфичные для Node ответы, такие как «НЕ ИСПОЛЬЗУЙТЕ NODE ДЛЯ ПРОБЛЕМЫ X» ». (Помимо задач с высокой загрузкой процессора; я это уже знаю :-)

web-development web-applications node.js

— Пол д'Ауст
источник

1

@ default.kramer: Спасибо за ссылку, мне очень понравилось!

— Зак

1

Вот Это Да! Скорее самоуверенный парень, а? В следующей статье он, по-видимому, говорит, что для приложений с высоким вводом-выводом и с низким использованием ЦП четные и многопоточные системы примерно на одном уровне, и что проблема заключается в начинающих программистах, которые не знают, когда отказаться от событий и создать новую тему. Но незнание программиста не означает, что инструмент плох, не так ли? Я согласен с тем, что использование среды, в которой есть циклы событий для задач с интенсивным использованием процессора, немного странно, но разве это зло?

— Paul d'Aoust

1

Его ненависть к JavaScript, кажется, тоже важная проблема, которая, боюсь, может быть отчасти ответственна за энергию его аргумента.

— Paul d'Aoust

@ Пол - Вы, вероятно, должны взять это с зерном соли. Я не знаю много о Node.js; Я просто подумал, что это было смешно. (как и большинство его сочинений)

— default.kramer

@ default.kramer спасибо за напоминание; Я склонен воспринимать мнение людей как Евангелие. Похоже, его главная веская критика заключается в том, что вы не должны использовать Node.js для задач, интенсивно использующих процессор. Я смущен его критикой рабочих процессов; Есть ли большие проблемы с созданием отдельных работников для конкретных задач?

— Paul d'Aoust

13

Есть ли веская причина избегать Node.js для традиционных веб-приложений?

Да, если у вас есть N лет на веб-платформе X, тогда вы, очевидно, сможете быстрее разработать приложение на платформе X.

Если вы хотите сделать Y, и у платформы X есть готовое решение Y, которое делает X, то сделайте это.

Все общие причины того, почему вы должны использовать одну платформу над другой.

какие CRUD-приложения вы создаете для внутренних бизнес-приложений?

Да, есть другая платформа, которая позволяет вам быстрее написать универсальное приложение, на ум приходит ruby on rails.

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

В основном это простой вопрос

Существует ли инструмент, который делает все это для меня? Нет, тогда выберите наиболее удобную платформу для написания инструмента.

Нет никаких веских причин, почему node.js является неудобной платформой (кроме «я ненавижу javascript»)

— Raynos
источник

Итак, вы думаете, что прагматические принципы, такие как знакомство, наличие библиотек и т. Д., Являются сильными аргументами для определенной платформы, а? Это хорошие мысли, и я определенно думаю об этом. (Я удивлен, что вы выступаете за нестандартные решения; я думал, что вы любопытный парень!)

— Paul d'Aoust

@ Pauld'Aoust Я своего рода крутой парень. Однако я ничего не делаю и у меня нет сроков.

— Raynos

хех, спасибо за оговорку. Я помню ваши комментарии в чате node.js об использовании библиотек моделей других людей (Backbone.js и т. Д.) И осознании того, что я тратил слишком много времени на изучение Backbone.js, а не на то, чтобы просто использовать (и изучать) JavaScript прототип наследования механизма. Хороший совет; Я чувствую себя намного более расслабленным сейчас.

— Paul d'Aoust

4

-1 расплывчато 1) То, что у вас есть N-летний опыт работы в X, не означает, что вам следует избегать Node.JS. Вы предлагаете преднамеренное невежество, основанное на опыте? И каковы «общие причины»? 2) «другие приложения, которые позволяют быстрее написать универсальное приложение» - это чисто субъективно. 3) «иное», чем «* я ненавижу * JavaScript» - это тоже субъективно и не является веской причиной, чтобы избегать процветающей технологии. * Правописание.

— Джек Стоун

@ClintNash Некоторые ваши причины ничем не отличаются от его. «Человеческие ресурсы» против «N-летнего опыта» точно такие же. «NodeJS не такой зрелый, как традиционные фреймворки» против «Да, есть другая платформа, которая позволяет вам быстрее написать универсальное приложение, на ум приходит ruby on rails». также одинаковы. Они не только одинаковы, но и вы не более измеримы (объективны), чем его.

— аааааа

6

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

Помните, что узел - это собственный сервер. Это создает сложности, если вы хотите запустить больше, чем просто одно приложение node.js. то есть, если у вас более одного сайта / домена, размещенного на машине. Это не похоже на стек LAMP, где вы можете иметь дюжину PHP-приложений для полдюжины разных доменов, работающих на одном сервере (по крайней мере, на порту 80). Существуют платформы для узла, которые, вероятно, делают это возможным, но это добавляет сложности, которая вам просто не нужна, если вы придерживаетесь традиционных веб-платформ. (Разумеется, вы также можете настроить прокси-серверы, разместив веб-сервер перед узлом, но это лишает преимущества использования узла).

Imo, Node идеально подходит для работы в сочетании с традиционным веб-сервером. Способ, которым я сейчас все организовал, состоит в том, чтобы обслуживать статические html / js / images через apache и обрабатывать потребности в данных в режиме реального времени путем длительного опроса приложения узла.

— GrandmasterB
источник

+1 простота использования при настройке нескольких хостов, безусловно, стоит рассмотреть.

— Пол д'Ауст

Довольно просто разместить приложения узла за сервером Apache httpd или nginx и направлять запросы с помощью подписи URI этого приложения на порт узла (или порты).

— TomG

+1 - понятие node.js как прокси-сервера на стороне сервера («в сочетании с традиционным веб-сервером») получило распространение в начале этого года и заслуживает изучения - особенно если у вас есть большая традиционная архитектура для управления. Это шаблон проектирования, который, кажется, имеет смысл для предприятия. Но стоит отметить - это не причина ИЗБЕЖАТЬ Node.js, а причина использовать его для определенных целей.

— Джек Стоун

4

-1 - Поместить прокси (например, nginx) перед узлом - это идеальный вариант использования, и в некоторых случаях он гораздо более безопасен и эффективен, чем его отсутствие. Это не побеждает никаких преимуществ узла. Я обычно запускаю свои приложения для узлов в доменных сокетах Unix, а затем nginx выступает в роли привратника.

— Скотт Андерсон

3

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

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

— Майкл Даррант
источник

так что вы думаете, что не очень много против использования Node вместо более традиционных стеков приложений; проблемы больше связаны с реальными проблемами?

— Paul d'Aoust

+1. Человеческие ресурсы - и нежелание некоторых изучать JavaScript - это неудобная правда. Этот ответ гласит это хорошо. Но избегать Node «потому что люди ненавидят JavaScript» тоже не логичная прогрессия. Где бы мы были технически, если бы избегали всех нововведений - которые кто-то еще ненавидел? Нигде. Задача с узлом - это A) Получение нового таланта или B) Обучение традиционному таланту новым талантом. К тому моменту - мы видим, что школы кода JavaScript появляются повсюду, так как Джон Резиг предвидел основание Академии Хана. Короче говоря, это способ вещей. +1. Хорошо сказано.

— Джек Стоун

3

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

Мне было очень любопытно узнать (как и Paul d'Aoust), где существуют ограничения Node.JS. К сожалению, многие ответы ПОЛНОСТЬЮ субъективного смещения и временного обоснования.

Я спросил себя: МОЖЕМ ЛИ МЫ Сфильтровать субъективную предвзятость и получить твердые ответы на этот важный вопрос?

Остальные точки кажутся:

1. NodeJS не такой зрелый, как традиционные фреймворки. Как полагает Пол д'Ауст, это только временная причина, но не для полного избегания, а для проверки и должной осмотрительности. Ожидается, что мы сделаем домашнее задание в качестве веб-профессионалов, и наша задача - определить наилучшее соответствие технологии организации, их потребностям, будущему, команде (а не нам). Зрелость - это необходимость в разъяснениях и суждении о склонности к риску, но не в уклонении.

2. NodeJS в качестве прокси-сервера. Мудрое предложение, предшествующее обсуждению, которое стоит рассмотреть и рассмотреть. Это понятие использования Node во взаимосвязи с существующими технологиями в качестве шаблона проектирования прокси интерфейсного интерфейса. Но также, это не причина избегать использования узла, а причина избежать его использования в качестве полной замены. Вместо этого выбрал следственный подход.

3. Узел отладки. В разговоре с основными разработчиками Node в Joyent есть много сложностей, связанных с отладкой и отслеживанием основной причины проблем, возникающих в ядре (на основе выполнения одного потока и неспособности увидеть прошлые потоки). Это заслуживает рассмотрения и оценки - но (опять же), вероятно, не отвращение к общему использованию только крайних случаев, которые могут раздвинуть границы. Может быть, ваши конкретные потребности попадут в эту категорию, а может и нет.

4. Человеческие ресурсы. Это лучшая причина ИЗБЕЖАТЬ использования JS на этой странице, и, по моему скромному мнению, это полная и неудобная правда. Возникает вопрос: есть ли у вашей компании подходящие талантливые профессионалы, чтобы увидеть проект в полном жизненном цикле? Если нет, то нет сомнений, что вам нужно избегать NodeJS. Или вместо этого рассмотрите A) поиск правильного таланта или B) Обучение существующему таланту.

Жалобы: Мое наблюдение за жалобами на JavaScript состоит в том, что многие из них являются результатом ошибки пользователя, а не постоянных ошибок языка. Мы опровергли множество претензий к «The Hate JavaScript Diatribe», и мы продолжим опровергать многие другие. Такие проблемы, как - документация недостаточно хороша, она недостаточно сексуальна, но людям это не нравится, это рак, это дьявол или она слишком «склонна к опечаткам» (-CRichardson), субъективны и предвзятые жалобы, которые необходимо отсеять для точного принятия корпоративных решений.

В конце концов, правильный ответ может быть - нет веских причин ИЗБЕЖАТЬ NodeJS . Может быть, поэтому он переживает быстрый рост, принятие и вклад. Но для всех нас, возможно, ответ здесь состоит в том, чтобы продолжать оценивать, исследовать и лучше понимать NodeJS - и искать конкретные отвращения. В стремлении быть открытым для понимания, где именно Node.JS незрелый - мы находим именно то, что нам нужно, чтобы сделать его лучше. И это благословение.

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

— Джек Стоун
источник

-1

Есть ли преимущество использования узла над X для приложений не в реальном времени:

Scaling : Узел имеет хорошую производительность , но и другие платформы делают слишком; PHP, Ruby, Python и Java все масштабируются. Вы можете найти большие имена с миллионами пользователей, использующих их.
Один язык для внешнего интерфейса и внутреннего интерфейса : это шутка, как в Java «Пиши когда-нибудь, беги куда угодно»
Горячий и сексуальный : единственная действительная точка. Но никого не волнует, что ваш сайт использует острые технологии!

Преимущество использования X over Node для приложений не в реальном времени:

Рекомендация . Поскольку Node является новым, он имеет меньше рекомендаций, чем другие платформы, особенно для веб-приложений CRUD.
Язык Javascript : людям не нравится Javascript. Пока Node.js горячий, а Javascript нет. Вот почему люди создали Coffeescript, чтобы избежать написания Javascript даже для клиентской части.
Скорость разработки . Старые и скучные фреймворки, включая, помимо прочего, Rails и Django, хорошо проверены и улучшены на протяжении многих лет для веб-сайтов CRUD. Хотя вы можете реализовать аналогичные приложения в Node, это проще сделать в среде вашего дедушки.
Стабильность : веб-фреймворки Node улучшаются в более быстром темпе. Это означает, что они меняются и будут иметь больше API-несовместимости в ближайшем будущем.
Библиотеки и инструменты : старые технологии с большим количеством пользователей имеют больше библиотек и инструментов.

Мой ответ определенно не будет действителен в 2015 году. В 2014 году пропустите Node для веб-приложений не в реальном времени, но следите за ним.

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

— Хоссейн
источник

2

-1. Я согласен, что этот ответ не будет действителен в 2015 году. Но это также повод для понижения. По сути, решения сегодняшнего дня - это решения завтрашнего дня. Это сводит на нет 8 пунктов выше, если мы видим, что они имеют временное значение. 1) Масштабирование - Walmart Mobile весы, а не причина, чтобы избежать Node. 2) Изоморфный JS не шутка. Не причина. 3) сервер сексуальность? Большинство пользователей знают только UX. 4) Лучшая практика субъективна, 5) Не жарко? Субъективно 6) Легче? Субъективные. 7) Стабильность является временно значимым моментом. 8) НПМ, по прогнозам, должен пройти Maven в 2014 году. Здесь нет причин. Downvote.

— Джек Стоун

-1

Node.js - очень популярная платформа, и у нее много интересных функций, но использование инструмента - это личное предпочтение. Я дал Node.js четыре раза, и мне это не понравилось. Вот мои причины. Пожалуйста, имейте в виду, что некоторые из этих причин являются устаревшими или просто личными: P

Я предпочел другой язык / синтаксис (мне нравится Python, Scala, мой любимый язык - Prolog, так что да).
Качество документации для каркасов и библиотек, которые я использовал, не так хорошо для библиотек Java, Scala, Python.
Разработчики nodejs довольно одержимы обратными вызовами, а не моделью событий, наблюдателем или фьючерсами.
Есть готовые решения для того, что я хочу сделать в Ruby, Python, Java, разработанных еще в 2005 году, мне просто нужно отредактировать файл конфигурации.

— Давид Сергей
источник

2

-1 - субъективные баллы. «Предпочтительный синтаксис», «Документация не так хороша», «Навязчивые обратные вызовы» и «Уже выполнено на моем языке» - все они расплывчаты и субъективны. Мы слышали это раньше. Они развенчаны. Нет причин избегать Node.JS здесь. Downvote.

— Джек Стоун

1

Все пункты являются моими личными предпочтениями, которые я высказал открыто. Кроме того, как вы опровергаете личные предпочтения?

— Давид Сергей

-9

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

Тем не менее, узел лучше подходит для конкретного типа архитектуры приложения. PHP это HTML-файлы, содержащие немного кода. Узел - это код, необязательно содержащий немного HTML.

Это означает, что если ваше приложение представляет собой стандартную HTML-форму без какого-либо скрипта на стороне клиента, PHP будет проще. В Node есть шаблоны, но, очевидно, они не такие зрелые, как PHP.

Если у вас много сценариев на стороне клиента и вы сохраняете данные с помощью ajax, вы получаете статический HTML-клиент, вызывающий функции на сервере. Это именно то, в чем хорош узел. Хотя CRUD-приложения обычно создаются не так, вы можете создать что-то довольно красивое с помощью подходящей среды.

— Том Кларксон
источник

Выяснилось, что HTTP не имеет состояния и работает в реальном времени; однако меня больше интересует прагматическая озабоченность по поводу типичного определения реального времени: большие объемы запросов с небольшим весом. Кажется немного излишним ускорение нового экземпляра PHP, чтобы иногда выдавать три или четыре строки JSON. Я прав или я просто страдаю от синдрома попугая?

— Paul d'Aoust

Если вы не загружаете PHP, вы загружаете javascript, и кеширование задействовано в различных видах, поэтому разницы будет недостаточно. Большая разница заключается в стиле кодирования и, следовательно, в удобстве обслуживания - обе платформы могут выводить либо HTML, либо JSON, но PHP был разработан для людей, привыкших к редактированию статических html-файлов, а узел - для людей, привыкших к современному программированию на JavaScript.

— Том Кларксон

Я знаю, что мне нужно некоторое время загружать интерпретатор, но я вижу преимущество в том, что постоянно запускается один экземпляр интерпретатора (для приложений с небольшим процессором, конечно), как в Node.js, а не вращение интерпретаторов. и завершать с каждым запросом, как в PHP.

— Paul d'Aoust

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

— Том Кларксон