Noticed the Socket.io client side file is a hefty 78k, whereas SockJS is 9k, and engine.io is about 16k. Engine.io is to SockJS which are both nearly identical to the official websocket api.
Perhaps a benefit of using engine.io is more seamless integration with socket.io if it's desired, but if you just want to do a few messages, then you only load 16k of js, and not 78.
We now recommend BrowserChannel by default, and the connection layer has been moved to its own module so that any socket-like connection type may be used with Derby.
The fact that BrowserChannel is used in gmail is very assuring 👍
Just to get comments out of IRC onto the boards - I spoke to @josephg about this particular issue the other day, and the advantages thereof of providing native WebSocket support - I will be writing an Engine.io driver for this as soon as the API is made available.
In my particular use case, I have direct control over the client browser stack, and WebSockets provide several sizable horizontal scaling benefits (less LB drama, transit overhead, etc.) when compared to long-polling. I understand the testing with Socket.io created some problems, however, I haven't seen any issues with Engine.io
I will keep the boards posted on whether or not Engine.io performs as well as node-browserchannel, as I know there have been issues with packet ordering, offline message queueing, etc. with other libraries.