非リアルタイムWebアプリでnode.jsを使用しないことには十分な理由がありますか？
ソケット、Comet、AJAXを多用した通信などを必要とするリアルタイムのWebアプリに対するNode.jsの素晴らしさについて多くの話をしてきました。イベント駆動型の非同期スレッド駆動型モデルは、オーバーヘッドの少ない並行処理にも適していることを知っています。
私はまた、よりシンプルで「伝統的な」非リアルタイムアプリのNode.jsチュートリアルを見てきました（たとえば、アプリ開発を学ぶ人にとっては標準の「Hello World」のように見える標準のブログの例）。また、node-staticを使用すると、静的なアセットを提供できることも知っています。
私の質問は：クラシファイド、フォーラム、前述のブログの例、または作成するCRUDアプリの種類など、従来のWebアプリのNode.jsをavoidする理由はありますか？内部のビジネスアプリケーション？ファンキーなリアルタイムのものに優れているからといって、それはより安定した使用に禁忌ですか？
私が考えることができる唯一のことは、最初から、成熟したライブラリの欠如です（それは変わりつつあります）。
（私が尋ねている理由は、Node.jsのディッチングPHPを検討していることです。ほとんどの場合、言語間の切り替えのインピーダンスの不一致を克服するためですが、検証コードを再利用して、私のスーパーエゴは、私に 仕事に最適なツールを選択する を勧めていますが、15の言語とそのすべてのユーザーランドライブラリを学ぶだけの時間はありません。また、大量のトラフィックについて考え始める必要がある場合、Node.jsが将来的にPHP/Apacheよりも簡単な最適化パスを提供する可能性があることも確信しています。）
[編集]これまでの回答に感謝します。答えを選ぶ前に、他の誰かが検討するかどうかを確認したいだけです。 @Raynosからの回答は、私が何を考えているかを確認し、コメント投稿者からのリンクは、考えにふさわしい食べ物を提供しましたが、他の誰かがノード固有の回答を持っているかどうかを確認したいと思います。 '。 （ハイCPUタスク以外に、私はすでにそれを知っています:-)
従来のウェブアプリでNode.jsを使用しない理由はありますか
はい、WebプラットフォームXでN年の経験がある場合は、プラットフォームXでアプリケーションをより速く開発できます。
Yを実行する場合、プラットフォームXにXを実行する既成のソリューションYがあれば、それを実行します。
あるプラットフォームを別のプラットフォームで使用する必要があるすべての一般的な理由。
内部ビジネスアプリケーション用に作成するCRUDアプリの種類は？
はい、一般的なアプリケーションをより速く記述できる他のプラットフォームがあります。Ruby on Railsが思い浮かびます。
しかし、それは言った。私はノードの経験があり、すぐに使える大量の機能がない限り、ノードではなく別のプラットフォームを選択するとは言えません。
基本的にそれはの簡単な質問です
これをすべて行うツールはありますか？いいえ、ツールを作成するのに最も便利なプラットフォームを選択してください。
Node.jsが不便なプラットフォームであるという明確な理由はありません（「JavaScriptが嫌い」以外の場合）
数週間ノードを操作した後、私はそう言うでしょう、それはとてもクールです。しかし、必ずしも、ありふれたWebアプリを置き換えるために使用したいものではありません。
ノードは独自のサーバーであることを忘れないでください。これは、1つのnode.jsアプリケーションだけでなく、それ以外のものも実行したい場合に複雑さをもたらします。つまり、1つのマシンで複数のサイト/ドメインをホストしている場合です。これは、LAMPスタックとは異なり、同じサーバーで（少なくともポート80で）実行されている6種類以上の異なるドメインのダースPHPアプリケーションを持つことができます。）ノード用のフレームワークがあります。おそらくそれは可能になりますが、従来のWebプラットフォームにこだわっている場合には必要のない複雑さを追加します（もちろん、ノードの前にWebサーバーを置くことでプロキシを設定することもできますが、そのような利点は無効になりますノードを使用する方法）。
imo、Nodeは作業に最適ですと組み合わせて従来のWebサーバーです。私が現在整理している方法は、静的なhtml/js/imagesを介して提供することですApache、そしてノードアプリケーションへの長いポーリングによって「リアルタイム」のデータニーズを処理します。
これは非常に良い質問であり、最先端の技術を進歩させるためにも、私たちは尋ねなければなりません。
Node.JSの制限がどこにあるのか（Paul d'Aoustのように）知りたくてとても興味深かったです。悲しいことに、多くの回答は主観的なバイアスと一時的に関連する根拠でいっぱいです。
私は自分自身に尋ねました：CAN WE主観的バイアスを除外し、SOLIDこの関連する質問への回答？
残りのポイントは次のようです：
1。NodeJSは従来のフレームワークほど成熟していません。 Paul d'Aoustが示唆するように、これは一時的に関連する理由であり、完全な回避のためではありませんが、レビューとデューデリジェンスです。ウェブプロフェッショナルとして宿題を行うことが期待されており、組織、ニーズ、将来、チーム（そして私たちではない）に対するテクノロジーの最適性を判断することが私たちの仕事です。成熟度は、リスクの明確化と食欲の判断の必要性ですが、回避ではありません。
2。NodeJSをプロキシサーバーとして使用。以前のディスカッションの賢明な提案であり、検討および検討する価値があります。これは、Nodeを既存の技術との関連でフロントエンドインターフェイスプロキシの設計パターンとして使用するという概念です。また、ノードを使用しない理由ではなく、回避する理由です。完全な代替品として使用する代わりに、当然のアプローチを選択します。
。デバッグノード。コアとの対話Node Joyentの開発者は、デバッグ可能性と、コアに起因する問題の根本原因を追跡することに関連する多くの複雑さがあります（シングルスレッドの実行と過去のスレッドを確認できないこと。これは検討と評価に値しますが、（繰り返しますが）一般的な使用法を嫌うのではなく、限界を押し上げる可能性のあるEdgeケースのみです。特定のニーズはおそらくこのカテゴリに分類され、彼らはしません。
4。人事。これが、このページでJSを使用しない理由の1つであり、控えめな見解では、それは厳格で不便な真実です。それは質問をします：あなたの会社は完全なライフサイクルを通してプロジェクトを見るために適切な有能な専門家を手元に持っていますか？そうでないなら、それは質問ではありませんNodeJSを回避する必要があります。または代わりに、A）正しい才能を見つけること、またはB）既存の才能を教育することを検討してください。
苦情：JavaScriptでの苦情の私の観察は、言語の一貫した失敗よりもユーザーエラーからより多くの結果が得られるということです「ヘイトJavaScriptダイアトリブ」に対する多くの主張を非難し、今後もさらに非難します。このような問題-ドキュメンテーションは十分ではない、それは十分にセクシーではないが、人々はそれが好きではない、それは癌である、それは悪魔である、またはそれはあまりにも「誤植が多い」（-CRichardson）、主観的であり、正確な企業の意思決定のために除外する必要がある偏った苦情。
結局、正しい答えは-かもしれません。NodeJSを回避する正当な理由はありません。たぶんこれが、急速な成長、採用、そして貢献を経験している理由です。しかし、私たち全員にとっておそらくここでの答えは、NodeJSの評価、調査、理解を継続し、具体的な嫌悪感を探すことです。 Node.JSが未成熟な場所を正確に理解できるようにすることを目指して、改善の必要な場所を正確に見つけます。そしてそれは祝福です。
良い質問。私は、NodeJSを回避するためのより良い理由を誰かが持ち出すのに興味を持っています-これらよりも。
ノードについて数秒で考えるのは技術的なことではありません-それはそれが何をするのかについて素晴らしいと驚くべきことです。
彼らはビジネスであり、特に人的資本です。つまり、それを知っているプログラマー、どれだけの費用がかかり、可用性があるかです。学ぶことはそれほど難しくありませんが、新しいテクノロジーと同様に、それをよく知っている（またはしたい）人々の数は、より大きな労働者のプールの一部です。