3 ms·

For the most part I agree with your quote save for the “stuck in the past, unable to adapt” part, I’d replace with “lag behind”. If the things continue to deve

For the most part I agree with your quote save for the “stuck in the past, unable to adapt” part, I’d replace with “lag behind”. If the things continue to develop the way they are now, the new features will be eventually incorporated into DNR (in somewhat different form, but anyways). Basically, the “innovation” should be requested via the W3C group from the browsers and only then (after quite some time) it can be used as a part of DNR. Is it worse than what we had before? Absolutely, adding anything to DNR is now a many-months process. Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant. I’d say that the situation changed from “MV3 is bad, DNR is unusable” to “MV3 is good, DNR is useable-but-limited”.

ghostwords 3y ago
> If the things continue to develop the way they are now I am not comfortable making that assumption! We already went through one "lost decade" for Chrome extensions.
- ameshkov 3y ago
  Good comment. I guess it’s a matter of hope :) I really want to believe that the extensions platform will continue to develop with at least the same pace, and eventually comes to Android. Maybe I am over optimistic though, we’ll see, but otherwise I just don’t understand what was all that about and what justifies such a significant investment in the extensions team.
xg15 3y ago
> Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant. Honest question, what kind of significant improvements do you actually see in MV3? I see a lot of more restriced, more complex APIs but few new features.
- ameshkov 3y ago
  I would argue that new APIs are better thought through and cover the use cases that the extensions actually need. Let me name a few examples. 1. chrome.scripting API and the concept of "isolated worlds" is easier to use and understand than what we had before. 2. Dynamic content scripts registration that everyone has waited for so long. 3. userScripts API is also a welcome addition. It does not provide everything and it needs to be improved, but it is already a good step forward. Finally the existence of userscript managers was recognized by Chrome and they're trying to make life easier for them. Also, the bug fixes. Before the expansion of the extensions platform team there were major bugs that could be open for many years, and now I see them closing one by one. To an outside observer it may look ridiculous that there was such a problem from the start, but that's how underinvestment looks like and I am happy that the situation improves. Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it. edit: formatting
  - xg15 3y ago
    Sorry, but I have to disagree here. > the concept of "isolated worlds" is easier to use and understand than what we had before. Isn't this basically the same concept they already used with ordinary content scripts for years? It's indeed useful, but also something that could have been relatively easily emulated with dynamic execution inside a content script before, I believe. > 2. Dynamic content scripts registration that everyone has waited for so long. 3. userScripts API is also a welcome addition. Yes, but those too are just an improvement compared to the previous state of MV3. In MV2 none of those APIs would even be necessary because an extension could easily implement this stuff itself. So it's an "improvement" in the sense that it now only removes 30% of the functionality instead of the 50% it did before. > Also, the bug fixes. That's orthogonal to MV3 though. And it again sounds like "we're now slightly less shitty to extension devs than we were before". > Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it. It's indeed not a bad API and there are many use cases in which it's clearly the better choice than the blocking version. However, the removal of the blocking variant and the removal of various usecases is Google's entire point here - otherwise, they wouldn't be so cagey with setting the limits of the number of rules. Firefox shows that it's no technical problem at all to implement both APIs at the same time.

ghostwords 3y ago

> If the things continue to develop the way they are now I am not comfortable making that assumption! We already went through one "lost decade" for Chrome extensions.

ameshkov 3y ago
Good comment. I guess it’s a matter of hope :) I really want to believe that the extensions platform will continue to develop with at least the same pace, and eventually comes to Android. Maybe I am over optimistic though, we’ll see, but otherwise I just don’t understand what was all that about and what justifies such a significant investment in the extensions team.

xg15 3y ago

> Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant. Honest question, what kind of significant improvements do you actually see in MV3? I see a lot of more restriced, more complex APIs but few new features.

ameshkov 3y ago
I would argue that new APIs are better thought through and cover the use cases that the extensions actually need. Let me name a few examples. 1. chrome.scripting API and the concept of "isolated worlds" is easier to use and understand than what we had before. 2. Dynamic content scripts registration that everyone has waited for so long. 3. userScripts API is also a welcome addition. It does not provide everything and it needs to be improved, but it is already a good step forward. Finally the existence of userscript managers was recognized by Chrome and they're trying to make life easier for them. Also, the bug fixes. Before the expansion of the extensions platform team there were major bugs that could be open for many years, and now I see them closing one by one. To an outside observer it may look ridiculous that there was such a problem from the start, but that's how underinvestment looks like and I am happy that the situation improves. Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it. edit: formatting
- xg15 3y ago
  Sorry, but I have to disagree here. > the concept of "isolated worlds" is easier to use and understand than what we had before. Isn't this basically the same concept they already used with ordinary content scripts for years? It's indeed useful, but also something that could have been relatively easily emulated with dynamic execution inside a content script before, I believe. > 2. Dynamic content scripts registration that everyone has waited for so long. 3. userScripts API is also a welcome addition. Yes, but those too are just an improvement compared to the previous state of MV3. In MV2 none of those APIs would even be necessary because an extension could easily implement this stuff itself. So it's an "improvement" in the sense that it now only removes 30% of the functionality instead of the 50% it did before. > Also, the bug fixes. That's orthogonal to MV3 though. And it again sounds like "we're now slightly less shitty to extension devs than we were before". > Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it. It's indeed not a bad API and there are many use cases in which it's clearly the better choice than the blocking version. However, the removal of the blocking variant and the removal of various usecases is Google's entire point here - otherwise, they wouldn't be so cagey with setting the limits of the number of rules. Firefox shows that it's no technical problem at all to implement both APIs at the same time.