[ronjouch]

No I meant long-polling exactly as you define it; periodic polling doesn't seem comparable to WebSockets, due to the polling frequency.

Let me reformulate: as you say, yes WebSockets are probably better in every way than longpoll in modern browsers. But due to the problems with WS highlighted in the articles, for applications that do not require real-time communication, I'd rather stick with a slightly slower longpoll.

Regarding resource usage greater with WS than longpoll, can you precise that?

[tracker1]

Long polling creates a new connection for each polling, and keeping the connection open anyway for a given length of time... the connection will still be idle for a while before it drops off, depending on your OS configuration. Whereas websockets keep the single connection open, and with the right backend there's VERY little overhead to actually doing this.

Current async platforms (node, go, etc) have been shown to be able to keep a million+ open connections on a moderate server... Node in particular was geared towards a target of 100k per cpu, iirc. Which it now greatly exceeds. There are of course other application complexities that can reduce the connections per server, but that's another issue.

[iofj]

One does get the impression that the problems with websockets are mostly much extremely large web companies complaining that it isn't perfectly ideal for their exact application, and that they'd rather have their exact usecase written into browsers.