I think you have in mind a specific usage that is not so popular and have rather complex requirements.
You mentioned threads, and requests and out-of-order responses, and streams, I can't think at a scenario involving all these.
You usually only need to refresh some non-real time data and make requests, you do not send a new request until you received a response from the last one.
Or have a stream of data and it can keep coming, usually you do not process them on the front end so you do not end up having a lag, and more you do not have different requests. Also JS is single threaded. No need for a request, you have a connection open so you need the latest data, otherwise it would not require a websocket.
Yeah, the experience where I wished I had a long-poll capability was on the back-end processing events. Maintaining an open connection requires a surprising amount of coding to handle failure cases. Whereas a long poll can give you realtime-stream-like behavior in normal cases and a nice protective fallback behavior in spiky cases without worrying too much about the underlying connection. I think it is probably abnormal for web-socket users to run into throughput constrained situations where they need to protectively disconnect. It's not our normal usage pattern either, but it was a possibility I had to code for.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think you have in mind a specific usage that is not so popular and have rather complex requirements.
You mentioned threads, and requests and out-of-order responses, and streams, I can't think at a scenario involving all these.
You usually only need to refresh some non-real time data and make requests, you do not send a new request until you received a response from the last one.
Or have a stream of data and it can keep coming, usually you do not process them on the front end so you do not end up having a lag, and more you do not have different requests. Also JS is single threaded. No need for a request, you have a connection open so you need the latest data, otherwise it would not require a websocket.
Yeah, the experience where I wished I had a long-poll capability was on the back-end processing events. Maintaining an open connection requires a surprising amount of coding to handle failure cases. Whereas a long poll can give you realtime-stream-like behavior in normal cases and a nice protective fallback behavior in spiky cases without worrying too much about the underlying connection. I think it is probably abnormal for web-socket users to run into throughput constrained situations where they need to protectively disconnect. It's not our normal usage pattern either, but it was a possibility I had to code for.