Show HN: Plasmo – a framework for building modern Chrome extensions(github.com)
github.com
Show HN: Plasmo – a framework for building modern Chrome extensions
https://github.com/PlasmoHQ/plasmo
38 comments
Any plans to do the same for firefox? I hate google Chrome
Currently using Parcel with its support for manifest.json as an entrypoint[0], could you explain what your framework does beyond that?
[0]: https://parceljs.org/recipes/web-extension/
[0]: https://parceljs.org/recipes/web-extension/
We use Parcel under the hood and are huge fans! Our framework has opinionated abstractions on top of it that we think help improve the extension development experience considerably.
Features we've built so far:
- manifest.json is generated automatically. If you want to create a content script, you name a file content.ts, and it'll auto-gen the right manifest key-value pair for it. Same with backround.ts. [1]
- Mounting a React component to the popup or options page is similar. You create a popup.tsx or options.tsx file, export a default React component, and it'll automatically associate it in the manifest and mount the component automatically for you.
- We support environment variables with .env files [2]
- We just released support to automatically inject a shadow DOM into a webpage and mount a React component from a content script [3]
- We have remote code bundling that automatically fetches URL based imports (like Google Analytics) in build time to mitigate issues with MV3 not allowing remote code [4]
[1]: https://docs.plasmo.com/#where-is-the-manifestjson-file
[2]: https://docs.plasmo.com/workflows/env
[3]: https://github.com/PlasmoHQ/examples/tree/57791e70549441e391...
[4]: https://docs.plasmo.com/workflows/remote-code
Features we've built so far:
- manifest.json is generated automatically. If you want to create a content script, you name a file content.ts, and it'll auto-gen the right manifest key-value pair for it. Same with backround.ts. [1]
- Mounting a React component to the popup or options page is similar. You create a popup.tsx or options.tsx file, export a default React component, and it'll automatically associate it in the manifest and mount the component automatically for you.
- We support environment variables with .env files [2]
- We just released support to automatically inject a shadow DOM into a webpage and mount a React component from a content script [3]
- We have remote code bundling that automatically fetches URL based imports (like Google Analytics) in build time to mitigate issues with MV3 not allowing remote code [4]
[1]: https://docs.plasmo.com/#where-is-the-manifestjson-file
[2]: https://docs.plasmo.com/workflows/env
[3]: https://github.com/PlasmoHQ/examples/tree/57791e70549441e391...
[4]: https://docs.plasmo.com/workflows/remote-code
Looks very promising. I'm wondering about the current state of cross-browser compatibility.
How close are we to being able to write MV3 extensions that run on Chrome/Firefox/Safari without code adaptations?
How close are we to being able to write MV3 extensions that run on Chrome/Firefox/Safari without code adaptations?
There's standardization work being done at the moment with the W3C WebExtensions Community Group [1] which is definitely a step in the right direction!
Mozilla has also done some great work building a web extension polyfill library that attempts to abstract away the differences between the browsers [2] but the translation will always be imperfect, and edge cases are abundant.
[1]: https://www.w3.org/community/webextensions/
[2]: https://github.com/mozilla/webextension-polyfill
Mozilla has also done some great work building a web extension polyfill library that attempts to abstract away the differences between the browsers [2] but the translation will always be imperfect, and edge cases are abundant.
[1]: https://www.w3.org/community/webextensions/
[2]: https://github.com/mozilla/webextension-polyfill
Love this. Chrome extensions are the most underrated platform to spit out 7+ figure recurring revenue businesses on. Mac App Store close second. I'm hesitant to even mention because it's such a good secret.
Can you point to one extension that is making 7 figures?
I imagine Grammarly is. And then they spend all that revenue on YouTube ads...
https://www.grammarly.com/browser/chrome
https://www.grammarly.com/browser/chrome
Grammarly is also a large and well established tech company. Pretty sure they’ve been around for 12+ years at this point, and I think have multiple hundreds of staff.
Are you looking very specifically for “ONLY 7 figures”?
Revenue, or profit?
Not hard to think of a handful of big players in revenue; 1Password and Honey spring instantly to mind as 9-figure revenue players.
Revenue, or profit?
Not hard to think of a handful of big players in revenue; 1Password and Honey spring instantly to mind as 9-figure revenue players.
So are you saying P(success|browser extension) > P(success|web app)?
All other things being equal.
All other things being equal.
What's your basis for these statements?
This is neat. How does live-reloading work? Manually reloading a chrome extension with each code change has been a pain point for me in the past.
Thanks! We wrote a custom Parcel runtime [1] inspired by Parcel's HMR runtime (which was too bloated and buggy for us) that injects a web socket listener into the development build of the extension.
Whenever a bundle change happens, Parcel sends it the refresh message and it either does `chrome.runtime.reload()` or `location.reload()` depending on the context.
[1]: https://github.com/PlasmoHQ/plasmo/blob/main/packages/parcel...
Whenever a bundle change happens, Parcel sends it the refresh message and it either does `chrome.runtime.reload()` or `location.reload()` depending on the context.
[1]: https://github.com/PlasmoHQ/plasmo/blob/main/packages/parcel...
Glad to see you on HN front page. I followed your progress via this Twitter thread: https://twitter.com/tylerangert/status/1527003106185207808
Thank you for doing this. Not tried it out yet but I fully intend to.
Very interesting. Thank you again!
Very interesting. Thank you again!
I found making Chrome extensions with Sveltekit was very easy thanks in part to its use of Vite. Any plans to support anything other than React?
Svelte or Sveltekit specifically? I've had issues with getting the webextensions polyfill working with Sveltekit but Svelte works without any issues.
Do you have any references that you could point me to on how to get Sveltekit running to build Chrome extensions?
Sorry for the digression, but this has been a bit of a bugbear for the past month and would dearly love to know how to get around it.
Do you have any references that you could point me to on how to get Sveltekit running to build Chrome extensions?
Sorry for the digression, but this has been a bit of a bugbear for the past month and would dearly love to know how to get around it.
Sveltekit! I used sveltekit-adapter-browser-extension[0] by Antony which conveniently handles the hashing stuff. I just made the repo public in case you want to check it out[1]. Let me know if you run into any issues!
[0] https://github.com/antony/sveltekit-adapter-browser-extensio...
[1] https://github.com/FractalHQ/nutab
[0] https://github.com/antony/sveltekit-adapter-browser-extensio...
[1] https://github.com/FractalHQ/nutab
It's definitely something we want to consider in the future! Right now, we want to focus on a single view framework and make the developer experience as seamless as possible with it. The framework we've chosen is React because we're most familiar with it.
> System Requirements
> Node.js 16.x or later
Plasmo's "users" will already be working under the constraint of developing for a target platform where NodeJS will not be available to them, but is nonetheless meant for running JS: Chrome. Why is NodeJS necessary?
> Node.js 16.x or later
Plasmo's "users" will already be working under the constraint of developing for a target platform where NodeJS will not be available to them, but is nonetheless meant for running JS: Chrome. Why is NodeJS necessary?
Our tooling is written in Node.js. So developers must have Node installed on their machines to utilize our tooling.
When they use our CLI to watch the file system for changes for live-reload or to build their extension, etc., that's a Node.js program.
The build target is browser Javascript, though.
When they use our CLI to watch the file system for changes for live-reload or to build their extension, etc., that's a Node.js program.
The build target is browser Javascript, though.
> Our tooling is written in Node.js.
Sure. My question is why.
Sure. My question is why.
It’s a norm for frontend devs to build CLI tools in the language/evironments/ecosystems they’re most familiar with.
That's an interesting way to respond, given the context. NodeJS doesn't run on the frontend, so your argument here would be an even _stronger_ reason to favor using Chrome as your runtime...
Surely you are trolling? That's a very, very common setup. Nothing complicated or out of the ordinary requiring specific tooling for the dev environment.
The output that runs in the browser at runtime has its own set of same constraints. Modern browser version, etc.
The output that runs in the browser at runtime has its own set of same constraints. Modern browser version, etc.
> Surely you are trolling?
First of all, don't do that. It's obnoxious. Secondly:
> That's a very, very common setup.
So? Falling back on the argument that, essentially, "lots of people do this" is about as worthy as attempting to counter by saying that the other person/what they are doing is weird[1]. (It's actually slightly more respectable, but that's only because of how unrespectable the call-them-a-weirdo path is.) You either have an argument for $THING that will hold up under scrutiny without appealing to how weird/anti-weird $THING is, or you don't.
Thirdly, you are not compelled to comment. (What makes your decision to join in even more mystifying is that you were not the person being addressed—at least their impulse to do so would have made sense, even if the argument was still a bad one.) If you don't actually have an answer, why bother commenting at all?
1. https://news.ycombinator.com/item?id=30721113
First of all, don't do that. It's obnoxious. Secondly:
> That's a very, very common setup.
So? Falling back on the argument that, essentially, "lots of people do this" is about as worthy as attempting to counter by saying that the other person/what they are doing is weird[1]. (It's actually slightly more respectable, but that's only because of how unrespectable the call-them-a-weirdo path is.) You either have an argument for $THING that will hold up under scrutiny without appealing to how weird/anti-weird $THING is, or you don't.
Thirdly, you are not compelled to comment. (What makes your decision to join in even more mystifying is that you were not the person being addressed—at least their impulse to do so would have made sense, even if the argument was still a bad one.) If you don't actually have an answer, why bother commenting at all?
1. https://news.ycombinator.com/item?id=30721113
[deleted]
So we thought it might be interesting to build a more declarative framework. When we built a proof of concept, we enjoyed working with it and decided to invest more time into making it usable and adding more features.
We're still pretty early in building it out, and there's a bunch more we want to add, but this feels like a good time to showcase it and hear what people think!