Hacker News Reader

Comment by samwillis | Hacker News Reader

It seems to me that the hype around Web Sockets has overshadowed the Server Sent Events API (http://dev.w3.org/html5/eventsource/) which for most situations where you don't need a continues stream of data is a more sensible system. It is purely a message sending system by design.

The really nice thing about SSE is that you can fall back to long polling very easily with exactly the same back end and as it runs over vanilla http without the upgrade protocol system is much easer to implement, you just don't close the connection after sending a message. Obviously its only one way but we have a well established way of sending messages in the other direction with http POST.

View on HN

Of course, the limitation of SSE is that it's not bidirectional - as the name implies, only the server can send messages to the client. SSE is definitely useful, especially when you don't need the full overhead of a WebSockets server, but the "hype around WebSockets" is largely because you can implement two-way connections with it. Yesterday there was actually a HN post where someone created a full TCP proxy using WebSockets.

I completely agree that WebSockets are a very good innovation and have their place but I do think that there are a lot of situations where you can achieve the same result easer with SSE and using a HTTP PUT to send messages back to the server.

For example a collaborative project management tool like Asana where saves are silent and update live on other peoples screens is a better place for SSE and a REST api than WebSockets, where as a real time game is probably a good place to the latter.

The TCP proxy use case, which has been my primary motivation for WebSocket since day one, points to another limitation of SSE. SSE cannot handle binary data without encoding the data into text. WebSocket can.

Agree, Server Sent Events is an incredibly simple API, has none of the problems with proxies, security and complexity that websockets has run into and is perfect for the typical case where Ajax is fine for sending events to the server, but you need a way to stream events in the other direction.

I just launched the beta of a small service for making Server Sent Events painless at http://eventsourcehq.com

It's currently only available for members of Heroku's beta program, but I plan on launching it as a stand alone service as well. In any case all the code behind it available on Github...

Which browsers have implemented SSE/EventSource?

All except IE and Android, as usual.

http://www.caniuse.com/#search=eventsource

However, since SSE is HTTP-compatible you can easily implement fallback for these, e.g.

https://github.com/Yaffle/EventSource

Wow, I seem to have missed the boat on caniuse.com =)

Thanks for the info, everyone.

http://caniuse.com/#search=eventsource

Firefox, Chrome, Safari and Opera all have it. I believe IE10 will have it but I cant find a reference right now.

This seems to be the nicest shim to let you use EventSource on older browsers https://github.com/Yaffle/EventSource, I did make something similar myself but this is much more complete.

Chrome 13+, Firefox 6+, Safari 5+, Opera 11+. No IE support on the horizon, though.

http://caniuse.com/#feat=eventsource

Reply on news.ycombinator.com