Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

Post reply on HN
Print view View original

261–266 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#261

Post by tekknik »

szastamasta wrote: post #33

My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better. Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.

> Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.

You can also implement websockets in 5 lines (less, really 1-3 for a basic implementation) without socket.ii. Why are you still using it?

Re: Server-Sent Events: an alternative to WebSockets

#262

Post by tekknik »

pier25 wrote: post #232
szastamasta wrote: post #33

My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better. Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.

WebSockets are also quite unreliable but Socket IO hides all this from you.

socket.io doesn’t do as much as the bloat warrants. implementing the same features (heartbeats and reconnects) takes minimal code. socket.io was useful when certain browsers didn’t support websockets, now it’s used mostly by people scared of sockets imo

Re: Server-Sent Events: an alternative to WebSockets

#263

Post by tekknik »

szastamasta wrote: post #83
jFriedensreich wrote: post #50

Earlier quoted context omitted.

sounds like you did not really evaluate both technologies at the heart but only some libraries on top?

Yeah, sorry. In socket.io it’s 2 lines. You need 5 lines with browser APIs :). You simply get stuff like auto-reconnect and graceful failover to long polling for free when using socket.io

2 lines vs 5 lines. did you check your payload size after adding socket.io? you added way more than 2 lines.

long polling shouldn’t be needed anymore, and auto reconnect is trivial to implement.

Re: Server-Sent Events: an alternative to WebSockets

#264

Post by kreetx »

coder543 wrote: post #251
kreetx wrote: post #250

Earlier quoted context omitted.

Right, but this article argues that SSE is simple and easy to debug on the wire - so is http1. Http2 is easy to set up, so are websockets, yet debugging the multiplexed http2 stream is is not that simple anymore. The SSE connection limit is a nasty surprise once you run into it, it should have been mentioned.

> The SSE connection limit is a nasty surprise once you run into it, it should have been mentioned. It does not apply to HTTP/2, as previously noted. > Http2 is easy to set up, so are websockets, yet debugging the multiplexed http2 stream is is not that simple anymore. I have literally never heard of anyone I personally know having to debug HTTP/2 on the wire. Unless you believe there are frequently bugs in the HTTP/…

Which web servers do they not work with? They have worked everything I've used thus far (which admittedly aren't many): nginx, warp (Haskell's embedded server), relayd (OpenBSD), all with easy setup.

It also seems that compression for websockets is supported in all major browsers.

The article's argument seems to be that ws adds complexity, but this is present in pretty much all web servers already, the user needs not to deal with it. (HTTP2, too, requires the same type of complexity for that matter)

Re: Server-Sent Events: an alternative to WebSockets

#265

Post by belter »

lelanthran wrote: post #234
bullen wrote: post #200

Earlier quoted context omitted.

The data is here: http://fuse.rupy.se/about.html Under Performance. Per watt the fuse/rupy platform completely crushes all competition for real-time action MMOs because of 2 reasons: - Event driven protocol design, averages at about 4 messages/player/second (means you cannot do spraying or headshots f.ex. which is another feature in my game design opinion). - Java's memory model with atomic concurrency parallelism ov…

> - Java's memory model with atomic concurrency parallelism over shared memory which needs a VM and GC to work Do you have a link that explains this bit?

I think this one helps: https://travisdowns.github.io/blog/2020/07/06/concurrency-co...
Post reply on HN