As someone who is intimately familiar with the Chrome extensions internals and is not employed by a big tech company, I believe most of the changes seem like a step in the right direction.*
I've been working towards implementing greater support for Chrome extensions in Electron which has involved reading and interacting with Chromium code [0].
- Using service workers instead of a hidden background webpage is more idiomatic for web developers.
- Forced non-persistent extensions guides developers to a better implementation which relies on less resources.
*The deprecation of webRequest's blocking behavior is what's most concerning. The implementation in Manifest V2 requires sending a message back and forth between processes with JS processing for each network request which seems to be in part why they redesigned it.
However, that optimization costs so much for innovative ad blocking technologies as gorhill of uBlock Origin has mentioned. When ad blocking begins requiring new methods of detection or filtering, it'll now be up to Chromium maintainers to implement support for it in the new declarativeNetRequest API. This is a tradeoff of performance for reduced flexibility where it is absolutely needed.
[0] https://github.com/samuelmaddock/electron-browser-shell
I've been working towards implementing greater support for Chrome extensions in Electron which has involved reading and interacting with Chromium code [0].
- Using service workers instead of a hidden background webpage is more idiomatic for web developers.
- Forced non-persistent extensions guides developers to a better implementation which relies on less resources.
*The deprecation of webRequest's blocking behavior is what's most concerning. The implementation in Manifest V2 requires sending a message back and forth between processes with JS processing for each network request which seems to be in part why they redesigned it.
However, that optimization costs so much for innovative ad blocking technologies as gorhill of uBlock Origin has mentioned. When ad blocking begins requiring new methods of detection or filtering, it'll now be up to Chromium maintainers to implement support for it in the new declarativeNetRequest API. This is a tradeoff of performance for reduced flexibility where it is absolutely needed.
[0] https://github.com/samuelmaddock/electron-browser-shell