> It is not memoryless request-response: there is a process per connected client that remembers where it is. It is the opposite of htmx, which is deliberately s

> It is not memoryless request-response: there is a process per connected client that remembers where it is. It is the opposite of htmx, which is deliberately stateless. This reflects some misconceptions I had about websockets before I used this protocol in a real application. In practice I found the following to be true: - Connection can drop at any time, be ready to reconnect, don't depend on that happening on the same server as before. - Messages may arrive out of order due to how framing works. Many implementations will complete a shorter message before an earlier longer message finishes. Don't depend on stream order for a one request-one response style messaging. Yes it's a serial TCP stream but it's basically modeling an asynchronous message protocol on top of that. This is reflected in the browser side API which just provides "onmessage" and leaves it up to you to track state. What this boils down to is that it's great for latency (but arguably superseded by WebTransport), but ultimately you're best off using it to handle a stateless protocol just as you would HTTP requests. If you do maintain state per connection, that state should only be metadata about that connection, such as a connection-level request id, or the caching of some contextual info (eg. user id) to avoid repetition in future messages. So I usually consider it a transport-layer optimization rather than something my application fundamentally depends on. At the end of the day with HTTP/2 reusing open connections combined with SSE, you should be able to achieve essentially the same behaviour and even latency. It's still useful to support but I disagree that the transport should dictate the framework style here, they are simply different layers that shouldn't be concerned with each other.