3 ms·
I think most people would agree that it's important to add the ability to evict unused extension code from memory, which is what the fundamental move to a state
by nightpool 4y ago
I think most people would agree that it's important to add the ability to evict unused extension code from memory, which is what the fundamental move to a stateless ServiceWorker architecture is designed to support (since the previous stateful architecture required all extension background pages to be loaded regardless of whether they were actually doing anything). Being able to do that for the vast majority of extensions that that helps, without requiring extension authors to "opt in" to that change, is a very important goal.
But I agree that the heuristics for when to evict certain extensions (especially those with broad all-page access permissions) definitely remains tricky, and I hear you that Chrome's are currently too severe for this type of extension to be practical. I don't think that's a fundamental problem with the service worker model though—it seems easy to add a heuristic to cover this case like "If the extension has a async network request event registered and there's an active tab open that that extension has permissions to view, be very cautious in evicting it". In that case Chrome could still want to evict the service worker i.e. if the tab/browser is in the background and paused[1], so that it wouldn't be handling event loop / network requests anyway.