Note that the http-equiv refresh will only trigger after the page is fully-loaded, which long-polling does not allows to happen, so you do have resilience for the case where the long-poll is interrupted mysteriously.
Note that the http-equiv refresh will only trigger after the page is fully-loaded, which long-polling does not allows to happen, so you do have resilience for the case where the long-poll is interrupted mysteriously.
This does limit what you can do with the poll-added content, but simply allowing the refresh to take place is a strict improvement over refreshing eagerly.
...and now you have to greatly scale up your backend infrastructure to be able to handle all those open connections to handle each and every single active user.
Not exactly. With sync calls each server instance can handle only a few hundred connections. With async calls each instance can in theory handle tens of thousands of concurrent requests but each polling response van easily spike CPU and network loads. This means your "it works on my machine" implementation barely registers any load whereas once it enters operation your dashboards start to look very funny and unpredictable, and your scaling needs become far greater just to be able to gracefully handle those spikes. This is a radical departure from classic request-and-response patterns where load is more predictable.