3 ms·

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, m

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

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.