Comment by ameshkov | Hacker News Reader

Comment by ameshkov | Hacker News Reader

Parent Full thread

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

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.

> Isn't this basically the same concept they already used with ordinary content scripts for years?

It was implicit, now it's explicit and it gives more control and better understanding. It also allows introducing more levels of isolation, like a separate "USER_SCRIPTS" world or "MAIN", before that you had to mess with evals and adding script tags.

> Yes, but those too are just an improvement compared to the previous state of MV3

Yes, that's why I listed these as improvements.

> And it again sounds like "we're now slightly less shitty to extension devs than we were before".

They went from "1 person that tries to make things not crumble" to a large team of developers, it's a big step forward. What signal do we send them if we always say "everything you're doing is bad" even when it's factually not true?

> Firefox shows that it's no technical problem at all to implement both APIs at the same time.

At first we all thought that DNR is there for them to limit content blockers. With time they proved us wrong when they worked hard on improving it and covering more and more use cases.

Now I tend to think that this is an engineering decision that's driven by the other change - the shift from persistent background pages to service workers.

Is there a better solution that could save the blocking webRequest and achieving their goals at the same time? Most likely there is, but how hard would it be to implement it instead or what if it requires an architectural change? Anyways, these are speculations, I am with you here and I don't support blocking webRequest removal.

Reply on news.ycombinator.com