Чи є вагомі причини уникати node.js для веб-додатків у режимі реального часу?

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

Я також бачив підручники Node.js для більш простих, "традиційних" додатків у режимі реального часу (наприклад, стандартний приклад блогу, який, здається, є стандартом "Hello World" для людей, які навчаються розробці додатків). І я також знаю, що вузол-статичний дозволяє обслуговувати статичні активи.

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

Єдине, про що я можу придумати, не кажучи про те, - це відсутність зрілих бібліотек (хоча це змінюється).

(Причина, про яку я прошу, полягає в тому, що я розглядаю можливість виривання PHP для Node.js, здебільшого, щоб подолати невідповідність імпедансу перемикання між мовами, але також я можу повторно використати код перевірки та інше. Моє superego закликає мене вибрати вибір найкращий інструмент для роботи , однак у мене не так багато часу, щоб вивчити п'ятнадцять мов та всі їх бібліотеки, щоб мати повний арсенал. Це також заспокоює, що Node.js може дати мені простіший шлях оптимізації, ніж PHP / Апачі в майбутньому, коли мені доведеться починати думати про інтенсивний рух.)

[EDIT] Спасибі за відповіді поки що, люди; Я просто хочу дізнатися, чи буде хтось зважуватися, перш ніж я обрати відповідь. Відповідь від @Raynos начебто підтверджує те, що я думаю, і посилання від коментаторів забезпечили гарну їжу для роздумів, але я хочу дізнатися, чи є ще хто-небудь відповіді, характерні для Вузла, як-от "НЕ ВИКОРИСТОВУЙТЕ НАЗВУ ПРОБЛЕМУ X" '. (Окрім завдань з високим процесором; я знаю, що вже :-)

чи є якісь вагомі причини уникати Node.js для традиційних веб-додатків

Так, якщо у вас N років на веб-платформі X, то однозначно ви можете швидше розробляти додаток на платформі X.

Якщо ви хочете зробити Y, і платформа X має заздалегідь зроблене рішення Y, яке робить X, то зробіть це.

Усі загальні причини, чому ви повинні використовувати одну платформу над іншою.

набір програм CRUD, які ви створюєте для внутрішніх бізнес-додатків?

Так, є й інша платформа, яка дозволяє швидше писати загальну програму, на розум приходить рубін на рейках.

Однак це сказано. У мене є досвід роботи з вузлом і не можу стверджувати, що я б обрав іншу платформу над вузлом, якщо це не зробить для мене величезну кількість функцій.

В основному це просте питання

Чи існує інструмент, який робить все це для мене? Ні, тоді виберіть найбільш зручну платформу для написання інструменту.

Немає жодних вагомих причин, чому node.js - незручна платформа (інакше "я ненавиджу JavaScript")

Попрацювавши з вузлом кілька тижнів, я б сказав, так, це дуже круто. Але це не обов'язково те, що ви хочете використати для заміни своїх веб-додатків, що працюють на верстаті, на ... а також, іммо, це не повинно бути.

Пам'ятайте, вузол - це власний сервер. Це створює складності, якщо ви хочете запустити більше, ніж просто один додаток node.js. тобто, якщо у вас на сайті розміщено більше одного сайту / домену. Це не так, як стек LAMP, де ви можете мати десяток додатків PHP для півдесятка різних доменів, що працюють з одного сервера (як мінімум на порту 80). Існують рамки для вузла, які, ймовірно, роблять це можливим, але це додає складності, яка вам просто не потрібна, якщо ви дотримуєтесь традиційних веб-платформ. (Звичайно, ви також можете налаштувати проксі-сервери, поставивши веб-сервер перед вузлом, але такий вид перешкоджає перевазі використання вузла).

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

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

Це бізнес та конкретно людський капітал, тобто програмісти, які це знають, скільки вони коштують та їх доступність. Навчитися це не так складно, але як і будь-яка новіша технологія, кількість людей, які добре її знають (або хочуть), це найменший з більших пулів працівників.

Це дуже гарне запитання, яке ми мусимо задати, аби надто просунути сучасний стан.

Мені було дуже цікаво дізнатись (як Paul d'Aoust), де існують обмеження Node.JS. На жаль, багато відповідей ПОВНІ суб'єктивні упередження та тимчасово актуальне обгрунтування.

Я запитав себе: чи можемо ми відфільтрувати суб’єктивні біоси та піти до твердих відповідей на це відповідне запитання?

Залишилися інші пункти:

1. NodeJS не настільки зрілий, як традиційні рамки. Як пропонує Пол д'Ауст, це лише тимчасово важлива причина, а не для повного уникнення - а натомість перегляд та належна ретельність. Виконання домашніх завдань як веб-професіоналів очікується, і наша робота - визначити якнайкраще підходити технології до організації, їх потреб, їхнього майбутнього, команди (а не нас). Зрілість - це потреба в уточненні та оцінці позиви щодо ризику, але не уникнення.

2. NodeJS як проксі-сервер. Мудра пропозиція попереднього обговорення, яку варто переглянути і розглянути. Це поняття використання Node у співвідношенні з існуючими технологіями в якості схеми розробки проксі-інтерфейсу інтерфейсу. Але також це не привід уникнути використання вузла, а натомість не уникати використання його як повної заміни. Замість того, щоб вибрати наступний підхід.

3. Налагодження вузла. У розмові з розробниками основних вузлів Joyent є багато ускладнень, пов’язаних з налагодженням і відстеженням першопричини проблем, що виникають в основі ядра (на основі виконання одного потоку та неможливості проникнути в минулі потоки). Це варто врахувати та оцінити, але (знову ж таки), швидше за все, це не буде відразом до загального використання лише крайових справ, які можуть підштовхнути конверт. Можливо, ваші конкретні потреби потраплять до цієї категорії, а може, і не будуть.

4. Людські ресурси. Це найкращий привід уникнути використання JS на цій сторінці, і на мою скромну думку, це надзвичайна і незручна правда. Постає питання: чи має у вашій компанії потрібні талановиті професіонали, щоб бачити проект протягом повного життєвого циклу? Якщо ні, то немає жодного питання, що вам потрібно уникати NodeJS. Або замість цього розгляньте A) пошук правильного таланту, або B) Виховання існуючого таланту.

Скарги: Моє спостереження за скаргами на JavaScript полягає в тому, що багато хто більше призводить до помилок користувача, ніж від постійних недоліків мови. Ми скасували багато претензій до "Ненависного JavaScript Діатриби", і ми продовжимо розвінчати ще багато. Такі проблеми, як - документація недостатньо хороша, вона не досить сексуальна, але людям це не подобається, це рак, це чорт, або він занадто "схильний до друку" (-CRichardson), є суб'єктивними і упереджених скарг, які необхідно відмивати для точного прийняття корпоративних рішень.

Зрештою, правильна відповідь може бути - немає жодних вагомих причин для того, щоб уникнути NodeJS . Можливо, саме тому він відчуває швидке зростання, прийняття та внесок. Але для всіх нас, можливо, відповідь тут - продовжувати оцінювати, досліджувати та розуміти NodeJS краще - і шукати конкретні відрази. Прагнучи бути відкритими для розуміння того, де саме Node.JS незрілий - ми знаходимо саме там, де нам потрібно зробити це краще. І це благо.

Гарне питання. Я для когось цікавий, щоб хтось виховував кращу причину уникати NodeJS - ніж ці.

Чи є якась користь від використання вузла над X для додатків у режимі реального часу:

• Масштабування : Вузол має хороші показники, але це роблять і інші платформи; 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.js - дуже популярна платформа, і вона має багато цікавих особливостей, бла-бла-бла, але використання інструменту є особистим уподобанням. Я давав Node.js чотири рази, і я не був задоволений цим. Ось мої причини. Зверніть увагу, що деякі з цих причин застаріли або просто особисті: P

• Я віддав перевагу іншій мові / синтаксису (мені подобається Python, Scala, моя улюблена мова - Prolog, так, так).
• Якість документації для фреймворків та бібліотек, які я використовував, не така хороша для бібліотек Java, Scala, Python.
• Дизайнери вузлів досить одержимі зворотними дзвінками замість моделі подій, спостерігача або ф'ючерсу.
• Є готові рішення для того, що я хочу зробити в Ruby, Python, Java, розробленому ще в 2005 році, мені просто потрібно редагувати файл конфігурації.

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

Однак, вузол краще підходить для певного типу архітектури додатків. PHP - HTML-файли, що містять трохи коду. Вузол - це код, необов'язково містить трохи html.

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

Якщо у вас багато сценаріїв на стороні клієнта і зберігаєте дані за допомогою ajax, ви отримуєте статичні функції виклику клієнтів у форматі html на сервері. Це саме те, у чому хороший вузол. Хоча зазвичай не будуються програми CRUD, ви можете створити щось досить приємне за допомогою правильних рамок.