Consider using SockJS internally #155

devinrhode2 opened this Issue Oct 18, 2012 · 4 comments


None yet

4 participants


Noticed the client side file is a hefty 78k, whereas SockJS is 9k, and is about 16k. is to SockJS which are both nearly identical to the official websocket api.

Perhaps a benefit of using is more seamless integration with if it's desired, but if you just want to do a few messages, then you only load 16k of js, and not 78.


Totally agree

nateps commented Jun 5, 2013

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.

@nateps nateps closed this Jun 5, 2013

The fact that BrowserChannel is used in gmail is very assuring 👍

korbin commented Jun 19, 2013

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 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 created some problems, however, I haven't seen any issues with

I will keep the boards posted on whether or not performs as well as node-browserchannel, as I know there have been issues with packet ordering, offline message queueing, etc. with other libraries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment