As a quite heavy user of websockets, and having done a few implementations of them, I agree only partly with it: Yes, Websockets are hard to implement, and mos

As a quite heavy user of websockets, and having done a few implementations of them, I agree only partly with it: Yes, Websockets are hard to implement, and most implementations that are floating around (e.g. on github are horribly broken). But the same probably applies to good HTTP and especially HTTP/2 implementations too! I also totally agree that web sockets make load balancing and proxying more complicated than stateless HTTP requests. But I still think that Websockets have their place. They are some kind of more basic building block (like TCP), on which you can build your own protocol with totally different semantics. If you only build some request/response protocol on top of it you probably have not gained much - but still it would be different from HTTP in the way that message ordering is guaranteed. If you only need events from the server to the client you could use SSE, but if you need to add some dynamic subscribe/unsubscribe functionality you would need some additional HTTP [POST] calls. You could get the idea that you use one SSE endpoint per topic and treat the stream disconnect as an unsubscribe, but as long as you can't rule out that you have any non HTTP/2 clients it won't work because of the connection limit in browsers. I also benchmarked that approach with node and golang http/2 against my websocket based protocol and achieved only a throughput of about 10% of the websocket based solution. All in all I currently think that currently one should favor pure HTTP if scaling is a big issue and if most state is anyway persisted in some distributed databases. If only a single server is the remote peer, the state is not necessarily persisted per client, a combination of RPC and event distribution semantics is needed, message ordering guarantees are necessary or high realtime characteristics are needed then websockets are a very powerful option seriously needs to be considered. My personal use-case is forwarding data from automotive realtime bus systems into web-based user interfaces and I had great success with using websockets to achieve this. Although I'm still also looking into HTTP/2, because it really has some interesting properties. One other thing I would like to add: One comment in the article mentions to always prefer websocket frameworks like socket.io or signalR. What you should take into account is that by using one of those frameworks you are also binding yourself to a specific technology stack (node, C#, ...), if you are not willing to reimplement the protocols. If you use your own well-specified protocol or another well-specified higher level protocol (like WAMP), then you are not bound to specific technologies for your client and server applications. Therefore I always opt to go that way if long maintenance, open APIs or good interoperability are desired.