It’s called a browser extension, why call it web extension?
replies(6):
Most projects similar to Extension.js rely on some sort of abstraction or configuration to get started, making the initial development process slow given the extra learning curve and setup guidelines. By using Extension.js, adding the package to your npm scripts is all it takes to get started developing cross-browser extensions with no build configuration. Say goodbye to extensive configurations to create your next cross-browser extension!
Creating a new extension is super easy. This command will create a new extension named "my-extension" in the current working directory. In your terminal:
npx extension@latest create my-extension
You can also create an extension based on any extension hosted on GitHub. Just add the URL of the folder where the manifest is located and run `npx extension@latest dev <github_url>`. For instance, you can try the Chrome Sample "page-redder" (https://github.com/GoogleChrome/chrome-extensions-samples/tr...).
I first created this project as a way to teach others how to develop browser extensions, until I realized that a good amount of my teachings would involve setting up a new project. With Extension.js, the abstractions and configurations needed to create cross-browser extensions are handled by a simple command-line interface, allowing developers to focus on the actual development of their next extension.
Any feedback is appreciated. I've been using it for a while in personal projects but it is now mature enough for others to give it a go. I'm looking forward to hear what you all have to say! :D
Basically, until ~8 years ago, there were only three browsers of note with browser extension APIs (Chrome, Firefox, and Safari); and they were all proprietary and all different, so developers had to code each extension from scratch for each browser. And developers of major extensions mostly did.
But then Chromium-based browsers like Brave and Opera and Edge became a thing, and they all inherited de-facto support for what they at the time called "Chromium-style extensions." With this, the Chrome extension API effectively "won" the browser-extension-API developer-mindshare war without really meaning to. Developers became less and less interested in porting their extensions, instead opting to just focus on Chromium-based browsers, since not only was Chrome the majority of the market, but Chromium-based browsers comprised a large fraction of the remainder.
Rather than Mozilla and Apple "solving" this by coming up with some artificial new eleventh-hour browser-extension API standard to foist on Google through the WHATWG (that would have required every dev rewriting all their code), Mozilla and Apple both did the pragmatic thing, and "embraced and extended" Chrome's own extensions API, locking in "whatever Chrome was doing at the time" as now being a conventional cross-browser API. That API, going forward, was referred to in the Firefox and Safari docs — and eventually the Chrome docs as well — as the "WebExtensions API" (mostly so that Mozilla and Apple didn't have to say the words "Chrome" or "Chromium" anywhere in their docs.)
A browser saying that it supports the "WebExtensions API", means that it exposes certain browser-extension APIs in JS under the chrome.* namespace, with Chromium-compatible semantics. Yes, Firefox and Safari both present themselves as Chrome to browser extensions, up to and including answering to the name "chrome" rather than "browser" in JS. Wild, isn't it?
Note, however, that these browsers do still also expose their original, incompatible extension APIs under the browser.* namespace. And if you write your JS carefully, you can attempt to make use of these per-browser features in your extension, while gracefully degrading to a WebExtensions baseline.