Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Browser Extensions Standard

browserext.github.io

Post reply on HN
Print view View original

81–82 of 82 posts

Re: Browser Extensions Standard

#81

Post by bzbarsky »

xg15 wrote: post #79
bzbarsky wrote: post #36

Earlier quoted context omitted.

> they'd have pushed for replacement of XUL APIs in WebExtensions in a non-blocking way Which "they" did, and are. Some APIs are more amenable to such replacement than others. For example, APIs that allow you to modify any part of the browser UI in an arbitrary way are not so amenable _and_ have the problem of breaking any time the internal structure of the UI changes. Which has, in the past, prevented improvements t…

Except the downsides are mostly for the users (extensions stop working) while the upsides are mostly for the browser developers. (Better ability to refactor and update)

The upsides are for users as well: better performance, less memory usage, better ability to implement web standards. Browser developers aren't just breaking extensions for the fun of it, but because they're in the way of actually producing a better product; the goal is to produce said better product.

The upsides are just somewhat more diffuse than the downsides: the former apply to all users, while the latter only to those who have extensions that stop working.

Re: Browser Extensions Standard

#82

Post by bzbarsky »

piyush_soni wrote: post #80
bzbarsky wrote: post #36

Earlier quoted context omitted.

> they'd have pushed for replacement of XUL APIs in WebExtensions in a non-blocking way Which "they" did, and are. Some APIs are more amenable to such replacement than others. For example, APIs that allow you to modify any part of the browser UI in an arbitrary way are not so amenable _and_ have the problem of breaking any time the internal structure of the UI changes. Which has, in the past, prevented improvements t…

The thing is, I as an end user shouldn't need to look from both sides (where one side is predominantly of the FF developers or extension developers). I speak for my continued convenience of using Firefox as a browser which had an upper hand to Chrome to Chrome due to its extensions (as far as I'm concerned) which will end soon.

As end users, many (in fact a majority) have already made the decision that the benefits of Firefox's extensions don't outweigh the drawbacks those same extensions impose on Firefox in terms of performance and responsiveness, and have voted with their feet.

I appreciate that your personal tradeoff was different from most, and I know the pain of having an application that was targeting your use cases move away from that. I don't have much to offer other than the goal that Firefox still has to offer extension APIs that are broader than the ones Chrome does. It won't be quite as "yeah, hook into anything you want" as the old extension system, but that was really becoming completely unsustainable and was holding back Firefox not only in things like performance and responsiveness but also web standards: extensions would depend on things working a certain way and changing them to follow the spec would break those extensions...

Post reply on HN