Should a single-page web application keep one Web Socket connection to the server or several?

Question

I'm working on a single page Backbone application that is going to use web sockets. The application is fairly complex, with 6 or more major areas (screens).

The syntax of web sockets seems straightforward enough and I'm wondering now about the architecture.

When using web sockets, is it most performant to take the first approach or the 2nd approach?

1: Open a single websocket for all live server communication, on any screen or area of the application, and then filter those messages on the client side?

or...

2: Open multiple websockets at a time, where each web socket represents some area of functionality in the application

(I've seen this page, but it's about the server side and I'm interested in the client side: What is the best practice for WebSocket server(s)?)

Update: server is using Jetty (a Java technology not unlike Tomcat).

Answer 1

I would open only one connection, easier to manage. To ease debugging you could namespace all your events with the area name. Also socket.io supports namespaces, see section "Restricting yourself to a namespace" here http://socket.io/#how-to-use.

Also if your doing lot of communications with your websocket you can turn it off with the Visibility API, example here: https://developer.mozilla.org/en-US/docs/DOM/Using_the_Page_Visibility_API