Live data from Hacker News

Browser Extensions Standard

browserext.github.io

61–70 of 82 posts

Re: Browser Extensions Standard

#61
post #59
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…

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 to prevent the other browsers from allowing easy portability.

Re: Browser Extensions Standard

#62

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]

Mozilla is pretty much pioneering this effort.

They've been looking to replace the current extension model for years, as it's not even really an API, it's mostly just a way for people to fuck around with Firefox's source code. Powerful, but unwieldy and extensions break all the time, if Mozilla changes anything.

Well, and one idea in that process was to not write a new extension API from scratch, but rather use the proven API from Chrome, which therefore will also make the transition much less painful, as a good portion of Chrome extensions will get ported over and we're not starting at square one with the extension ecosystem.

Also, they recently introduced multi-process which breaks all extensions anyways, so they're pushing hard to get WebExtensions done, as it means that add-on authors can just port directly to WebExtensions and don't have to port to multi-process-compatible first.

And if Chrome continues to eat up market share and extension developers lose interest in Firefox, this will also help out, as the effort of porting from Chrome to Firefox is now often trivial.

So, yeah, Firefox 57 will exclusively run WebExtensions, which is Nov 14.

Microsoft mostly just saw what Mozilla is doing, figured that they still needed an extension system to get Edge fit for competition and figured that complying to the standard for once would get their extension ecosystem quicker up to speed.

As for Google, well, I assume they are not particularly excited about Mozilla embracing and extending their extension API, as well as Microsoft having a slice from their cake, too, but it's not like Chrome was in any danger of competition...

Re: Browser Extensions Standard

#63
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.

Well, the APIs that make sense for various browsers can be shared by those browsers. The APIs that are specific won't be.

For example, Chrome doesn't support sidebars. Opera does. So, Opera constructed a sidebar API. Then came along Mozilla, also wanted to have sidebar, and so they adopted Opera's sidebar API, allowing extension authors to easily support Firefox and Opera.

They can't support Chrome, but it's not like people didn't previously already write sidebar extensions when they could only support one browser at a time.

Re: Browser Extensions Standard

#64
post #61
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…

Pointing to another company and saying "Well they would be more evil" is not IMO a valid defense.

Just because Microsoft is more anti-competitive than Google does not change anything I said

Re: Browser Extensions Standard

#65

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.

Isn't the problem with Electron that any app built with it spawns a full browser runtime? Doesn't seem to be a problem if the app in question is in fact a browser. More like a necessity really.

Re: Browser Extensions Standard

#66
post #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 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.

Re: Browser Extensions Standard

#67
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.

> I think Firefox supports all of the Chrome APIs but I'm not sure

They support quite a few but not all. in addition there is a promise based version of each of the APIs that you can use in firefox under the browser namespace instead of the chrome namespace. (with a polyfill on npm too if you want that in chrome)

Re: Browser Extensions Standard

#68

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…

They are planning on supporting the necessary functions required to port those types of extensions over to webextensions... see [0]

0. https://bugzilla.mozilla.org/show_bug.cgi?id=1384515#a545216...

Re: Browser Extensions Standard

#69
post #45

Earlier quoted context omitted.

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.

There is a polyfill written by mozilla devs that port the browser namespace and promise based api calls over to chrome if needed.

https://github.com/mozilla/webextension-polyfill

Re: Browser Extensions Standard

#70
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…

Firefox tries to minimize breaking API changes, but there have certainly been plenty of them. While avoiding API changes presumably made the switch to multiprocessing more difficult, it didn't stop it; they made the switch. The fundamental problem with extensions and multiprocessing (at least from the perception of someone who wrote FF extensions) is the obvious one: Rather than having everything for all windows in a single thread, now you have them in different processes; communication goes from literally nothing to IPC.
Post reply on HN