Hacker News Reader

Comment by untog | Hacker News Reader

I do web dev for a living and I'm slightly embarrassed that this is the first time I've heard of the EventSource API. Why would I use it over Websockets, though? It appears that it does the same thing - keeps an HTTP connection open - but without the ability for the client to send anything back.

View on HN

I wouldn't, EventSource isn't supported by IE yet[0].

[0] http://caniuse.com/#search=EventSource

I've been using this polyfill for years in production with success: https://github.com/Yaffle/EventSource

My favorite thing about EventSource/ServerSentEvents is that reconnection is handled for you by the browser. EventSource also works over straight HTTP without need to renegotiate the protocol, which is nice for hosts that don't support WebSockets.

I can think of many scenarios where the client needn't send anything back, notifications being an immediate example; I haven't dabbled with either, but I imagine reasoning about EventSource is probably a little bit easier than WebSockets.

I used it for notifications once and it was really nice, as well as trivial to implement on the server side. I think that it can be thrown in to basically any server is a big selling point.

In this particular case this is exactly what I need - to send server generated events with no way to talk back :) I just use the right tool for the right thing here

It handles a lot of the details if what you want is to get a stream of asynchronous events. You can certainly implement an equivalent on top of websockets, but the same is true of any protocol, including HTTP itself.

Reply on news.ycombinator.com