3 ms·
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
by untog 11y ago
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.
- grandrew 11y agoIn 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
- drhayes9 11y agoMy 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.
- TN1ck 11y agoI wouldn't, EventSource isn't supported by IE yet[0]. [0] http://caniuse.com/#search=EventSource http://caniuse.com/#search=EventSource
- adrianpike 11y agoI've been using this polyfill for years in production with success: https://github.com/Yaffle/EventSource https://github.com/Yaffle/EventSource
- dclowd9901 11y agoI 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.
- PeCaN 11y agoI 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.
- wiml 11y agoIt 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.