2 ms·

For me, the most significant part of this announcement is the breaking out of this feature into an extension. Some interesting questions - Does this represent

For me, the most significant part of this announcement is the breaking out of this feature into an extension. Some interesting questions - Does this represent a deprioritisation of the feature by Mozilla (it would seem not, since there's an explicit WebExtensions API just for this, but I'm curious to see how the level of maintenance of the extension UI keeps up with browser changes going forward) - This seems like the first major WebExtensions API that Firefox has added post 57 (though it was available with a flag before) that no other browser supports[0]. Does the represent Mozilla's future policy w.r.t. WebExtensions in general - i.e. building out the API with Firefox-specific features? This could be good for differentiating Firefox again, but probably more work for devs creating cross-browser extensions. [0] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contextualIdentities#Browser_compatibility https://developer.mozilla.org/en-US/Add-ons/WebExtensions/AP...

aembleton 9y ago
Personally I don't want this feature. Because it is an extension, I don't have to have it and my browser can be lighter. This is exactly what should happen, move as much as possible into extensions. If WebExtensions doesn't allow for this, then yes, Firefox should extend it. That way, other extensions can make use of it. You might not be able to port it to Chrome because it is using specific Firefox APIs but the alternative is not to have this feature. I expect to see other extensions in the future like the ability to hide the tab bar.
- Vinnl 9y ago
  That sounds rather arbitrary. In fact, most of the feature is implemented in browser code; what the extension does is expose a UI for it. "Lighter" isn't really properly defined, and it feels a bit like you're just principally opposed to code you don't personally use "being there", which I don't think is really productive if it doesn't really impact your use in another way.
- lucideer 9y ago
  I have to agree with Vinni here, particularly as a former Opera user which is a browser that took the polar opposite of this approach and yet remained by far the lightest, most performant of the main browsers up until version 12. It is absolutely possible to have your cake and eat it here, and the main reason for this is that extensibility - from an engineering perspective - is complex. Providing extension APIs necessitates generalised code, that fits a range of use-cases and is parameterised in a generic manner. Providing specific browser features on the other hand requires specific code, which can be written in a targetted fashion for the single feature, and therefore can be made much leaner and optimised. This is absolutely not always the case - you can of course have the worst of both worlds (inflexible non-extensible apps with inefficient badly written code), but I would not underestimate the heaviness of extensibility, nor the potential "lightness" of built-in features. --- That said - I'm impressed with the performance of 57 and the ease of writing WebExtensions, so I'm pro this move personally.
Vinnl 9y ago
I know they were struggling with a way to make this available to the users without being confusing. Making it an extension probably comes down to "we had no idea how to do that/only power users considered it useful, so an extension is a good compromise". In other words: if an extension is a good way to serve a significant part of a certain group of niche users (i.e. power users), they will probably properly maintain it but keep distributing it in this way. Oh, and about the API: they already had quite a few API's that weren't available in Chrome (e.g. the sidebar API). It will be interesting to see whether/how much they will be able to get standardised, and if they are willing to make breaking changes to the API if the W3C desires those to be made.

aembleton 9y ago

Personally I don't want this feature. Because it is an extension, I don't have to have it and my browser can be lighter. This is exactly what should happen, move as much as possible into extensions. If WebExtensions doesn't allow for this, then yes, Firefox should extend it. That way, other extensions can make use of it. You might not be able to port it to Chrome because it is using specific Firefox APIs but the alternative is not to have this feature. I expect to see other extensions in the future like the ability to hide the tab bar.

Vinnl 9y ago
That sounds rather arbitrary. In fact, most of the feature is implemented in browser code; what the extension does is expose a UI for it. "Lighter" isn't really properly defined, and it feels a bit like you're just principally opposed to code you don't personally use "being there", which I don't think is really productive if it doesn't really impact your use in another way.
lucideer 9y ago
I have to agree with Vinni here, particularly as a former Opera user which is a browser that took the polar opposite of this approach and yet remained by far the lightest, most performant of the main browsers up until version 12. It is absolutely possible to have your cake and eat it here, and the main reason for this is that extensibility - from an engineering perspective - is complex. Providing extension APIs necessitates generalised code, that fits a range of use-cases and is parameterised in a generic manner. Providing specific browser features on the other hand requires specific code, which can be written in a targetted fashion for the single feature, and therefore can be made much leaner and optimised. This is absolutely not always the case - you can of course have the worst of both worlds (inflexible non-extensible apps with inefficient badly written code), but I would not underestimate the heaviness of extensibility, nor the potential "lightness" of built-in features. --- That said - I'm impressed with the performance of 57 and the ease of writing WebExtensions, so I'm pro this move personally.

Vinnl 9y ago

I know they were struggling with a way to make this available to the users without being confusing. Making it an extension probably comes down to "we had no idea how to do that/only power users considered it useful, so an extension is a good compromise". In other words: if an extension is a good way to serve a significant part of a certain group of niche users (i.e. power users), they will probably properly maintain it but keep distributing it in this way. Oh, and about the API: they already had quite a few API's that weren't available in Chrome (e.g. the sidebar API). It will be interesting to see whether/how much they will be able to get standardised, and if they are willing to make breaking changes to the API if the W3C desires those to be made.