> > by changing the extensions API to make it less powerful
> This is not about copying Chrome. This is about moving off of an API which was effectively "our entire codebase is your public API, here, have fun"
But at the same time it also breaks access to non-mozilla things, i.e. external libraries and the operating system (e.v. via js-ctypes). Which means it becomes more difficult to interact with native, which turns the browser more into a non-interoperating silo.
It also prevents valid use-cases such as modifying the UI, download management, implementing novel network protocols (think ipfs) and integrating it with the internal network request APIs.
While the arguments for webextensions are clear to me the no-compromise approach is not. There are no escape hatches that are conceptually comparable to sudo, rust's unsafe blocks, phone unlocking or whatever.
Mozilla was fairly loudly warned by developers that this will hurt specific addons and exclude entire categories of addon features and they went ahead anyway. In other words they did choose to make their addon system less useful. I don't think this can be argued away.
I'm saying that it doesn't imply firefox is copying Chrome.
There are tradeoffs here. The team weighed them and made a decision. It was not about copying Chrome.
> It also prevents valid use-cases such as modifying the UI, download management, implementing novel network protocols (think ipfs) and integrating it with the internal network request APIs.
Not necessarily, webextension APIs that provide better scoped hooks to this can be added. Except perhaps the novel network protocols one. But it depends.
> Not necessarily, webextension APIs that provide better scoped hooks to this can be added.
That mere possibility does not alter the fact that upon release of FF57 a long-tail set of features will unavailable at that given point, in other words there will be a decline and mozilla might work over time to win back some fraction of that decline.
The net effect compared to today is still a decline in features, which is what will be perceived.
Without escape hatches this system will always be inferior in its versatility. Which is why most runtimes do have escape hatches, they admit that any provided APIs will never be sufficient for all valid uses.
> This is not about copying Chrome. This is about moving off of an API which was effectively "our entire codebase is your public API, here, have fun"
But at the same time it also breaks access to non-mozilla things, i.e. external libraries and the operating system (e.v. via js-ctypes). Which means it becomes more difficult to interact with native, which turns the browser more into a non-interoperating silo.
It also prevents valid use-cases such as modifying the UI, download management, implementing novel network protocols (think ipfs) and integrating it with the internal network request APIs.
While the arguments for webextensions are clear to me the no-compromise approach is not. There are no escape hatches that are conceptually comparable to sudo, rust's unsafe blocks, phone unlocking or whatever.
Mozilla was fairly loudly warned by developers that this will hurt specific addons and exclude entire categories of addon features and they went ahead anyway. In other words they did choose to make their addon system less useful. I don't think this can be argued away.