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.
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.
The vendors are using both terms. See, for example, the text at the end of this url, and both terms in the text.
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)
Consider WebExtensions Experiments: https://webextensions-experiments.readthedocs.io/en/latest/w...
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.
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).
Browsers can add their own brand new features, the specs are just for the minimum.
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.