私は現在、DerbyJSと協力しています。クリーンなDRYクライアント/サーバーコードを育成するからです。サイドメリット（ほとんどの人がフレームワークを使用する主要な理由）は、Socket.IOを使用してリアルタイムアプリを作成することです。この場合、私はを必要とせず、リアルタイムでが必要ですが、それは素晴らしい追加です。Socket.IO - 開いている接続に問題がありますか？
私の質問は、Socket.IOを使用してスケーラビリティとパフォーマンスを犠牲にしています。 Backbone + ExpressJSを使用すると、開いている接続がないのでリソースを解放しますか？
明らかに開いている接続の束を維持することは明らかにサーバーのオーバーヘッドの面でコストがかかりますが、明らかなスケーリングの問題がなければ、このような懸念は心配しません。明らかにスケーリングの問題が発生したら、サーバーリソースをさらに購入するのに十分な収入があるはずです。サーバーは非常に安価であり、あなたの時間は非常に高価です。小さなものの最適化について心配しないでください。
Socket.IOを使用してスケーラビリティとパフォーマンスを犠牲にしていますが、すべて が維持しているものですか？
新しい情報が利用可能になったらすぐにページ（ダイナミックページ）を更新したい場合は、接続を開いたままにしておくと、非ブロッキングのioを使ってがこれを行う最も効率的な方法です。幸いにもnode.jsは非ブロッキングioを使用します。それがnode.jsがとても人気がある理由の1つです（さらに、最も人気のあるプログラミング言語であるJavaScriptでコード化することができます）。あなたのウェブサイトが静的（あなたの言ったようなリアルタイムではありません）であるため、実際には（将来も）必要ない場合は、接続を閉じるとリソースが節約されます。
開いている接続がないため、Backbone + ExpressJSのリソースを解放しますか？
私は、バックボーン/明示的組み合わせとderbyjsを使用してあなたのウェブサイトを開発するためのコスト（開発時間）を見ていきます。
また、Nateのように、Socket.ioは多くの（1000+）並行接続を簡単に処理できます。 derbyJSを使って開発するのが簡単なら、それを使用します。その道を横断するときは、サーバーを追加したり、エクスプレス/バックボーンの組み合わせを使用するようにウェブサイトを再設計（余分なプログラマーを雇うこともあります）することができます。最初に、ユーザーがあなたのウェブサイトを最小の努力（開発時間）で貴重なものにしているところに到達しようとします。
P.S：私はあなたが何か他のもののためにDerby.jsを交換最小の時間で行うことができるように可能な限りモジュラーとしてのあなたのシステムを維持しようとすべきだと思います。
一般的に、私はこれらは適度に良いルールだと思いますが、ビジネスで非常に支配的です。すべてのソフトウェアがビジネスコンテキストで書かれているわけではありません。 XとYは "質問しないでください"というだけのことではないので、「質問しないでください」と言っています。 –