Live data from Hacker News

Browser Extensions Standard

browserext.github.io

41–50 of 82 posts

Re: Browser Extensions Standard

#41

It would be interesting to have a browser where every part except the engine is an extension. I.e. hotkeys, address field, bookmarks and so on being standardized, replaceble extensions, run in a chromeless window. An infinitely hackable experience. Prepackaged bundles could ship as discreet browsers, for the less techy user.

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 technology stacks.

Re: Browser Extensions Standard

#42
post #31

Part of the reason why we have different browsers is the variety of features they support. A browser extension inherently is closer to the unique part of browsers that make them different. What value does this really provide? The times that I've gotten into browser extensions were really working with features that are unique to the given browser.

There's an argument that while rendering engines are huge, monolithic undertakings, the actual browsers wrapped around them are fairly trivial. Assuming they use the same rendering engine under the hood, a relatively lightweight, tightly integrated platform-native browser (i.e. Safari or Gnome Web) might be a better user experience than a cross-platform behemoth like Chrome.

Extension support and depth of extension library have traditionally been the big pain point with switching to a minority browser. Moving extension support into a browser independent standard removes a lot of the selective pressure toward a monoculture.

Re: Browser Extensions Standard

#43

It would be interesting to have a browser where every part except the engine is an extension. I.e. hotkeys, address field, bookmarks and so on being standardized, replaceble extensions, run in a chromeless window. An infinitely hackable experience. Prepackaged bundles could ship as discreet browsers, for the less techy user.

One problem with this is that if extensions need to be sandboxed from the user, the browser, and each other. Therefore you'r proposing running a process for each part of the browser.

Re: Browser Extensions Standard

#44

It would be interesting to have a browser where every part except the engine is an extension. I.e. hotkeys, address field, bookmarks and so on being standardized, replaceble extensions, run in a chromeless window. An infinitely hackable experience. Prepackaged bundles could ship as discreet browsers, for the less techy user.

Well, that sounds like the historical Firefox. If you look at the source code of Firefox, just about everything except Gecko is a XUL add-on. Worked like a charm for the first 10 years, not so much afterwards because it became a maintenance nightmare.

That's actually the main reason for which Firefox is moving away from XUL add-ons and towards more restricted WebExtensions.

Re: Browser Extensions Standard

#45

Does anybody know whether the Google Chrome / Chromium team and the Mozilla team are squarely behind this standardization effort? What about the Apple Safari team? There's only one rep from Google in the community group. There don't seem to be any from Apple. [1990s paranoia mode] this could be another Microsoft effort to embrace and suffocate [/1990s paranoia mode]

I made an extension to appease a slight reddit addiction: "What's new reddit?" https://github.com/mrspeaker/whats-new-reddit/ it highlights updates and auto-refreshes things. I wrote it for Firefox, and then I wondered what it would take to port it to Chrome. The answer was "nothing really" - it worked out of the box for the main functionality. I had to do a small wrapper over loading settings, but having done a mill…

> The answer was "nothing really" - it worked out of the box for the main functionality.

Do you mean Chrome supports Promises like Firefox does? Last time I checked, the Chrome APIs were using callbacks for all asynchronous operations.

Re: Browser Extensions Standard

#46
post #22

Earlier quoted context omitted.

It can. But it can't keep XUL compatibility and do major overhauls of the browser. If XUL compatibility doesn't even get you a clear advantage in the add-ons area, should it block modernizing the browser? Firefox can't be the browser that people use only because they're stuck on it because they have extensions that changes how the browser works. Think about that for a bit.

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.

Re: Browser Extensions Standard

#47

It would be interesting to have a browser where every part except the engine is an extension. I.e. hotkeys, address field, bookmarks and so on being standardized, replaceble extensions, run in a chromeless window. An infinitely hackable experience. Prepackaged bundles could ship as discreet browsers, for the less techy user.

Sounds like Atom. It would probably have terrible performance issues.

Re: Browser Extensions Standard

#48
post #28

As a developer, I'd really like if I could publish an extension as a single archive file and have users load it into whatever (compliant) browser they like - however, the standard doesn't seem to actually support this. When it comes to packaging, there is nothing more than a vague acknowledgment: Browser extensions MAY be distributed and subsequently loaded as individual files or via a container, such as a .zip archi…

Unfortunately that would be practically difficult with Chrome only allowing extensions downloaded from the Chrome Web Store.

Re: Browser Extensions Standard

#49
post #2

Finally! WebExtensions ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions ) have slowly been becoming an adhoc standard for a little while now, but with a few tricky small differences here and there between browsers (e.g. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Ch... ). So far it's just been Firefox and Edge slowly building a close approximation of Chrome's existing API, but a proper standa…

I'm not very involved, but on top of the Chrome base API both Firefox and Edge have a bunch of additional APIs IIRC (I think Firefox supports all of the Chrome APIs but I'm not sure). The intent is to have the same manifest format so basic extensions work everywhere, but extensions can use browser-specific APIs that fit within the same general framework too.

Re: Browser Extensions Standard

#50
post #48
post #28

As a developer, I'd really like if I could publish an extension as a single archive file and have users load it into whatever (compliant) browser they like - however, the standard doesn't seem to actually support this. When it comes to packaging, there is nothing more than a vague acknowledgment: Browser extensions MAY be distributed and subsequently loaded as individual files or via a container, such as a .zip archi…

Unfortunately that would be practically difficult with Chrome only allowing extensions downloaded from the Chrome Web Store.

The package format could apply to how extensions are deployed to the store at least.

Also, I know it's possible to run third-party extensions in developer mode.

Post reply on HN