I think GP talks about how to think about communication (client server).

Stateless request response cycles are much simpler to reason about because it synchronizes messages by default. The state is reflected via this back and forth communication. Even when you do it via JS: the request data is literally in the scope of the response callback.

If you have bi-directional, asynchronous communication, then reading and writing messages is separate. You have to maintain state and go out of your way to connect incoming and outgoing messages semantically. That's not necessarily what you should be doing though.

1. Send Request 1 2. Wait for Response 1 3. Send Request 2 4. Wait for Request 2

while you can do

1. Send Request 1, move on 2. Send Request 2, move on

and have an other process/routine handling response

and potentially you even have Request that can be sent without needing a reponse "user is typing" in XMPP for example.

and even wilder for people using only http, that you can receive Response without a Request ! (i.e that you don't need to implement a GET /messages request, you can directly have your server sending messages)

> Sounds like a worse way of writing async requests,

It's just how it works under the hood, this complexity is quickly abstracted and actually it's how a lot of async requests are implemented, it's just here it's on 1 tcp connection.

> , while the last part is basically what websockets seem to be intended for

yes I was specifically answering that :

> I have seen teams of experienced seniors using websockets and then just sending requests/responses over them as every architecture choice and design pattern they were familiar with required this.

i.e people using websocket like normal http request.

Easiest example is probably games, events could be things such players moving to new locations, firing a weapon, explosions.

In realtime games, as well as "request-response" scenarios, it's common to have some kind of response that acknowledges that data was received.