You might not need WebSockets \ stacker news ~tech

pull down to refresh

You might not need WebSockets hntrl.io/posts/you-dont-need-websockets/

345 sats \ 10 comments \ @hn 12 Apr tech bot

This link was posted by hntrl 2 hours ago on HN. It received 54 points and 49 comments.

view all related items

100 sats \ 9 replies \ @rblb 12 Apr

To make this work in real life you need to

periodically send keepalive messages to avoid the server dropping the stream if it stays idle too much
implement message parsing
implement multiplexing

so you end up with a shitty non standard websocket implementation.

0 sats \ 8 replies \ @ek 12 Apr

periodically send keepalive messages to avoid the server dropping the stream if it stays idle too much

Can’t you just retry with HTTP if the stream is dropped? And you don’t have to do that with websockets?

implement message parsing

You don’t have to parse the app-specific messages you send over websockets?

implement multiplexing

Is this not built into HTTP/2?

100 sats \ 5 replies \ @rblb 12 Apr

Can’t you just retry with HTTP if the stream is dropped? And you don’t have to do that with websockets?

No, you don't have to do that with websockets, because you rely on the tcp stack to do that. HTTP/2 connections are also tcp, of course, but they have an idle timeout, after which the socket is forcefully closed. You can reopen the http stream, sure, but you will be dealing with a dirty close.

You don’t have to parse the app-specific messages you send over websockets?

I am not talking about parsing the content of the message, but extracting the message from the stream. Websocket are message based, if you use a raw http stream you'll have to figure out where the message starts and where it ends.

Is this not built into HTTP/2?

Not if you abuse the protocol like that, because your application will pipe all the data through a single stream and wait for responses, you'll have implement a queue for writers, and a callback mechanism of some sort, if you want it to be efficient.

0 sats \ 4 replies \ @ek 12 Apr

If you could create YouTube, Netflix, Amazon Prime etc. from scratch, would you use websockets instead of HTTP streaming?

0 sats \ 3 replies \ @rblb 12 Apr

These are all examples of unidirectional data stream with little to no idle time. That's what http streams are for and not what the article is talking about.

0 sats \ 2 replies \ @ek 12 Apr

So when you said

to make this work in real life

You didn’t mean the example of using HTTP streams instead of websockets that came at the end?

So what’s the alternative?

We touched on it very briefly in the previous sections, but if we can abstract away the transmitting side of the socket and only be left with a one-way stream of data on the receiving side, we can use a much simpler communication pattern.

What did you refer to with "this" then?

The post title is "You might not need websockets." When you say "to make this work in real life", you’re either referring to the example in the article or dismissing every case in which you want to stream something in some way that is not using websockets.

What do you think the article was talking about?

view all 2 replies

0 sats \ 1 reply \ @ek 12 Apr

Sounds to me like you’re mentioning reasons why websockets are shitty but instead of saying websockets are shitty, you say any other method needs to be just as shitty, else it’s even shittier.

0 sats \ 0 replies \ @rblb 12 Apr

No, i am saying that implementing an half baked tcp socket on top of an abused http request doesn't make sense when you have websockets that are a proper wrapper around lower level tcp.