The background page to service worker change may backfire in practice

While thinking/writing on discord I "discovered" that the move to time-limit background tasks by moving them to service workers (#72) might backfire. I understand that this is a solution for a problem. But it might have unintended consequences. While this is the obvious solution, sometimes people do not react as you expect, and things develop differently. I would like to have your opinion. Maybe I got something wrong.

Any extension that wants to do compute in the background will immediately restart the background task. So, the background task will still run all the time and the change does not help. Others who need a persistent context (to store data, state or maintain a network connection) will also restart the background task AND consume additional resources doing so. In essence: the change does not achieve the desired effect and even hurts performance.

With respect to memory consumption: there might be more worthwhile targets. A typical chrome tasks list of my always open tabs shows the weblin.io extension uses 30 MB and does almost nothing even though it holds user items, avatars and manages a persistent messaging connection. Compare this with chrome core processes (1.1 GB), LinkedIn, Facebook, gmail tabs (300 MB each), and many tabs/extensions between 100 and 300 MB including Google Sheet, Google Analytics, Google Keep, Google Translate. Then tell me that the Manifest V2 extension is a resource hog, that must be dealt with.

What do you think?

(Related to the persistent-background-context-for-a-messenger-app issue #133)

Start by reading the proposed service-worker change in issue #72 and the related persistent-background-context discussion in issue #133. Compare the concerns about background-task restarts, persistent state, network connections, and resource use; the issue does not define a concrete implementation target or completion criterion.