Live data from Hacker News

A WebSocket Primer

caitiem.com

1–10 of 24 posts

Re: A WebSocket Primer

#4
It's funny that the article says "This enables server sent events" without actually referring to the HTML5 Server Sent Events API:

http://www.html5rocks.com/en/tutorials/eventsource/basics/

SSE is realtime server->client protocol that's fully compatible with HTTP and has lower handshake overhead (no Upgrade roundtrip, doesn't require HTTPS to go through proxies).

Re: A WebSocket Primer

#5
post #4

It's funny that the article says "This enables server sent events" without actually referring to the HTML5 Server Sent Events API : http://www.html5rocks.com/en/tutorials/eventsource/basics/ SSE is realtime server->client protocol that's fully compatible with HTTP and has lower handshake overhead (no Upgrade roundtrip, doesn't require HTTPS to go through proxies).

Agreed. Both approaches have their place, but I see SSE getting overlooked too often.

Re: A WebSocket Primer

#6
post #4

It's funny that the article says "This enables server sent events" without actually referring to the HTML5 Server Sent Events API : http://www.html5rocks.com/en/tutorials/eventsource/basics/ SSE is realtime server->client protocol that's fully compatible with HTTP and has lower handshake overhead (no Upgrade roundtrip, doesn't require HTTPS to go through proxies).

Thanks for the pointer! This seems much more straightforward than websockets.

Re: A WebSocket Primer

#8
post #7
post #2

Related: definitely check out https://github.com/sockjs

Also check out https://github.com/primus/primus It's an abstraction layer over sockjs, socket.io, etc.

Does any have experiences with Primus they can share?

The idea of being able to insulate the rest of the code from the specifics of which lower-level library I'm using is very attractive. On the other hand, any abstraction layer can introduce bugs in its own right. Thoughts about the tradeoff?

Re: A WebSocket Primer

#9
post #8
post #7

Earlier quoted context omitted.

Also check out https://github.com/primus/primus It's an abstraction layer over sockjs, socket.io, etc.

Does any have experiences with Primus they can share? The idea of being able to insulate the rest of the code from the specifics of which lower-level library I'm using is very attractive. On the other hand, any abstraction layer can introduce bugs in its own right. Thoughts about the tradeoff?

I was using socket.io until about two weeks ago when I ran into some reconnecting issues that weren't fixed. I decided to use Primus + Multiplex + Emitter. I have only run into one issue so far with Multiplex on IE10, but that was fixed quickly. Otherwise the package seems rather solid.

Re: A WebSocket Primer

#10
post #8
post #7

Earlier quoted context omitted.

Also check out https://github.com/primus/primus It's an abstraction layer over sockjs, socket.io, etc.

Does any have experiences with Primus they can share? The idea of being able to insulate the rest of the code from the specifics of which lower-level library I'm using is very attractive. On the other hand, any abstraction layer can introduce bugs in its own right. Thoughts about the tradeoff?

I'm using it now for a project that's due to go live early next year and so far it's been a dream. Case in point, I ran in to a bug on Monday and it turned out to be with engine.io itself rather than Primus. The workaround was a one line code change swapping the transformer to something else.

Arnout Kazemier (the lead dev) is a really nice guy and when I pinged him about the egine.io bug, he pushed out a change to Primus 24 hours later that worked around the bug and let me continue to use engine.io as the transformer.

YMMV but so far I've no regrets using it.

Post reply on HN