It feels to me like the author used WebSockets for the wrong thing. I don't think WebSockets belong on a website (even an interactive one as discourse, it is still a website based on my criteria). They'd be more apt in web applications.
So, to me it feels like the 1-connection-per-tab feels like saying "someone launched 50 instances of an executable and it opened 50 TCP connections".
Examples of where I think it's acceptable/recommended to use Web Sockets include /(video|audio)?/ chats, multiplayer games, collaboration tools, etc. Stuff that requires real-time notifications.
Does a discussion platform require that time precision? I doubt it (frankly, I think WebSockets would give a too high "temporal resolution" unless there were proper delays in place which just complicates the implementation, but that is actually irrelevant here).
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 :)
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.
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?
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.
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.
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)
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.
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.
I'm not understanding your distinction between 'websites' and 'web applications'(we can have a debate about the distinction). All the issues that the author raised apply to both categoties when WebSockets are used. So in context, it's a meaningless distinction. And even if you are writing just a 'website' - why shouldn't you use any standard tool available? It's like saying CSS3 is overkill for 'websites'.
At work we have a true 'web application' and opted for long polling for real-time collab for a variety of reasons, one of which is that long poll plays nice with corporate firewalls and WebSockets are a mixed bag.
I suppose inherent in the design of many modern 'web applications' is the concept of a single page interface. This encourages user behavior through a single view, rather than how many people interact with a website where they might spawn off dozens of tabs for each piece of content they intend to consume. In the case of the later, you'd wind up with dozens of tabs each conducting some form of communication, whereas with a web application, the design of the app might result in fewer connections since they're being routed through an interface designed to manage the flow of user interaction. Certainly not the case for every website or every web application, but I think that's conceptually why the distinction was being made.
It's like @uptown described it. It's not so much about what technology is used, but the overall design, work flow, and the user requirements of the Web app.
Let's take Facebook.com for example, feels more like a website, while its Messenger.com website does feel more like a web app.
So, to me it feels like the 1-connection-per-tab feels like saying "someone launched 50 instances of an executable and it opened 50 TCP connections".
Examples of where I think it's acceptable/recommended to use Web Sockets include /(video|audio)?/ chats, multiplayer games, collaboration tools, etc. Stuff that requires real-time notifications.
Does a discussion platform require that time precision? I doubt it (frankly, I think WebSockets would give a too high "temporal resolution" unless there were proper delays in place which just complicates the implementation, but that is actually irrelevant here).