[jacobolus]

In general long polling takes more browser/network resources than web sockets. “Long polling” means you keep one request always open to the server, and whenever it is answered or times out, you immediately open a new connection.

cf. https://en.wikipedia.org/w/index.php?title=Comet_(programmin... for an explanation of various ways of implementing “comet” / “push” web applications. In my opinion anyone who would consider using long polling should default to using WebSockets, with some XHR streaming implementation as a backup option, and long polling as a last resort fallback when other methods don’t work. Long polling is strictly inferior to WebSockets for modern browsers. [I’m linking to the old version of the Wikipedia page because shortly after that version a rogue editor with an axe to grind came and obliterated most of the content, and the article never really recovered.]

Maybe you just meant “polling”, with some very low poll frequency, or perhaps some kind of exponential backoff? In my experience, websites which use polling usually also take more browser resources than WebSockets would take. Almost nobody bothers to back their polling rate off to once every few minutes or slower when they are in a background window/tab, because web developers have little to no incentive to care about client-side resource use, so as a rule they don’t. If your site is polling every few seconds, that ends up being terrible for browser performance once there are many tabs open.

More properly, web applications which expect they might be opened in multiple tabs (looking at you Facebook, Gmail, etc.) should just be opening a single WebSocket connection, and then communicating among themselves across tabs to pass data where it needs to go. It’s really annoying that lazy web developers just open up several new persistent connections per tab, wasting sockets / bandwidth / battery life / etc.

[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.