undefined | Better HN

0 pointskreetx4y ago0 comments

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.

0 comments

coder5434y ago

> 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/2 implementation in your browser or the library you use, this just not a real concern. HTTP/2 has been around long enough that this is definitely not a concern of mine. I would be more worried about bugs with HTTP/3, since it is so new.

Websockets are also not especially easy to set up… they don’t work with normal HTTP servers and proxies, so you have to set up other infrastructure.

kreetxOP4y ago

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)

j / k navigate · click thread line to collapse