_______ __ _______ | |
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----. | |
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --| | |
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____| | |
on Gopher (inofficial) | |
Visit Hacker News on the Web | |
COMMENT PAGE FOR: | |
Show HN: I made a CLI tool to create web extensions with no build configurati… | |
cantSpellSober wrote 1 day ago: | |
s | |
satisfice wrote 1 day ago: | |
I'm confused. I've written an extension, already (just for Chrome, all | |
Javascript). Getting started was simply a matter of copying a few files | |
from the Chrome extension documentation site. I haven't done anything | |
to configure an IDE, but I don't know what I should want to do. | |
I'm trying to understand what your tool does, above and beyond copying | |
a few files. Is it cross-browser support? multi-language support? | |
cezaraugustodev wrote 1 day ago: | |
In your case, Extension.js can help by managing the configuration | |
details that are usually overlooked in general web development. | |
After copying a few files from the Chrome extension documentation | |
site, you'll need to manually enable "developer mode" in your browser | |
and add these files. If you make changes to your code, seeing the | |
updates live requires manually reloading the various contexts that a | |
browser extension can influence. Additionally, if you want to test | |
your extensions on multiple browsers, you must do this manually for | |
each one. | |
If you plan to use package dependencies like TypeScript or a | |
JavaScript framework, you'll either have to rely on an existing | |
abstraction framework for extensions and learn new techniques, or | |
create your own configuration using tools like webpack, Parcel, | |
esbuild, or another code compiler. At this point, developing browser | |
extensions can become complex and frustrating. | |
Extension.js simplifies this by automating the process of bundling an | |
extension in a browser ready for development. It comes with | |
auto-reload support for every context, including parts of the browser | |
that are not HTML/CSS/JavaScript. It also has built-in support for | |
code dependencies such as TypeScript and React, where a simple | |
installation enables your extension to have support without any setup | |
wizardry. And it runs on multiple browsers at once. | |
Hope that clarifies things, and I'm happy to answer more questions :) | |
kosolam wrote 1 day ago: | |
Need to change the title itâs browser extensions not | |
Web extensions. | |
sureIy wrote 1 day ago: | |
Thatâs wrong: | |
[1]: https://github.com/w3c/webextensions | |
kosolam wrote 10 hours 21 min ago: | |
Please read these quotes from these links to better understand why | |
itâs not wrong. | |
âExtension is a plug-and-play, zero-config, cross-browser | |
extension development tool for browser extensions with built-in | |
support for TypeScript, WebAssembly, React, and modern | |
JavaScript.â | |
âWebExtensions are a way to write browser extensions: that is, | |
programs installed inside a web browser that modify the behavior of | |
the browser or web pages loaded by the browser. WebExtensions are | |
built on a set of cross-browser APIs, so WebExtensions written for | |
Google Chrome, Opera, or Edge will, in most cases, run in Firefox | |
too.â | |
rantymcrant wrote 1 day ago: | |
This may be very cool but I'm here to rant | |
What is it with "I made a _______" posts? Those seem new to me and very | |
braggy. I see them on youtube as well. I feel like if I could check all | |
the posts to HN I'd find a trend of instead of just "Show HN: A | |
tool/app/site to do X" there's a tread of adding "I made" in front. Is | |
that a result of social media conditioning, that you must brag that "I" | |
made? | |
fragmede wrote 1 day ago: | |
[1] is the oldest one I could find via the algolia search at the | |
bottom of the page, from 2010, so it's not that recent a phenomenon. | |
A different reading is less that the emphasis is on I made a thing, | |
and more about being a complete sentence with an explicit subject vs | |
implicit. | |
[1]: https://news.ycombinator.com/item?id=1381172 | |
rantymcrant wrote 1 day ago: | |
Checking the years those types of post have increased several X | |
over a few years ago (the year starting april 1st) | |
2023 416 | |
2022 307 | |
2021 232 | |
2020 252 | |
2019 158 | |
2018 87 | |
2017 42 | |
2016 45 | |
2015 39 | |
2014 42 | |
2013 68 | |
2012 40 | |
2011 28 | |
2010 10 | |
That's just "Show HN: I made" and doesn't include all the similar | |
"I built ..." and similar braggy titles. | |
fragmede wrote 22 hours 11 min ago: | |
I don't have a problem with people bragging about a thing they | |
made. I think if someone spent a bunch of time on a thing, I'll | |
give them time to be proud of the work they did and give them | |
space to show off. | |
if it's something I'm interested in. The difference between | |
"ShowHN: I built a thing", and "ShowHN: thing" seems | |
inconsequential to me. | |
But you know that one about how naming things is an unsolved | |
problem in computer science? Looking at random search results, I | |
think it's more about it being a more natural way to describe | |
something. "Show HN: I built a thing that does blah", rather than | |
"Show HN: Foobar, a thing that does blah". | |
If I do "Show hn: George", what's George? vs "Show HN: I made a | |
thing that does foo called George" | |
Interestingly enough, there are only 805 results for "Show HN: | |
We" vs 5,060 results for "Show HN: I", What a bunch of loners we | |
are. | |
rantymcrant wrote 13 hours 47 min ago: | |
I see "I made X that does Y" as self promotion. You're not | |
prmmoting X, your prmoting the fact that "I" made it. You're | |
smart. People should take you seriously. They should offer you | |
jobs and/or praise. Of course you're secondarily promoting X | |
but only in the cause of promoting yourself | |
I see "X, an app that does Y" as promoting X and sayuhg | |
"reader, you might find X useful if you want to do Y" | |
The purpose of the posts are entirely different. | |
Your observation on "We" is interesting though I suspect that | |
teams are more likely to write "X, and app that does Y" because | |
"We made X" doesn't achieve the self promotion goals in the | |
same way as "I made X" | |
saghm wrote 1 day ago: | |
I can't speak for youtube given that I don't really actively browse | |
it, but I'm not sure how it's "braggy" when the entire purpose of | |
"Show HN" is to demo things that were made by the person posting it ( | |
[1] ): | |
> Show HN is for something you've made that other people can play | |
with. | |
At most, it's redundant, but not in a way that hurts anyone. | |
[1]: https://news.ycombinator.com/showhn.html | |
hhimanshu wrote 1 day ago: | |
This is good project. I built my first chrome extension using [1] and | |
there was lot of fiddling to et styles working. | |
This could also be because this is my first browser extension | |
development. [2] There is still lot more work to do, so I will checkout | |
your project. Thanks for sharing! | |
[1]: https://crxjs.dev/vite-plugin/getting-started | |
[2]: https://chromewebstore.google.com/detail/bettermenu-for-doorda... | |
cezaraugustodev wrote 1 day ago: | |
That's great! I'm glad you will give it a try | |
msephton wrote 1 day ago: | |
Just added an issue: Safari support should be relatively | |
straightforward using Apple's safari-web-extension-converter cli tool. | |
cezaraugustodev wrote 1 day ago: | |
Thanks for that! | |
gerroo wrote 1 day ago: | |
Absolutely amazing! When I was developing a chrome extension all I | |
could think of was a severe lack of dev-tools. I'll try it when I get | |
the opportunity. | |
cezaraugustodev wrote 1 day ago: | |
Thank you! The ecosystem for developing extensions could be so much | |
better, hope we can help with that | |
dotproto wrote 1 day ago: | |
Would love to hear your thoughts on how to improve it ;) | |
aaronharding wrote 1 day ago: | |
Okay I love it, I feel like you should also sprinkle your magic on | |
extension<>tab communication. Whenever I make an extension, it's always | |
such a pain to read from the DOM or send a message from the extension | |
to the active tab. | |
dotproto wrote 1 day ago: | |
Can you share more about what you find frustrating or confusing about | |
this process? | |
nullandvoid wrote 1 day ago: | |
Plasmo has a messaging library you might want to explore | |
[1]: https://docs.plasmo.com/framework/messaging | |
cezaraugustodev wrote 1 day ago: | |
Haha, thanks! Itâs not in the immediate plans, but meanwhile, I'm | |
sure there are some good libraries on npm for that :) | |
from-nibly wrote 1 day ago: | |
Ive made a few extensions. One was silly and changed the imgur heart | |
color when they changed it and everyone was upset. | |
Every time i make a chrome extension i get massive imposter syndrome. | |
It is so hard to create a new project for some reason. This would be | |
awesome. | |
cezaraugustodev wrote 1 day ago: | |
Totally relate. Extension development should be fun, right? Hope | |
Extension.js can help you with your next project! | |
lagniappe wrote 1 day ago: | |
Wow this is cool, thank you :) I look forward to trying this out on a | |
little hobby extension I'm working on as well. | |
cezaraugustodev wrote 1 day ago: | |
I'm glad to hear! | |
simple10 wrote 2 days ago: | |
This is exactly what I need right now. Thanks for building and sharing | |
it! Looking forward to Firefox support. I hope you can get it working. | |
Firefox Support Issue: | |
[1]: https://github.com/cezaraugusto/extension.js/issues/5 | |
Vinnl wrote 2 days ago: | |
In particular, navigating the conflicting requirements for | |
`manifest.json` would be useful, e.g. the difference between event | |
pages and background service workers, or permissions that are | |
inconsistently required/forbidden. | |
cezaraugustodev wrote 1 day ago: | |
That's interesting, what do you mean? An abstraction for the | |
manifest apply dev defaults or instructions on how each major part | |
should work? | |
dotproto wrote 1 day ago: | |
I don't know exactly what the the person you're replying to had | |
in mind, but support for different parts of the manifest varies | |
(especially in Manifest V3). While it's possible to write a | |
single manifest that works in all browsers (with warnings), doing | |
so requires more than a little specialized knowledge. | |
For example, Firefox does not currently support the | |
`optional_host_permissions` top level manifest key. To work | |
around this, developers can declare their optional host | |
permissions in both the `optional_host_permissions` array for | |
Chrome compatibility and in the `optional_permissions` array for | |
Firefox/Safari compatibility. | |
Another example is that currently only Chrome supports | |
`background.service_worker` in stable releases. To work around | |
this, developers can write their MV3 background scripts in a way | |
that's compatible with both service workers and event pages, then | |
declare both in the manifest like so: | |
```json | |
{ | |
"background": { | |
"scripts": ["background.js"], | |
"service_worker: "background.js" | |
} | |
} | |
``` | |
simple10 wrote 2 days ago: | |
It would be great if you could add more details to the Firefox | |
support issue in github. Maybe the community could help solve it? | |
cezaraugustodev wrote 2 days ago: | |
The plugin for Firefox is on the way, but any community support is | |
highly appreciated. | |
masto wrote 2 days ago: | |
I've made a couple of (admittedly trivial) Chrome extensions to tweak | |
things on sites I use. I didn't really spend any time configuring the | |
compilation config (not sure what that is) or frameworks. I'm guessing | |
the reason for needing something like this is for handling complicated | |
dependencies and cross-platform stuff? | |
The main issue I've run into is that I have no idea how to hook into | |
and modify the behavior of fancy modern web sites with all of their | |
React and Angular and Snorfleflox. I was kind of hoping this was for | |
that. Is there some sort of framework that makes that stuff easier, or | |
failing that, a really good tutorial for an experienced but a little | |
out of date web developer to get up to speed? | |
insin wrote 1 day ago: | |
> The main issue I've run into is that I have no idea how to hook | |
into and modify the behavior of fancy modern web sites with all of | |
their React and Angular and Snorfleflox. I was kind of hoping this | |
was for that. Is there some sort of framework that makes that stuff | |
easier, or failing that, a really good tutorial for an experienced | |
but a little out of date web developer to get up to speed? | |
I've written extensions (L I N K S I N B I O) which significantly | |
modify Twitter.com (which uses React Native for Web) and YouTube | |
(which uses web components), which are both SPAs - the main tips I'd | |
give are: | |
1. Which page am I on? | |
In an MPA extension or userscript, you just check the current URL and | |
go. In an SPA, you could go as far as patching the pushState() method | |
on History (although you can't do this from an extension's content | |
script - you would need to inject a page script) and watching for | |
popstate events to detect URL changes, but I've found using a | |
MutationObserver [1] to observe the contents of to be a simpler | |
proxy for the current page changing. | |
When the changes, check the current URL to see if it's one you've | |
already handled, and if not, start making your modifications. This | |
also gives you a natural place to put any teardown logic, such as | |
disconnecting active observers and cancelling any async actions which | |
may be in progress for the previous page, such as waiting for | |
elements to appear. | |
The target app may even have custom events you can hook into. YouTube | |
has these, for example, but I found they were being fired at the same | |
time the was being changed whenever the user was navigating to a | |
different page, so I stuck with the implementation-independent | |
approach. | |
2. When are the main elements I care about available? | |
You'll need some utility functions which allow you to wait for | |
specific elements to be available in the current page, either as an | |
indicator the page is ready to modify, or because you need to do | |
something with their contents. | |
This could be as un-smart as writing a function which returns a | |
Promise wrapping document.querySelector() calls at regular intervals, | |
or uses a MutationObserver to wait for a specific element to appear, | |
then resolves with it, but there should be lots of existing open | |
source utilities like these available out there (some have already | |
been linked to in this thread). | |
I ended up writing my own version of these so I could specifically | |
control stopping waiting for an element based on a timeout and/or | |
other conditions, e.g. immediately resolving the Promise with `null` | |
if the current URL has changed at the next available interval. | |
3. When do the elements I care about change? | |
Use the MutationObserver API [1] to watch for child elements being | |
added/removed, or for specific attributes being changed. | |
It's kind of clunky, so you may want to write your own convenience | |
wrapper - this is also a natural place to facilitate storing active | |
observers for a later teardown. I've found I usually end up with at | |
least a pageObservers collection, which makes it easy to disconnect | |
everything which is currently being observed when the page changes. | |
e.g. I use a MutationObserver on the element which contains Twitter | |
timeline contents to watch for the current window of visible tweets | |
being changed so I can do things like hide quotes of specific tweets | |
or hide Retweets from the Following timeline. | |
4. Hiding things in an SPA-friendly way | |
Removing elements which UI libraries such as React expect to be under | |
their control when some state changes at a later time can lead to | |
errors, so I've found it best to use CSS where possible to hide | |
things, and even adding your own class names to use as styling hooks. | |
It can also just be more convenient than writing code to manually | |
remove things from the DOM. | |
e.g. Twitter uses React Native for Web's styling system, which takes | |
CSS-like style objects and generates utility-like style rules from | |
them (it's like Tailwind in reverse) - this means there aren't any | |
developer-friendly class names to use as styling hooks, so on some | |
pages I add my own. If I open my own user profile, will have | |
'Profile' and 'OwnProfile' classes on it, which I can use to hide the | |
"Articles" and "Highlights" tabs, which are there purely as Premium | |
upsells. | |
[1]: https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... | |
sfink wrote 1 day ago: | |
I haven't done a lot of userscript dev, but based on my experience | |
so far, all of this advice is spot-on. | |
I found it useful to create a `waitForElement(query)` helper | |
function that takes a CSS selector path and returns a Promise that | |
resolves when the query starts finding a match in the DOM. | |
(Internally, it's just populating a table that is iterated over in | |
the MutationObserver callback.) | |
As for SPA "navigation", I had trouble with popstate events. I | |
hadn't considered your trick; I'll bet that would have worked for | |
me! Right now, I'm polling window.location.href every half second, | |
which sucks. | |
cezaraugustodev wrote 2 days ago: | |
Extension.js can help you creating a new extension using React in no | |
time: | |
npx extension create my-react-extension --template=react | |
But I guess it doesn't make it any easier to modify the behavior of | |
fancy modern web sites :_( | |
grimgrin wrote 2 days ago: | |
The best luck Iâve had with SPA apps and a goal of manipulating the | |
DOM is by using mutation observers. Worth exploring if you havenât | |
yet [1] You can hack on the behavior via userscripts, my preferred | |
way to alter websites, though I write extensions too (greasemoney is | |
good tho) | |
[1]: https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... | |
rsoto wrote 2 days ago: | |
IMO MutationObserver's API is a bit difficult to grasp. For simpler | |
cases for getting a callback when an element is created, I use | |
spect[1] or sentinel[2]. | |
1: [1] 2: | |
[1]: https://github.com/dy/spect | |
[2]: https://github.com/kubetail-org/sentineljs | |
sfink wrote 1 day ago: | |
You can wimp out and just use MutationObserver as a way to get a | |
callback whenever anything changes, ignoring all of the mutation | |
records. Then in the callback, look up all of the elements you | |
care about. The API is pretty simple then. It may be less | |
efficient, but usually when you're mucking about with existing | |
web pages, you're not all that performance sensitive. (And MO | |
batches up updates reasonably well, so it's not like you're | |
running the callback once per change.) | |
Occasionally it might even be faster, since you're not iterating | |
through the mutation | |
records and testing for stuff you care about. | |
grimgrin wrote 1 day ago: | |
yeah that's exactly how I've done it -- observe the highest | |
order container I care about (document.body lazy mode) | |
outlore wrote 2 days ago: | |
this is cool! how would you contrast this with Plasmo, a similar | |
framework? | |
[1]: https://www.plasmo.com/ | |
cezaraugustodev wrote 2 days ago: | |
Great question! | |
The biggest difference, in my opinion, is that Plasmo is a framework, | |
which means you have to learn its abstractions and rely on specific | |
samples tailored for these abstractions to create new extensions. | |
There are config files and specific rules to follow that are not | |
necessarily related to browser extensions. | |
On the other hand, Extension.js allows developers to create | |
extensions using the standard extension APIs and abstracts only the | |
configuration files, without the need to learn the tooling specifics. | |
This way, a sample from Chrome or MDN that works with a manifest file | |
as the source of truth requires no refactoring to work with | |
Extension.js, making it easier to get started and prototype new | |
projects. | |
selalipop wrote 1 day ago: | |
Iâve used Plasmo without touching their framework (essentially | |
using it for HMR and bundling) and it works pretty well | |
But itâs never a bad thing to have two projects solving a painful | |
problem | |
simple10 wrote 2 days ago: | |
Plasmo looks extremely useful. Have you used it to develop any | |
extensions? | |
bluelightning2k wrote 1 day ago: | |
I use Plasmo. Strongly recommend it. So much so I gave them a | |
shout-out in a blog post just this Sunday ( [1] ). | |
I don't really use the framework stuff but HMR that works really | |
well is just chefs kiss. | |
[1]: https://moddable.app/blog/unofficial-mod-support | |
spxneo wrote 2 days ago: | |
I use it and it does a lot of what I used to do manual deployment | |
so I was wondering the same thing as GP, could this be a | |
self-hosted plasmo of sorts | |
_andrei_ wrote 2 days ago: | |
very cool, also check out | |
[1]: https://www.plasmo.com/ | |
chadrs wrote 2 days ago: | |
Iâve been pretty happy with web-ext, Iâm curious what abstractions | |
and configurations Extensions.js avoids comparatively. Iâm assuming | |
youâll still need a manifest.json, and it looks like both use | |
npm/package.json for dependencies. | |
[1]: https://github.com/mozilla/web-ext | |
cezaraugustodev wrote 2 days ago: | |
Yes, the manifest.json is a required file for all extensions, and the | |
package.json file provides necessary package metadata. | |
web-ext is excellent, but it seems there are no plans for the project | |
to support more browsers than it currently does. On the other hand, | |
Extension.js plans to support all major vendors. | |
Except for Firefox support, which is in progress, I believe | |
Extension.js offers parity with all core functionalities of web-ext, | |
but it goes further by providing built-in support for React and | |
TypeScript. All you need to do is add the correct dependencies to get | |
up and running. | |
Additionally, Extension.js provides comprehensive extension reload | |
support, including changes to the manifest.json file and the | |
service_worker background. This feature sets it apart from similar | |
tools, including web-ext, which do not offer this capability. | |
rmdes wrote 2 days ago: | |
well... you just gave me a reason to rebuild my Bluesky extension from | |
scratch, without a dependency from the original extension I used to get | |
my base opengraph running. Bluesky OGraph Poster | |
cezaraugustodev wrote 2 days ago: | |
Haha glad to hear that | |
avtar wrote 2 days ago: | |
Minor feedback: please consider an option to exclude emojis from the | |
cli output. I can appreciate wanting to add some character here and | |
there, but the output of ``npx extension create my-extension`` seems | |
very noisy. | |
cezaraugustodev wrote 2 days ago: | |
That's great feedback, thank you. Will consider the removal. | |
notum wrote 2 days ago: | |
Apologies for the confusion but what is "cross-browser" about this tool | |
if it only works with chromium? | |
purple-leafy wrote 1 day ago: | |
Agreed. It would be more fair to call it chromium only. I donât | |
consider that cross browser as any chrome extensions defacto works on | |
any chromium browser | |
cezaraugustodev wrote 1 day ago: | |
Safari and Firefox are next, feel free to subscribe to the issues | |
below so you know when Extension.js supports them. | |
- Safari [1] - Firefox | |
[1]: https://github.com/cezaraugusto/extension.js/issues/46 | |
[2]: https://github.com/cezaraugusto/extension.js/issues/5 | |
cezaraugustodev wrote 2 days ago: | |
No worries :) but Chrome and Edge are indeed different browsers. | |
Support for Firefox and Safari is next. | |
notum wrote 2 days ago: | |
Not to take away from the simplicity of use, of course, totally | |
giving it a go. I think this is an awesome foot in the door for | |
people who never considered developing extensions. | |
Firefox would be a MASSIVE win! | |
ViktorBash wrote 2 days ago: | |
Looks good! I'll give this a swing on my own extension Vim for Docs. | |
Firefox not being supported is a bummer, but it's not like there is a | |
build tool for extensions that does support both Firefox and chromium | |
based browsers. | |
cezaraugustodev wrote 2 days ago: | |
Thanks! Firefox support will come in the next update. Stay tuned! :) | |
mrozbarry wrote 2 days ago: | |
I totally understand why, but no firefox support is a show-stopper for | |
most extension developers. | |
thenbe wrote 2 days ago: | |
FWIW there's an existing issue for "firefox support" which you can | |
subscribe to in order to be notified when this feature lands. | |
[1]: https://github.com/cezaraugusto/extension.js/issues/5 | |
cezaraugustodev wrote 2 days ago: | |
Sure thing! There will be support for Firefox very soon | |
mvkel wrote 2 days ago: | |
This is extremely cool. Even the readme is beautiful! | |
I'm going to give this a try. I've been holding off on adding an | |
extension to my app because of the absolute cluster that is Google | |
Play. | |
dotproto wrote 1 day ago: | |
Chrome extensions are published on Chrome Web Store ( [1] ), not on | |
Google Play. | |
[1]: https://chromewebstore.google.com | |
mvkel wrote 16 hours 10 min ago: | |
Sorry! Different name, same cluster :) | |
cezaraugustodev wrote 2 days ago: | |
Thank you! I'm glad you liked the readme as well :D | |
blackhaj7 wrote 2 days ago: | |
This looks really helpful - thanks! | |
cezaraugustodev wrote 2 days ago: | |
Thanks for the kind words! | |
edwinjm wrote 2 days ago: | |
Itâs called a browser extension, why call it web extension? | |
derefr wrote 2 days ago: | |
"WebExtensions API" is the genericized term coined by (IIRC) Mozilla, | |
for the (subset of the) originally-proprietary browser extension API | |
surface exposed by Chrome, that non-Chromium browsers (Firefox, | |
Safari) have since added support for in order to be able to support | |
easy porting of originally-Chrome-targeted extensions. | |
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. | |
PurpleRamen wrote 2 days ago: | |
Because this specific browser extensions are named WebExtensions[1] | |
[1]: https://www.w3.org/community/webextensions/ | |
cezaraugustodev wrote 2 days ago: | |
HN has a character limitation for the post title and changing the | |
word made the title fit just fine :) | |
jonathanlydall wrote 2 days ago: | |
100%, I was also initially confused by the term web extension, itâs | |
a browser extension. | |
thrdbndndn wrote 2 days ago: | |
It has often been called "WebExtensions" or "WebExt" for a long time | |
[1]. | |
I wasn't even aware that it's just referred as "browser extensions" | |
on MDN [2] now (..and the URL still uses "WebExtensions" and it's all | |
over the actual article content. So I don't know.) | |
To me, 'WebExt' represents a specific specification within the | |
broader category of browser extensions. However, since all major | |
browsers now support this specification (and this only), it has | |
become the de facto standard. | |
I hope someone more familiar with this topic can provide a more | |
precise explanation [1] | |
[1]: https://developer.mozilla.org/en-US/docs/Glossary/WebExtensi... | |
[2]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... | |
herrherrmann wrote 2 days ago: | |
Very cool stuff! I might check this out for my extension ( [1] ). So | |
far, Iâve been creating my own scripts to manage the extension | |
builds, dev mode etc. â but Iâve been eyeing web-ext already to | |
make my life easier. However, my main browser is Firefox, which | |
doesnât seem fully supported yet by Extension, right? | |
[1]: https://github.com/herrherrmann/omnivore-list-popup | |
cezaraugustodev wrote 2 days ago: | |
Thanks a lot! | |
You can run your Mozilla Add-On on Chrome or Edge by adding a | |
--polyfill flag, but for now you need to manually add the extension | |
to Firefox. I do plan to support Firefox in the near future, but no | |
browser runner available at the moment. | |
isodev wrote 2 days ago: | |
Looks interesting but I donât understand why Safari is excluded on | |
both desktop and mobile. | |
bpev wrote 2 days ago: | |
fwiw, in my experience, Safari is a much bigger annoyance to release | |
extensions on than all the other platforms, and has the more | |
differences is release process. So I'd expect this browser to be | |
supported last. | |
cezaraugustodev wrote 1 day ago: | |
FYI There is a new issue to track progress and enable Safari | |
support | |
[1]: https://github.com/cezaraugusto/extension.js/issues/46 | |
cezaraugustodev wrote 2 days ago: | |
Thanks! I do plan to support all major browsers in the near future, | |
including Safari :) | |
<- back to front page |