非リアルタイムWebアプリのnode.jsを避ける正当な理由はありますか？

Node.jsがリアルタイムWebアプリにどれほど優れているか、ソケット、Comet、AJAXの重い通信などを必要とするものについて、多くの話を見てきました。イベント駆動、非同期、スレッド駆動のモデルは、オーバーヘッドの少ない同時実行にも適していることを知っています。

また、Node.jsのチュートリアルでは、より単純で「伝統的な」非リアルタイムアプリ（たとえば、アプリ開発を学ぶ人にとって標準的な「Hello World」と思われる標準的なブログの例）を見ました。また、node-staticを使用すると、静的アセットを提供できることも知っています。

私の質問は次のとおりです。クラシファイド、フォーラム、前述のブログの例、または社内ビジネスアプリケーション用に作成するCRUDアプリなど、従来のWebアプリでNode.jsを使用しない理由はありますか。ファンキーなリアルタイムのものに優れているからといって、より安定した使用を禁じているのでしょうか？

私が考えることができるのは、最初のうちは、成熟したライブラリの不足です（ただし、変化しています）。

（私が求めている理由は、ほとんどの言語の切り替えのインピーダンス不整合を乗り越えるために、私はNode.jsのためにPHPを捨てる検討しているということですが、また、私は検証コードやその他もろもろを再利用することができるように。私の超自我のために私を訓戒選びます仕事に最適なツールですが、包括的な兵器庫を得るために15の言語とそのすべてのユーザーランドライブラリを学ぶ時間はあまりありません。また、Node.jsがPHP /将来的には、大量のトラフィックについて考え始めなければならないApache。

[編集]これまでの回答に感謝します。答えを選択する前に、他の誰かが体重を測定するかどうかを見たいだけです。@Raynosからの回答は私が考えていることを確認し、コメンターからのリンクは思考のための良い食べ物を提供しましたが、「ノードXを問題に使用しないでください」など、ノード固有の回答があるかどうかを確認したいです'。（CPUの高いタスクに加えて、私はすでにそれを知っています:-)

従来のWebアプリのNode.jsを避ける正当な理由はありますか

はい、WebプラットフォームXでN年間を使用している場合、プラットフォームXでアプリケーションをより迅速に開発できます。

Yを実行したい場合、プラットフォームXにはXを実行する既成のソリューションYがあります。

あるプラットフォームを別のプラットフォームよりも使用する理由のすべての一般的な理由。

内部ビジネスアプリケーション用に作成するCRUDアプリのようなものですか？

はい、汎用アプリケーションをより速く書くことができる他のプラットフォームがあります。Rubyon Railsが思い浮かびます。

しかし、それは言った。私はノードの経験があり、ノードの代わりに大量の機能を実行しない限り、ノードよりも別のプラットフォームを選択すると主張することはできません。

基本的にそれはの単純な質問です

これをすべて行うツールが存在しますか？いいえ、ツールを作成するのに最も便利なプラットフォームを選択してください。

node.jsが不便なプラットフォームである理由はありません（「iはJavaScriptが嫌い」）

ノードで数週間作業した後、私はイエスと言います、それはとてもクールです。ただし、従来のWebアプリを置き換えるために使用するものである必要はありません。

ノードは独自のサーバーです。これは、node.jsアプリケーションを1つ以上実行したい場合に複雑さをもたらします。つまり、マシンでホストされているサイト/ドメインが複数ある場合。LAMPスタックとは異なり、同じサーバー（少なくともポート80）で実行されている、半ダースの異なるドメイン用のダースPHPアプリケーションを使用できます。おそらくそれを可能にするノード用のフレームワークがありますが、それは従来のWebプラットフォームにこだわる場合に必要な複雑さを追加するだけです。（もちろん、Webサーバーをノードの前に置くことでプロキシを設定することもできますが、そのようなことはノードを使用する利点を無効にします）。

imo、Nodeは従来のWebサーバーと連携して動作するのに最適です。私が今整理している方法は、Apache経由で静的html / js / imagesを提供し、ノードアプリケーションへの長いポーリングによって「リアルタイム」データニーズを処理することです。

ノードについて数秒考えることは技術的ではありません-それが何をするかで素晴らしいと驚くべきです。

彼らはビジネスであり、特に人的資本です。つまり、それを知っているプログラマー、彼らがどれだけの費用と彼らのアベイラビリティです。学ぶことはそれほど難しくありませんが、新しいテクノロジーと同様に、それをよく知っている（または知りたい）人々の数は、より大きな労働者のプールの最下位です。

これは非常に良い質問であり、最新技術を進歩させるために私たちは尋ねなければなりません。

Node.JSの限界がどこにあるのか（Paul d'Aoustなど）を知りたいと思いました。悲しいことに、多くの答えは主観的な偏見と一時的に関連する根拠に満ちています。

私は自問しました：主観的なバイアスを除外し、この関連する質問に対する明確な回答を得ることができますか？

残りのポイントは次のようです：

1. NodeJSは、従来のフレームワークほど成熟していません。Paul d'Aoustが示唆しているように、これは一時的に関連する理由であり、完全に回避するためではなく、レビューとデューデリジェンスです。Webの専門家として宿題をすることが期待されており、組織、ニーズ、将来、チーム（そして私たちではない）に最適なテクノロジーを決定するのが私たちの仕事です。成熟度は、明確化の必要性とリスクへの欲求の判断ですが、回避ではありません。

2.プロキシサーバーとしてのNodeJS。事前の議論の賢明な提案は、検討と検討に値します。これは、フロントエンドインターフェイスプロキシデザインパターンとして、既存のテクノロジと相関してNodeを使用するという概念です。しかし、それはノードを使用することを避ける理由ではなく、代わりに完全な代替として使用することを避ける理由です。代わりに、結果的なアプローチを選択します。

3.デバッグノード。Joyentのコアノード開発者との会話では、デバッグ可能性と、コアに起因する問題の根本原因の追跡（シングルスレッドの実行と過去のスレッドを確認できないことに基づく）を取り巻く問題が多くあります。これは検討および評価する価値がありますが、（再び）一般的な使用法では、エンベロープをプッシュする可能性のあるエッジケースのみを嫌うことはないでしょう。特定のニーズがこのカテゴリに分類される場合もあれば、そうでない場合もあります。

4.人事。これが、このページでJSを使用することを避ける一番の理由です。私の謙虚な意見では、これは厳しく不便な真実です。それは疑問を投げかけます：あなたの会社には、ライフサイクル全体を通してプロジェクトを見るために、適切な才能のある専門家がいますか？そうでない場合、NodeJSを避ける​​必要があることは間違いありません。または、代わりにA）正しい才能を見つけるか、B）既存の才能を教育することを検討してください。

苦情： JavaScriptに関する苦情の私の観察では、多くの場合、言語の一貫した失敗からよりも、ユーザーエラーからより多くの結果が生じます。私たちは「The Hate JavaScript Diatribe」に対する多くの主張を暴きました。そして、さらに多くのことを暴き続けます。次のような問題-ドキュメンテーションは十分ではない、それはセクシーではないが、人々はそれを好きではない、それは癌である、それは悪魔である、またはそれはあまりに「タイプミス」（-CRichardson）であり、主観的であり、正確な企業の意思決定のために排除する必要がある偏った苦情。

最終的に、正解は-AVOID NodeJSに正当な理由はありません。たぶん、これが急速な成長、採用、貢献を経験している理由です。しかし、おそらくここでの答えは、NodeJSの評価、調査、理解を続け、具体的な嫌悪感を探すことです。Node.JSが未熟な場所を正確に理解することにオープンであることを追求するために、それを改善する必要がある場所を正確に見つけます。そしてそれは祝福です。

良い質問。私は誰かがNodeJSを避ける​​ためのより良い理由を持ち出すことに興味があります-これらよりも。

非リアルタイムアプリケーションでXよりもノードを使用する利点はありますか？

• スケーリング：ノードのパフォーマンスは良好ですが、他のプラットフォームも同様です。PHP、Ruby、Python、およびJavaはすべて拡張可能です。何百万人ものユーザーが使用している大きな名前を見つけることができます。
• フロントエンドとバックエンド用の1つの言語：これは冗談です。Javaの「どこでも一度実行すれば書き込み」のように
• ホットでセクシー：唯一の有効なポイント。しかし、あなたのウェブサイトがエッジの効いた技術を使用していることに誰も気にしません！

非リアルタイムアプリケーションにX over Nodeを使用する利点：

• ベストプラクティス：Nodeは新しいため、特にCRUD Webアプリケーションの場合、他のプラットフォームよりもベストプラクティスが少なくなっています。
• Javascript言語：人々はJavascriptが好きではありません。Node.jsはホットですが、Javascriptはホットではありません。これが、クライアント側でもJavascriptを記述しないように人々がCoffeescriptを作成した理由です。
• 開発速度：RailsやDjangoを含むがそれらに限定されない、古くて退屈なフレームワークは、CRUD Webサイトで長年にわたって十分にテストされ、改善されています。Nodeで同様のアプリケーションを実装できますが、おじいちゃんのフレームワークで行う方が簡単です。
• 安定性：NodeのWebフレームワークはより速いペースで改善されています。それは、それらが変化しており、近い将来により多くのAPIの非互換性があることを意味します。
• ライブラリとツール：より多くのユーザーを持つ古いテクノロジーには、より多くのライブラリとツールがあります。

私の答えは2015年には間違いなく無効になります。2014年には、非リアルタイムWebアプリケーションのNodeをスキップしますが、注意してください。

すべてのWebフレームワークには長所があります。その点で使用している間、あなたは幸せになるでしょう。非リアルタイムWebアプリケーションは、NodeのWebフレームワークの長所ではありません。

Node.jsは非常に人気のあるプラットフォームであり、多くの興味深い機能がありますが、ツールの使用は個人的な好みです。Node.jsを4回提供しましたが、満足できませんでした。ここに私の理由があります。これらの理由のいくつかは時代遅れ、または単に個人的なものであることに留意してください：P

• 私は別の言語/構文を好みました（Python、Scalaが好きで、私のお気に入りの言語はPrologですので）。
• 私が使用したフレームワークとライブラリのドキュメントの品質は、Java、Scala、Pythonライブラリほど良くありません。
• nodejsのデザイナーは、イベントモデル、オブザーバー、フューチャーの代わりにコールバックに非常に夢中です。
• 2005年に開発されたRuby、Python、Javaでやりたいことにはすぐに解決策があります。設定ファイルを編集するだけです。

HTTPはステートレスであるため、実際には非リアルタイムWebアプリのようなものは存在しないため、すべてにノードを使用できない理由はありません。

ただし、ノードは特定のタイプのアプリケーションアーキテクチャにより適しています。PHPは、少しのコードを含むHTMLファイルです。ノードは、オプションで少しのHTMLを含むコードです。

これは、アプリがクライアント側スクリプトのない標準のhtmlフォームである場合、PHPがより簡単になることを意味します。Nodeにはテンプレートツールがありますが、明らかにPHPのようなものほど成熟していません。

クライアント側のスクリプトがたくさんあり、データをajaxで保存すると、サーバー上の関数を呼び出す静的なHTMLクライアントになります。これはまさにノードが得意とするものです。CRUDアプリの通常のビルド方法ではありませんが、適切なフレームワークを使用すると、かなり素晴らしいものを作成できます。