[endriju]

I don't think WebSockets belong on a website (even an interactive one as discourse...

From the article "Discourse does not use WebSockets. Discourse docker ships with HTTP/2 templates."

The whole article is worth reading. It looks like the author is well aware the WebSockets limitations.

[ronjouch]

The author is indeed well aware of WebSockets limitations, and OP's "Examples of where it's acceptable/recommended to use WebSockets" seem sound.

The problem is that the appeal of oooh-shiny is so strong that some (many?) developers and influencers do end up "using WebSockets for the wrong thing". Last case I met: a tutorial for a client+server js app using React & Redux [1], building... a CRUD voting application. Quoting the article on why choosing WebSockets for this, "This is an app that benefits from real-time communication, since it's fun for voters to see their own actions and those of others immediately when they occur. For that reason, we're going to use WebSockets to communicate."

Well yes, WebSockets work here (modulo problems and missed benefits/tooling that are the whole point of this article), and socket.io seems like a nice library, but a good old long poll would have done just as well :)

[1] http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial...

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

[mstade]

This seems like a terrible fit for WS. It's not a realtime problem, and doesn't require a realtime solution. Near-realtime will do just fine. I.e. have some endpoint that gives you voting results, and if requested with the text/event-stream media type will give you a stream of realtime events. Then post votes and what not with usual HTTP methods. This is presumably less efficient in terms of transport, but much more straight forward (and thus more cost-efficient) to implement and has some serendipitous side-effects such as your API now being usable by any ol' HTTP client.

Edit: to be clear, I'm agreeing with your assessment; and criticizing the article you linked to. :o)

[jacobolus]

If you are getting the results as an event stream, that doesn’t really save anything on client-side resources. Seems just as “real time”, just with a slightly different back-end implementation.

[mstade]

The difference is on the client-to-server communication, since it's a one-way stream. So you're right in saying it's just as realtime when getting results from the server, but there's added latency to each request being made from the client. My point is that this latency is probably negligible for most "realtime" applications. The benefit to all this is that you're not re-inventing protocols on top of a low-level transport, and both front- and backend becomes significantly simpler (and thus more cost effective) to implement.