yes. without background processing every web based service that has live updates would break. Email (Gmail/outlook.com/...) chat (slack/messenger/WhatsApp/Discord) SNS (fb/Twitter) even stack overflow and github have various forms of live update
On mobile platforms, app don't use polling loops for that sort of stuff, precisely so that power usage could be optimized. Time for something similar for the web?
Arent notifications same thing with only difference that they go through apple/google centralized server so your phone doesnt have to listen for multiple servers but just one?
A simple short-term workaround would a setInterval equivalent that can be set to "every so often" instead of a hard number, leaving it up to the browser or OS to coalesce updates into chunks of activity every so often.
background connections !== polling loops
Many services use an open tcp connection (e.g. websocket) rather than polling. Mobile platforms are doing the same thing, just on a system level. I guess service workers are the closest web analogue.
Re:Limiting JavaScript?
by realusername on Sunday February 03, 2019 @12:13AM
(#19068005)
Firefox has also the same logic to throttle background tabs.
Chrome does throttle background tabs: https://developers.google.com/web/updates/2017/03/background...
It doesn't throttle them all the way to zero, though. If they did that they'd break things like sites that change their favicon to signal "unread message".
(Disclosure: I work at Google, though not on Chrome)