5 ms·

I really think it depends on the complexity of the extension and how much it leverages the background page. > Background-workers instead of background-pages ma

I really think it depends on the complexity of the extension and how much it leverages the background page. > Background-workers instead of background-pages makes for a more consistent API. IMO background-pages were always weird. True, but they also did provide developers with a few benefits. For starters having a complete DOM available allows for a lot of handy dandy functionality to be done in the background. In the same sense it also meant having localstorage available in the backgroud. Which was actually very neat for caching purposes. Specifically if you care about privacy and people using your extension in incognito mode. With `"incognito": "split"` enabled it meant that cached data (so most likely the sort of data you don't want to leak between sessions) would remain seperated. This is no longer possible. You'd hope that the new session storage would work there, but no, for some reason that still ignores the fact that `"incognito": "split"` has been set and just leaks across sessions. Timers no longer being a thing also makes some operations slightly more complex, even more so because alarms do have some funky behavior. Ajax no longer being available sort of makes sense, but fetch isn't a drop in replacement as it does require a bit of boilerplate to make it work in a predictable manner. So it does require some effort there. > Time taken? Roughly one work-day. Eh, for relatively simple extensions I'd say that is accurate. But having done the conversion recently with an extension that does a bunch more and did rely on various background operations it took substantially more to get to there. It had a general positive impact on the code base in various areas but it was really more work than one workday, even more so when I include all planning and brainstorming. Given that many extensions are open source projects where maintainers have limited time and where for many extensions there really isn't a benefit I fully understand some of the hate towards being forced to do the conversion.

josteink 4y ago
All extensions are different. My extension (excluding NPM-dependencies) counts in at around 20k lines of TypeScript + various other resources. I think that counts as above average. Granted, the background-page/worker portion of it was not the dominant aspect, and thus had less rewrites required than if things had been the other way around. That said, migrating to V3 was way less effort than I thought it would be. I'm not saying it will be so for all extensions, but it was for mine, and it may be for others as well. Basically I'm just trying to provide some additional perspective here besides the usual content-blocker perspective which so far has gotten 100% of the narrative. Note I'm in no way dismissing that concern, but I think having the entire conversation framed around those extensions only does not correctly represent the huge variations found across the extension ecosystem.
- creesch 4y ago
  > All extensions are different. Absolutely, I didn't reply to say you are wrong or anything in that regard. I basically wanted to give some additional perspective. > I'm not saying it will be so for all extensions, but it was for mine, and it may be for others as well. Yup, for many extensions it might be relatively painless. It was for a different extension where I just had to replace ancient ajax calls for fetch and move some functionality to the front into content_scripts. At the same time it was a lot of work for the extension I mentioned in my previous comment. Which I might add is not an extension that has anything to do with content blocking which I agree does get a lot of attention. But the truth is that there are also a number of extensions that made creative use of the current manifest construction. Those extensions no longer can offer the same functionality, have to rewrite a lot of code with no functional benefit or redo functionality in a way that degrades the user experience. Even if for the majority of extensions migration is relatively painless it still leaves those extensions where it isn't and even those that can't be migrated due to how they work. They won't be a majority, but it still means that once the switch is done the ecosystem will be less diverse.

josteink 4y ago

All extensions are different. My extension (excluding NPM-dependencies) counts in at around 20k lines of TypeScript + various other resources. I think that counts as above average. Granted, the background-page/worker portion of it was not the dominant aspect, and thus had less rewrites required than if things had been the other way around. That said, migrating to V3 was way less effort than I thought it would be. I'm not saying it will be so for all extensions, but it was for mine, and it may be for others as well. Basically I'm just trying to provide some additional perspective here besides the usual content-blocker perspective which so far has gotten 100% of the narrative. Note I'm in no way dismissing that concern, but I think having the entire conversation framed around those extensions only does not correctly represent the huge variations found across the extension ecosystem.

creesch 4y ago
> All extensions are different. Absolutely, I didn't reply to say you are wrong or anything in that regard. I basically wanted to give some additional perspective. > I'm not saying it will be so for all extensions, but it was for mine, and it may be for others as well. Yup, for many extensions it might be relatively painless. It was for a different extension where I just had to replace ancient ajax calls for fetch and move some functionality to the front into content_scripts. At the same time it was a lot of work for the extension I mentioned in my previous comment. Which I might add is not an extension that has anything to do with content blocking which I agree does get a lot of attention. But the truth is that there are also a number of extensions that made creative use of the current manifest construction. Those extensions no longer can offer the same functionality, have to rewrite a lot of code with no functional benefit or redo functionality in a way that degrades the user experience. Even if for the majority of extensions migration is relatively painless it still leaves those extensions where it isn't and even those that can't be migrated due to how they work. They won't be a majority, but it still means that once the switch is done the ecosystem will be less diverse.