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 vendors explicitly did conceive of, and stamped their approval on -- sometimes literally, if you're going through a curated store. Is that a net win? I'm not sure.
> Hm, if web extensions become a standard, are they really even extensions? Isn't that just new web APIs with tweaked security parameters?
The main difference is that the user installs an extension, which possibly modifies the behavior of the browser for all websites. A traditional web API only takes effect if the page that the user visits makes use of that API.
> if web extensions become a standard, are they really even extensions?
They're browser extensions, not web extensions. If standardised, then arguably they will be a native part of the web stack, yes.
> strictly limits extensions to things the browser vendors explicitly did conceive of, and stamped their approval on
That's the situation today anyway. The new standard won't change that. Browser vendors may opt to follow the new extensions standard as a 'baseline' feature set, and provide further non-standard options on top of it.
Most extension APIs follow common patterns, and this standard paves those cowpaths. The standard needn't predict all future extension needs to be useful today. For comparison, the DOM is a standard, but individual browser vendors still experiment with their own custom DOM features, and these experiments sometimes get 'merged in' to the standard. Meanwhile, authors benefit from having a well defined set of features that work across platforms. Standardisation doesn't need to be final or absolute to be useful.
While I as a developer greatly appreciate creating things with the new WebExtensions APIs over old Firefox XUL thingies, I can see how they severely limit my capabilities. If the browser says "You can't do that", I can't do that.
And based on that, you don't have to look too hard into the Firefox userbase to find out that quite a lot people have an answer for your question: "No"
(Background: Firefox is going WebExtensions only in a near upcoming release. Not everyone is thrilled about that)
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 worse performance and security), and now wants to move to 2 and 3.
Incidentally, I suspect that's _one_ of the reasons Linux doesn't have a stable Kernel ABI - they chose 1 and 3.
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).
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.
That's a common set of features every browser should support. Because doesn't make sense to have various techniques to achieve simple behaviors like a toolbar button.
Browsers can add their own brand new features, the specs are just for the minimum.
Another perspective would be that a standardized browser extension api means you're not locked into browsers via "essential" extensions. Though, while I do like removing locking, I'm not sure if that is a bigger concern than what you cite.
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 vendors explicitly did conceive of, and stamped their approval on -- sometimes literally, if you're going through a curated store. Is that a net win? I'm not sure.