EventSource vs Websockets?

[ghost]

Just wondering the reason for using EventSource over Websockets? I have found that chrome and firefox have differing implementations of EventSource. The spec seems to have been abandoned as well.

[glenjamin]

I've generally found them to be simple & stable, work on modern browsers, and be a very lightweight dependency.

If it's causing issues I'm not averse to switching to websockets.

[ghost]

I'm trying to implement this middleware without the need for a node server. Specifically in Go, which doesn't have an adequate implementation of EventSource. Presumably because it's hardly used and the docs are nonexistent. It would be nice if it used websockets.

[glenjamin]

This lib has its own hand rolled event-stream implementation - it's very straightforward. Slim over the source - feel free to ask any questions.

The spec itself I found quite clear - the main reason I think libs aren't very good is that it's very simple to do without.

Are you re-implementing webpack in go?

[ghost]

That's true, infact it's not so much of a problem with Go itself and lack of libraries, as I've managed to get it working for the most part. The weird thing for me has been chrome acting differently than firefox. For example Chrome will detect onopen on connection/headers, however firefox does not, until I send a "building" event. It may be a problem with my implementation but I have been able to recreate the problem sporadically with the default node implementation.

And no, not webpack itself but I would like to serve reloads from my backend rather than through a middleware/webpack. Ie. Push compile events from webpack to my backend and to the client, thus not needing CORS or any fancy middleware stacks.

[glenjamin]

Going to close this, as there isn't really an action for me to take.

Feel free to ask more questions if you're still having trouble with the port.

[ghost]

Fwiw I ended up not implementing it in the way I initially planned. It's definitely better having the HMR decoupled from the backend. I was just being silly. Though I still think websockets would be a better choice :)

[kesne]

I'm having issues with SSE behind a proxy. I run my node app in a local VM behind a proxy, and for some reason it doesn't proxy the SSE requests.

Are you still not averse to switching to websockets? I realize that the issues are related to my use case and really likely to be encountered by others.

[glenjamin]

I'm still open to the idea, but if SSE is getting chewed up by the proxy, I'm not sure why websockets wouldn't.

[kesne]

I'm not 100% that it wouldn't as well. This issue seems tangentially related to the issue that I've been having: http-party/node-http-proxy#921

I'll spend this weekend playing with a fork to see if websockets also get killed.