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

71–80 of 82 posts

Re: Browser Extensions Standard

#71

Post by lewisl9029 »

piyush_soni wrote: post #9

The only problem which Mozilla didn't think about or hasn't given much value to is the huge number of add-ons that are going to die or just stop working when they completely switch to WebExtensions (as there's just no replacement to the previous API in them). One of the Firefox's USPs was its addons which could modify the browser behavior and UI in any manner. It's all going to go, and Mozilla is moving closer to bec…

For tab groups, take a look at Sea Containers: https://addons.mozilla.org/en-GB/firefox/addon/sea-container...

It makes use of the new Containers experiment to provide a similar tab organization mechanism as TabGroups, and presents them in a vertical sidebar which IMO makes for a much saner workflow for heavier tab users. The identity encapsulation that comes by default with Containers might not be what you're looking for in a pure tab management system though, but as Sea Containers shows, some variant of tab grouping can definitely be implemented in WebExtensions.

Re: Browser Extensions Standard

#72

Post by connorcpu »

gcp wrote: post #46
josteink wrote: post #24

Earlier quoted context omitted.

I know all about the issues with Firefox, the new WebExtensions and how the "old" XUL extensions which let you do "anything" are being phased out. I just don't see how any of that is relevant to the original comment I replied to: > But will Google allow this to happen, as it would strip them a huge selling point for Chrome? In what way would standardizing WebExtensions, which are already supported by all modern brows…

Chrome currently has the largest amount of extensions, which is an advantage for that browser. Standardized WebExtensions dilute that, because they allow easy ports to the other browsers.

I think the point is more, in what way does google have any power to stop other browsers from implementing this API?

Re: Browser Extensions Standard

#73

Post by Osmium »

It would be really nice if you could blacklist websites from using extensions in Safari, e.g. banking websites.

There are lots of useful extensions out there that would be nice to use, but I'm concerned if they became compromised (which happens regularly[1]) they might hijack my data.

Safari has a great feature that stops extensions from being able to read or transmit anything from websites you visit, which is great, but limits the effectiveness of a lot of ad blockers.

[1] https://news.ycombinator.com/item?id=14888010 (just 2 days ago!)

Re: Browser Extensions Standard

#74

Post by btrask »

greenhouse_gas wrote: post #58
avaer wrote: post #5

Hm, if web extensions become a standard, are they really even extensions? Isn't that just new web APIs with tweaked security parameters? This is great for security and all, but browser extensions were borne out of the idea that you wanted your browser to do things that the browser vendor didn't want, or didn't even conceive of. Having it be a standard adds security but strictly limits extensions to things the browser…

In general, if your software supports plugins, you can: 1. Have plugins with ultimate power (meaning that plugins can change everything, no encapsulation) 2. Stable API/ABI (meaning that plugins written for version 1 will work with version 2) 3. A refactorable code base. You can pick only two out of three. Traditionally, Firefox chose 1 and 2, and for stuck without multiprocess support for years (causing it to have w…

There is one plausible solution to this inequality: the Unix philosophy. Small parts, loosely coupled. Individual parts can't be significantly changed or removed, but they can be deprecated and better alternatives added. Because the parts themselves are small, they're less likely to have errors and replacing them is cheap.

Rich Hickey also has a talk on this. And there's also an overlap with CRDTs (basically you have a distributed system unless you can refactor everything atomically).

Re: Browser Extensions Standard

#75

Post by JadeNB »

mekkkkkk wrote: post #66
JadeNB wrote: post #41

Earlier quoted context omitted.

That sounds like a dream in many respects, but also, by analogy with the size of laptops where every part is customiseable and swappable, like it could be very, very slow or crash-prone. Much of the bugginess of Windows comes from its need to accommodate all possible combinations of bizarre hardware offerings; and much of the "It Just Works" of (some) Apple products comes from the tightly integrated nature of their t…

I don't really agree with that analogy. Dealing with hardware versus software is vastly different. Demanding driver updates from manufacturers, and then enforcing them onto users is real messy compared to changing an API (with reasonable heads up) and expecting extension developers to adhere or become incompatible.

> Dealing with hardware versus software is vastly different.

I agree; it's important not to read too much (which may be anything!) into the analogy. I just meant that there's a trade-off between flexibility and optimisation, and mentioned the first example of that trade-off that came to mind.

Re: Browser Extensions Standard

#76

Post by piyush_soni »

lewisl9029 wrote: post #71
piyush_soni wrote: post #9

The only problem which Mozilla didn't think about or hasn't given much value to is the huge number of add-ons that are going to die or just stop working when they completely switch to WebExtensions (as there's just no replacement to the previous API in them). One of the Firefox's USPs was its addons which could modify the browser behavior and UI in any manner. It's all going to go, and Mozilla is moving closer to bec…

For tab groups, take a look at Sea Containers: https://addons.mozilla.org/en-GB/firefox/addon/sea-container... It makes use of the new Containers experiment to provide a similar tab organization mechanism as TabGroups, and presents them in a vertical sidebar which IMO makes for a much saner workflow for heavier tab users. The identity encapsulation that comes by default with Containers might not be what you're lookin…

Though Containers are mutually separate in terms of the cookies etc. (they're more like the good old 'Profiles' that I still use for keeping my 'work', 'personal' and 'dev' work separate) this still looks interesting. Thanks.

Re: Browser Extensions Standard

#77

Post by gcp »

connorcpu wrote: post #72
gcp wrote: post #46

Earlier quoted context omitted.

Chrome currently has the largest amount of extensions, which is an advantage for that browser. Standardized WebExtensions dilute that, because they allow easy ports to the other browsers.

I think the point is more, in what way does google have any power to stop other browsers from implementing this API?

They don't. Unless you want to claim API's are copyrightable, but there are some downsides to that :-)

Re: Browser Extensions Standard

#78

Post by xg15 »

pzone wrote: post #61
syshum wrote: post #59

Earlier quoted context omitted.

Yes, Finally, all browser will be chrome clones, just what we need... Sad times indeed, when people celebrate mono-culture and the lack of options... W3C is leading effort to kill the Open Web and everyone is just clapping long... EME, Browser Extensions, what will be the next thing W3C will sell to its google overlords?

This is wild overreaction. Google is by far the market leader, they pump out innovations in this space, and their decision to work with others mimicing its APIs so that browser extensions can have a level of cross-compatibility is is perfectly nice and pro-competition as you could possibly ask for. I guarantee you if Edge had such a flourishing browser extension marketplace Microsoft would do everything in its power…

Yet the actual effect is that the Firefox' browser extension marketplace is severely reduced (by their own descision, admittedly) while Chromes' stays the same for the time being.

Re: Browser Extensions Standard

#79

Post by xg15 »

bzbarsky wrote: post #36
piyush_soni wrote: post #25

Earlier quoted context omitted.

Had they given it enough thought, they'd have pushed for replacement of XUL APIs in WebExtensions in a non-blocking way, for example. But they found killing all of the valuable add-ons of years worth of work of so many developers justified.

> 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)

Re: Browser Extensions Standard

#80

Post by piyush_soni »

bzbarsky wrote: post #36
piyush_soni wrote: post #25

Earlier quoted context omitted.

Had they given it enough thought, they'd have pushed for replacement of XUL APIs in WebExtensions in a non-blocking way, for example. But they found killing all of the valuable add-ons of years worth of work of so many developers justified.

> 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.
Post reply on HN