WebSockets solve two way asynchronous communication in the most awkward way possible. There's a ton of unnecessary protocol overhead on top of TCP/IP, which is where a lot of the difficulties with the WebSocket protocol occurs. Instead of upgrading to a straight TCP/IP passthrough, the WebSocket protocol applies a "frame" protocol and splits message types between "text" and "binary" frames along with a few special frame types including a broken-by-design "closing" frame type. A good protocol would just say, "Here's a raw TCP/IP connection passthrough to the backend after the Upgrade request. Knock yourself out." WebSocket is not that protocol.
Server-sent events (SSE) can end up polling something on the server side of things. Users who follow the official MDN example would effectively do just that. That's just as bad, if not worse (wasted CPU cycles on the server), than using WebSocket. SSE solves the polling problem from client to server to reduce network load but that's about all it is good for. The SSE protocol itself is even wackier than WebSocket. SSE is an ad hoc protocol of highly questionable design. For better or worse, WebSocket has an actual IETF specification since it is an actual network protocol. Further, SSE has client level limits on how many connections can be established to a host. Debugging SSE is also more difficult in some browsers as the Network tab may only show the contents of the received data after the connection closes. If the connection doesn't terminate, then the line data can't be viewed in the Network tab. Of course, for a while in the early days of WebSocket, there was no debugging support for that protocol built into web browsers either. In short, SSE has a lot of downsides too.
Technically, the HTTP protocol itself already supports two way, asynchronous communication. It's just that web servers and clients don't really support that mode. Both client and server could continuously send and receive data as part of a single HTTP request and response. The client sends its request headers and the server sends its response headers. Then, after that, it's just back and forth TCP/IP as part of that single request. If someone wanted to get fancy, HTTP supports chunked data in BOTH directions. We normally only see chunked encoding from server to client. Chunked transfers also support writing additional headers at the end of the request/response (currently extremely rare) but could be used to temporarily pause a request/response and then pick it up again later on the same TCP/IP connection. HTTP/2 has frames and multiplexed streams but none of that is exposed to the web developer to leverage/utilize. This is basically what WebSocket wanted to be but it completely failed to hit the broadside of the barn. In short, HTTP itself already solved all of the problems that WebSocket and SSE try to solve but the necessary support is severely lacking.
In conclusion, there isn't any particularly good, general-purpose solution to two way asynchronous communication with a HTTP server because the website developer is at the mercy of web browser vendors' whims. And browser vendors mostly focus on UI/chrome redesigns that cause end users to riot instead of making better underlying technology that devs rely on. Both WebSocket and SSE have their pros and cons but neither one are arguably good/correct solutions.
WebSockets solve two way asynchronous communication in the most awkward way possible. There's a ton of unnecessary protocol overhead on top of TCP/IP, which is where a lot of the difficulties with the WebSocket protocol occurs. Instead of upgrading to a straight TCP/IP passthrough, the WebSocket protocol applies a "frame" protocol and splits message types between "text" and "binary" frames along with a few special frame types including a broken-by-design "closing" frame type. A good protocol would just say, "Here's a raw TCP/IP connection passthrough to the backend after the Upgrade request. Knock yourself out." WebSocket is not that protocol.
Server-sent events (SSE) can end up polling something on the server side of things. Users who follow the official MDN example would effectively do just that. That's just as bad, if not worse (wasted CPU cycles on the server), than using WebSocket. SSE solves the polling problem from client to server to reduce network load but that's about all it is good for. The SSE protocol itself is even wackier than WebSocket. SSE is an ad hoc protocol of highly questionable design. For better or worse, WebSocket has an actual IETF specification since it is an actual network protocol. Further, SSE has client level limits on how many connections can be established to a host. Debugging SSE is also more difficult in some browsers as the Network tab may only show the contents of the received data after the connection closes. If the connection doesn't terminate, then the line data can't be viewed in the Network tab. Of course, for a while in the early days of WebSocket, there was no debugging support for that protocol built into web browsers either. In short, SSE has a lot of downsides too.
Technically, the HTTP protocol itself already supports two way, asynchronous communication. It's just that web servers and clients don't really support that mode. Both client and server could continuously send and receive data as part of a single HTTP request and response. The client sends its request headers and the server sends its response headers. Then, after that, it's just back and forth TCP/IP as part of that single request. If someone wanted to get fancy, HTTP supports chunked data in BOTH directions. We normally only see chunked encoding from server to client. Chunked transfers also support writing additional headers at the end of the request/response (currently extremely rare) but could be used to temporarily pause a request/response and then pick it up again later on the same TCP/IP connection. HTTP/2 has frames and multiplexed streams but none of that is exposed to the web developer to leverage/utilize. This is basically what WebSocket wanted to be but it completely failed to hit the broadside of the barn. In short, HTTP itself already solved all of the problems that WebSocket and SSE try to solve but the necessary support is severely lacking.
In conclusion, there isn't any particularly good, general-purpose solution to two way asynchronous communication with a HTTP server because the website developer is at the mercy of web browser vendors' whims. And browser vendors mostly focus on UI/chrome redesigns that cause end users to riot instead of making better underlying technology that devs rely on. Both WebSocket and SSE have their pros and cons but neither one are arguably good/correct solutions.
Thanks for you insights, very reasonable 👍 That could be a whole separate post by itself 👏