WebSockets still win for high‑frequency updates
A developer thread compared polling to WebSockets and concluded WebSockets are preferable for persistent, bidirectional low‑latency streams despite higher memory costs. The conversation reinforces that for real‑time trading UIs and telemetry, maintaining persistent connections often outperforms repeated HTTP polling (x.com).
Most websites still work like a kid asking “are we there yet?” every few seconds: the browser sends an Hypertext Transfer Protocol request, waits, then asks again. WebSocket was standardized in Internet Engineering Task Force Request for Comments 6455 to stop that loop by turning one Hypertext Transfer Protocol connection into a long-lived two-way channel. (rfc-editor.org) That one channel stays open after a single handshake, so the server can speak first instead of waiting to be asked. Mozilla’s Web Docs says a browser can send messages and receive responses “without having to poll the server for a reply.” (developer.mozilla.org) Polling is simpler, but it burns work even when nothing changed. In short polling, the client asks on a timer and often gets back “nothing new,” while in long polling the server holds the request until data arrives and the client immediately opens another request. (developer.mozilla.org) (javascript.info) That is why the tradeoff flips when updates come fast. A stock chart moving several times per second or a telemetry dashboard streaming sensor readings spends less time reopening Hypertext Transfer Protocol requests and more time just moving data. (developer.mozilla.org) (websocket.org) The developer thread making the rounds lands on exactly that point: if the app needs persistent, bidirectional, low-latency updates, WebSockets usually win. The “bidirectional” part matters because a trading screen, game, or collaborative tool often needs the browser to send actions upstream while the server is pushing updates back down the same pipe. (rfc-editor.org) (developer.mozilla.org) The cost is that every open WebSocket is a live connection the server has to keep in memory. Long polling can also tie up resources, but WebSockets ask you to budget for many simultaneous sockets instead of many repeated requests. (ably.com) (getstream.io) There is another catch on the browser side: Mozilla warns that the WebSocket interface has no built-in backpressure. If messages arrive faster than the page can process them, memory can fill up and the page can peg the central processing unit at 100 percent. (developer.mozilla.org) That is why “WebSockets are better” is only true for a specific shape of problem. If updates are rare, one-way, or tolerant of a few seconds of delay, plain polling or server-sent events can be easier to run, and server-sent events keep a single Hypertext Transfer Protocol stream open for server-to-browser messages without adding browser-to-server messaging. (developer.mozilla.org 1) (developer.mozilla.org 2) So the thread is less a surprise than a reminder of what the web stack was built to do. Repeated Hypertext Transfer Protocol requests are fine for checking occasionally, but if your screen is supposed to feel live every second, the old 2011 WebSocket standard is still the tool most developers reach for. (rfc-editor.org) (developer.mozilla.org)
