私は現在、DerbyJSを使用しています。これは、クリーンで DRY なクライアント/サーバー コードを促進するためです。副次的な利点 (ほとんどの人がフレームワークを使用する主な理由) は、Socket.IO を使用してリアルタイム アプリを作成することです。この場合、リアルタイムは必要ありませんが、便利な機能です。
私の質問は、Socket.IO を使用することでスケーラビリティ/パフォーマンスを犠牲にしているか、それが維持するすべてのオープン接続ですか? 開いている接続がないため、Backbone + ExpressJS を使用するとリソースが解放されますか?
多数のオープンな接続を維持すると、明らかにサーバーのオーバーヘッドの点でコストがかかりますが、明らかなスケーリングの問題がない限り、このような懸念について心配する必要はありません。明らかなスケーリングの問題が発生したら、より多くのサーバー リソースを購入するのに十分な収入が得られるはずです。サーバーは非常に安価で、時間は非常に高価です。小さなものを最適化することについて心配する必要はありません。
Socket.IO を使用してスケーラビリティ/パフォーマンスを犠牲にしているのでしょうか。
新しい情報が利用可能になったらすぐにページ（動的ページ）を更新したい場合。次に、非ブロッキング io を使用して接続を開いたままにしておくことが、これを行う最も効率的な方法です。幸いなことに、node.js はノンブロッキング io を使用します。これが、node.js が非常に人気がある理由の 1 つです (さらに、最も人気のあるプログラミング言語である JavaScript でコーディングできることも理由の 1 つです)。あなたのウェブサイトがかなり静的である（あなたが言ったようにリアルタイムではない）ために本当に必要ない場合（将来的にも）、接続を閉じるとリソースが節約されます。
開いている接続がないため、Backbone + ExpressJS を使用するとリソースが解放されますか?
バックボーン/エクスプレスの組み合わせとderbyjsを使用してWebサイトを開発するためのコスト（開発時間）を調べます。
次に、ネイトが言及したように、Socket.ioは多くの（1000以上）同時接続を簡単に処理できます。derbyJS を使用して開発する方が簡単な場合は、それを使用します。その道を渡ると、いつでもサーバーを追加したり、ウェブサイトを再設計 (追加のプログラマーを雇うことができます) して、エクスプレス/バックボーンの組み合わせを使用することができます。最初に、最小限の労力 (開発時間) で、ユーザーがあなたの Web サイトを価値あるものと感じるようになるようにしてください。
PS: Derby.js を他のものに置き換える作業を最小限の時間で行えるように、システムを可能な限りモジュール化するように努めるべきだと思います。