22 ms·

Show HN: I made a CLI tool to create web extensions with no build configuration

Hello HN! I'm the creator and solo developer of Extension.js, a development tool for browser extensions with built-in support for TypeScript, WebAssembly, React, and modern JavaScript. Developers use it to spend less time configuring the compilation config or learning new frameworks and more time actually writing code. 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/tree/main/functional-samples/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

isodev 2y ago
Looks interesting but I don’t understand why Safari is excluded on both desktop and mobile.
- cezaraugustodev 2y ago
  Thanks! I do plan to support all major browsers in the near future, including Safari :)
- bpev 2y 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 2y ago
    FYI There is a new issue to track progress and enable Safari support https://github.com/cezaraugusto/extension.js/issues/46 https://github.com/cezaraugusto/extension.js/issues/46
herrherrmann 2y ago
Very cool stuff! I might check this out for my extension (https://github.com/herrherrmann/omnivore-list-popup https://github.com/herrherrmann/omnivore-list-popup). 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?
- cezaraugustodev 2y 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.
edwinjm 2y ago
It’s called a browser extension, why call it web extension?
- thrdbndndn 2y 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] https://developer.mozilla.org/en-US/docs/Glossary/WebExtensions https://developer.mozilla.org/en-US/docs/Glossary/WebExtensi... [2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
- jonathanlydall 2y ago
  100%, I was also initially confused by the term web extension, it’s a browser extension.
- cezaraugustodev 2y ago
  HN has a character limitation for the post title and changing the word made the title fit just fine :)
- PurpleRamen 2y ago
  Because this specific browser extensions are named WebExtensions[1]. [1] https://www.w3.org/community/webextensions/ https://www.w3.org/community/webextensions/
- derefr 2y 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.
blackhaj7 2y ago
This looks really helpful - thanks!
- cezaraugustodev 2y ago
  Thanks for the kind words!
mvkel 2y 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.
- cezaraugustodev 2y ago
  Thank you! I'm glad you liked the readme as well :D
- dotproto 2y ago
  Chrome extensions are published on Chrome Web Store (https://chromewebstore.google.com https://chromewebstore.google.com), not on Google Play.
  - mvkel 2y ago
    Sorry! Different name, same cluster :)
mrozbarry 2y ago
I totally understand why, but no firefox support is a show-stopper for most extension developers.
- cezaraugustodev 2y ago
  Sure thing! There will be support for Firefox very soon
- deleted 2y ago
  [deleted]
- thenbe 2y ago
  FWIW there's an existing issue for "firefox support" which you can subscribe to in order to be notified when this feature lands. https://github.com/cezaraugusto/extension.js/issues/5 https://github.com/cezaraugusto/extension.js/issues/5
ViktorBash 2y 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 2y ago
  Thanks! Firefox support will come in the next update. Stay tuned! :)
notum 2y ago
Apologies for the confusion but what is "cross-browser" about this tool if it only works with chromium?
- deleted 2y ago
  [deleted]
- cezaraugustodev 2y ago
  No worries :) but Chrome and Edge are indeed different browsers. Support for Firefox and Safari is next.
  - notum 2y 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!
- purple-leafy 2y 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 2y ago
    Safari and Firefox are next, feel free to subscribe to the issues below so you know when Extension.js supports them. - Safari https://github.com/cezaraugusto/extension.js/issues/46 https://github.com/cezaraugusto/extension.js/issues/46 - Firefox https://github.com/cezaraugusto/extension.js/issues/5 https://github.com/cezaraugusto/extension.js/issues/5
avtar 2y 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.
- deleted 2y ago
  [deleted]
- cezaraugustodev 2y ago
  That's great feedback, thank you. Will consider the removal.
rmdes 2y 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 2y ago
  Haha glad to hear that
redder23 2y ago
[dead]
chadrs 2y 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. https://github.com/mozilla/web-ext https://github.com/mozilla/web-ext
- deleted 2y ago
  [deleted]
- cezaraugustodev 2y 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.
_andrei_ 2y ago
very cool, also check out https://www.plasmo.com/ https://www.plasmo.com/
outlore 2y ago
this is cool! how would you contrast this with Plasmo, a similar framework? https://www.plasmo.com/ https://www.plasmo.com/
- simple10 2y ago
  Plasmo looks extremely useful. Have you used it to develop any extensions?
  - spxneo 2y 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
  - bluelightning2k 2y ago
    I use Plasmo. Strongly recommend it. So much so I gave them a shout-out in a blog post just this Sunday (https://moddable.app/blog/unofficial-mod-support https://moddable.app/blog/unofficial-mod-support). I don't really use the framework stuff but HMR that works really well is just chefs kiss.
- cezaraugustodev 2y 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 2y 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
masto 2y 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?
- grimgrin 2y 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 https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... You can hack on the behavior via userscripts, my preferred way to alter websites, though I write extensions too (greasemoney is good tho)
  - rsoto 2y 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: https://github.com/dy/spect https://github.com/dy/spect 2: https://github.com/kubetail-org/sentineljs https://github.com/kubetail-org/sentineljs
    - sfink 2y 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.
simple10 2y 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: https://github.com/cezaraugusto/extension.js/issues/5 https://github.com/cezaraugusto/extension.js/issues/5
- simple10 2y 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 2y ago
    The plugin for Firefox is on the way, but any community support is highly appreciated.
- Vinnl 2y 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 2y 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 2y 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" } } ```
lagniappe 2y 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 2y ago
  I'm glad to hear!
from-nibly 2y 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 2y ago
  Totally relate. Extension development should be fun, right? Hope Extension.js can help you with your next project!
- deleted 2y ago
  [deleted]
aaronharding 2y 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.
- cezaraugustodev 2y ago
  Haha, thanks! It’s not in the immediate plans, but meanwhile, I'm sure there are some good libraries on npm for that :)
- nullandvoid 2y ago
  Plasmo has a messaging library you might want to explore https://docs.plasmo.com/framework/messaging https://docs.plasmo.com/framework/messaging
- dotproto 2y ago
  Can you share more about what you find frustrating or confusing about this process?
gerroo 2y 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 2y ago
  Thank you! The ecosystem for developing extensions could be so much better, hope we can help with that
  - dotproto 2y ago
    Would love to hear your thoughts on how to improve it ;)
msephton 2y ago
Just added an issue: Safari support should be relatively straightforward using Apple's safari-web-extension-converter cli tool.
- cezaraugustodev 2y ago
  Thanks for that!
hhimanshu 2y ago
This is good project. I built my first chrome extension using https://crxjs.dev/vite-plugin/getting-started https://crxjs.dev/vite-plugin/getting-started and there was lot of fiddling to et styles working. This could also be because this is my first browser extension development. https://chromewebstore.google.com/detail/bettermenu-for-doordash/dljbjnbdbcaoolcpnipponklapjlkbhj https://chromewebstore.google.com/detail/bettermenu-for-door... There is still lot more work to do, so I will checkout your project. Thanks for sharing!
- cezaraugustodev 2y ago
  That's great! I'm glad you will give it a try
kosolam 2y ago
Need to change the title it’s browser extensions not Web extensions.
- sureIy 2y ago
  That’s wrong: https://github.com/w3c/webextensions https://github.com/w3c/webextensions
  - kosolam 2y 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.”
    - sureIy 2y ago
      You’re making up differentiation where there is none. Browser extensions are called WebExtensions. The terms are used interchangeably in practice. > WebExtensions are a way to write browser extensions Even if “technically correct”, the tool still specifically creates WebExtensions, it does not create “non-WebExtension browser extensions”
      - kosolam 2y ago
        You are welcome to go to their respective repos and make your arguments there. I just pasted the quotes here.
        sureIy 2y ago
        They’re right, it’s your “correcting” comment that’s wrong
rantymcrant 2y 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?
- saghm 2y 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 (https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html): > 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.
- fragmede 2y ago
  https://news.ycombinator.com/item?id=1381172 https://news.ycombinator.com/item?id=1381172 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.
  - rantymcrant 2y 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 2y 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.
deleted 2y ago
[deleted]
satisfice 2y 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 2y 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 :)
cantSpellSober 2y ago
s

isodev 2y ago

Looks interesting but I don’t understand why Safari is excluded on both desktop and mobile.

cezaraugustodev 2y ago
Thanks! I do plan to support all major browsers in the near future, including Safari :)
bpev 2y 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 2y ago
  FYI There is a new issue to track progress and enable Safari support https://github.com/cezaraugusto/extension.js/issues/46 https://github.com/cezaraugusto/extension.js/issues/46

herrherrmann 2y ago

Very cool stuff! I might check this out for my extension (https://github.com/herrherrmann/omnivore-list-popup https://github.com/herrherrmann/omnivore-list-popup). 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?

cezaraugustodev 2y 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.

edwinjm 2y ago

It’s called a browser extension, why call it web extension?

thrdbndndn 2y 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] https://developer.mozilla.org/en-US/docs/Glossary/WebExtensions https://developer.mozilla.org/en-US/docs/Glossary/WebExtensi... [2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
jonathanlydall 2y ago
100%, I was also initially confused by the term web extension, it’s a browser extension.
cezaraugustodev 2y ago
HN has a character limitation for the post title and changing the word made the title fit just fine :)
PurpleRamen 2y ago
Because this specific browser extensions are named WebExtensions[1]. [1] https://www.w3.org/community/webextensions/ https://www.w3.org/community/webextensions/
derefr 2y 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.

blackhaj7 2y ago

This looks really helpful - thanks!

cezaraugustodev 2y ago
Thanks for the kind words!

mvkel 2y 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.

cezaraugustodev 2y ago
Thank you! I'm glad you liked the readme as well :D
dotproto 2y ago
Chrome extensions are published on Chrome Web Store (https://chromewebstore.google.com https://chromewebstore.google.com), not on Google Play.
- mvkel 2y ago
  Sorry! Different name, same cluster :)

mrozbarry 2y ago

I totally understand why, but no firefox support is a show-stopper for most extension developers.

cezaraugustodev 2y ago
Sure thing! There will be support for Firefox very soon
deleted 2y ago
[deleted]
thenbe 2y ago
FWIW there's an existing issue for "firefox support" which you can subscribe to in order to be notified when this feature lands. https://github.com/cezaraugusto/extension.js/issues/5 https://github.com/cezaraugusto/extension.js/issues/5

ViktorBash 2y 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 2y ago
Thanks! Firefox support will come in the next update. Stay tuned! :)

notum 2y ago

Apologies for the confusion but what is "cross-browser" about this tool if it only works with chromium?

deleted 2y ago
[deleted]
cezaraugustodev 2y ago
No worries :) but Chrome and Edge are indeed different browsers. Support for Firefox and Safari is next.
- notum 2y 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!
purple-leafy 2y 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 2y ago
  Safari and Firefox are next, feel free to subscribe to the issues below so you know when Extension.js supports them. - Safari https://github.com/cezaraugusto/extension.js/issues/46 https://github.com/cezaraugusto/extension.js/issues/46 - Firefox https://github.com/cezaraugusto/extension.js/issues/5 https://github.com/cezaraugusto/extension.js/issues/5

avtar 2y 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.

deleted 2y ago
[deleted]
cezaraugustodev 2y ago
That's great feedback, thank you. Will consider the removal.

rmdes 2y 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 2y ago
Haha glad to hear that

redder23 2y ago

[dead]

chadrs 2y 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. https://github.com/mozilla/web-ext https://github.com/mozilla/web-ext

deleted 2y ago
[deleted]
cezaraugustodev 2y 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.

_andrei_ 2y ago

very cool, also check out https://www.plasmo.com/ https://www.plasmo.com/

outlore 2y ago

this is cool! how would you contrast this with Plasmo, a similar framework? https://www.plasmo.com/ https://www.plasmo.com/

simple10 2y ago
Plasmo looks extremely useful. Have you used it to develop any extensions?
- spxneo 2y 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
- bluelightning2k 2y ago
  I use Plasmo. Strongly recommend it. So much so I gave them a shout-out in a blog post just this Sunday (https://moddable.app/blog/unofficial-mod-support https://moddable.app/blog/unofficial-mod-support). I don't really use the framework stuff but HMR that works really well is just chefs kiss.
cezaraugustodev 2y 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 2y 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

masto 2y 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?

grimgrin 2y 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 https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... You can hack on the behavior via userscripts, my preferred way to alter websites, though I write extensions too (greasemoney is good tho)
- rsoto 2y 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: https://github.com/dy/spect https://github.com/dy/spect 2: https://github.com/kubetail-org/sentineljs https://github.com/kubetail-org/sentineljs
  - sfink 2y 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.

simple10 2y 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: https://github.com/cezaraugusto/extension.js/issues/5 https://github.com/cezaraugusto/extension.js/issues/5

simple10 2y 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 2y ago
  The plugin for Firefox is on the way, but any community support is highly appreciated.
Vinnl 2y 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 2y 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 2y 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" } } ```

lagniappe 2y 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 2y ago
I'm glad to hear!

from-nibly 2y 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 2y ago
Totally relate. Extension development should be fun, right? Hope Extension.js can help you with your next project!
deleted 2y ago
[deleted]

aaronharding 2y 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.

cezaraugustodev 2y ago
Haha, thanks! It’s not in the immediate plans, but meanwhile, I'm sure there are some good libraries on npm for that :)
nullandvoid 2y ago
Plasmo has a messaging library you might want to explore https://docs.plasmo.com/framework/messaging https://docs.plasmo.com/framework/messaging
dotproto 2y ago
Can you share more about what you find frustrating or confusing about this process?

gerroo 2y 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 2y ago
Thank you! The ecosystem for developing extensions could be so much better, hope we can help with that
- dotproto 2y ago
  Would love to hear your thoughts on how to improve it ;)

msephton 2y ago

Just added an issue: Safari support should be relatively straightforward using Apple's safari-web-extension-converter cli tool.

cezaraugustodev 2y ago
Thanks for that!

hhimanshu 2y ago

This is good project. I built my first chrome extension using https://crxjs.dev/vite-plugin/getting-started https://crxjs.dev/vite-plugin/getting-started and there was lot of fiddling to et styles working. This could also be because this is my first browser extension development. https://chromewebstore.google.com/detail/bettermenu-for-doordash/dljbjnbdbcaoolcpnipponklapjlkbhj https://chromewebstore.google.com/detail/bettermenu-for-door... There is still lot more work to do, so I will checkout your project. Thanks for sharing!

cezaraugustodev 2y ago
That's great! I'm glad you will give it a try

kosolam 2y ago

Need to change the title it’s browser extensions not Web extensions.

sureIy 2y ago
That’s wrong: https://github.com/w3c/webextensions https://github.com/w3c/webextensions
- kosolam 2y 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.”
  - sureIy 2y ago
    You’re making up differentiation where there is none. Browser extensions are called WebExtensions. The terms are used interchangeably in practice. > WebExtensions are a way to write browser extensions Even if “technically correct”, the tool still specifically creates WebExtensions, it does not create “non-WebExtension browser extensions”
    - kosolam 2y ago
      You are welcome to go to their respective repos and make your arguments there. I just pasted the quotes here.
      - sureIy 2y ago
        They’re right, it’s your “correcting” comment that’s wrong

rantymcrant 2y 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?

saghm 2y 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 (https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html): > 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.
fragmede 2y ago
https://news.ycombinator.com/item?id=1381172 https://news.ycombinator.com/item?id=1381172 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.
- rantymcrant 2y 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 2y 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.

deleted 2y ago

[deleted]

satisfice 2y 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 2y 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 :)

cantSpellSober 2y ago