では、イベント駆動型フレームワークの欠点はどこにあるのでしょうか。
- 親しみやすさ。イベント駆動型のWebプログラミングは非常に異なるため、プログラマーがそれに慣れるまでにはしばらく時間がかかります。締め切りに取り組んでいるときは、知っていることを使用する方が簡単です。
ライブラリのサポート。Nodeには驚くほど多くのモジュールがありますが、RubyとPythonに追いつくには長い道のりがあります。更新：Nodeには、PythonやRubyよりも多くの公開モジュールがあります。- 展開。ITスタッフは、フレームワークのスレッド化に慣れています。イベント駆動型フレームワークを利用するには、上から下への非同期が必要になります。現在、Node.jsで開発できますが、効果的にデプロイできますか、それとも独自のサーバーを管理する必要がありますか？
- 根拠のない懸念。問題のように見えますが、実際にはそうではありません。
- イベント駆動型プログラミングは、CPUを集中的に使用するアプリには適していません。その理由は、CPUを集中的に使用する計算によってサーバーがブロックされるためです。これは厳密には真実ですが、実際には、別のプロセスを生成し、たとえばノードを使用してI/Oとして処理することで克服され
child_process.execます。
- イベント駆動型プログラミングは、高い同時実行性を必要とするアプリ専用です。ここでの理由は、イベント駆動型プログラミングは従来のWebアプリプログラミングよりも「難しい」ため、正当な理由がない限り、実行する価値はありません。個人的にはそうは思わない。イベント駆動型プログラミングはこれ以上難しいことではないが、それは非常に異なっている。ある時点で、非常に多くのプログラマーがイベント駆動型アプローチに精通し、この懸念はなくなります。
- イベント駆動型プログラミングは、ネストされたコールバックの混乱です。これは、最初にそれを学んだときに当てはまるかもしれませんが、最終的には、コードを読みやすい方法で構造化する方法を発見するでしょう。
- ドキュメンテーション。Nodeとそのサードパーティライブラリのドキュメントはひどいもので、通常は。だけで構成されてい
README.mdます。優れたドキュメントに慣れているPythonの世界から来ているので、これは大きな欠点です。これは徐々に良くなっています（このようなドキュメントがもっと必要です）。
Node.jsよりもRailsを優先するのはいつですか？
- あなたやあなたのチームがJavaScriptよりもRubyを好む場合。
- あなたまたはあなたのチームがNodeに精通しておらず、仕事を終わらせる必要がある場合。
- ノードにまだないRailsにある機能を使用する必要がある場合。
- 既存のRailsベースのインフラストラクチャにデプロイする必要がある場合。
- Node.jsを使用する必要があることを経営陣に納得させる必要があるが、プロジェクトが失敗した場合に転倒したくない場合。
すべての新しいWebサーバーがEventMachine、Twisted、またはNode.jsで作成されていないのはなぜですか？
上記を参照。
DjangoやRailsとして有名なフレームワークは、イベント駆動型になるのでしょうか、それとも死ぬのでしょうか？
DjangoとRailsは長い間存在します。これらのフレームワークには多くのアプリがあり、それらを書き直す理由はありません。また、新しいWebアプリを開発する際に考慮されることが多い、大きな人材プールがあります。
（ただし、Nodeを承認しているDjangoのリード開発者からのこのQuoraの回答を参照してください）。