> Is it mainly because of the HTTP request overhead?
Aside from the overhead you and others mention, there is a bigger problem. For most server-side languages, once a request is initiated, it is very difficult to feed new data into that request and make it perform additional functions. Most requests get their input data from GET or POST. What if an external server outside of the one that is handling the request needs to contact one of the clients?
Using long polling/SSE, you essentially have to have the thread/process handling the request also poll any external sources for information for any potential events that might need to be triggered. This turns into a huge mess very quickly. Especially since each polling/SSE request thread/process is isolated from the rest, forcing you to do really funky stuff to coordinate everything.
This isn't as much of a problem with web sockets. Your web socket server has access to all of the connected clients and you can create a web socket interface in any external servers to allow them to talk directly to the proper clients. It's cleaner.
Web sockets isn't perfect. I had to implement a proper client for web sockets in PHP so that it can talk to my Node.JS websocket server. It was horrible. But it was less horrible than setting all of that up with long polling.
Aside from the overhead you and others mention, there is a bigger problem. For most server-side languages, once a request is initiated, it is very difficult to feed new data into that request and make it perform additional functions. Most requests get their input data from GET or POST. What if an external server outside of the one that is handling the request needs to contact one of the clients?
Using long polling/SSE, you essentially have to have the thread/process handling the request also poll any external sources for information for any potential events that might need to be triggered. This turns into a huge mess very quickly. Especially since each polling/SSE request thread/process is isolated from the rest, forcing you to do really funky stuff to coordinate everything.
This isn't as much of a problem with web sockets. Your web socket server has access to all of the connected clients and you can create a web socket interface in any external servers to allow them to talk directly to the proper clients. It's cleaner.
Web sockets isn't perfect. I had to implement a proper client for web sockets in PHP so that it can talk to my Node.JS websocket server. It was horrible. But it was less horrible than setting all of that up with long polling.