Show HN: Plasmo – a framework for building modern Chrome extensions (github.com)
Hey HN, we're excited to have people try out our framework! When we built out a Chrome extension earlier this year, we noticed that the config was too imperative. You had to constantly tell Chrome via the manifest.json file where your files were, what your permissions should be, etc.
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!
38 comments
[ 3.1 ms ] story [ 79.0 ms ] threadHow close are we to being able to write MV3 extensions that run on Chrome/Firefox/Safari without code adaptations?
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
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.
[0] https://github.com/antony/sveltekit-adapter-browser-extensio...
[1] https://github.com/FractalHQ/nutab
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...
[0]: https://parceljs.org/recipes/web-extension/
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
https://www.grammarly.com/browser/chrome
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.
All other things being equal.
> 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?
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.
Sure. My question is why.
The output that runs in the browser at runtime has its own set of same constraints. Modern browser version, etc.
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
Very interesting. Thank you again!
I think I get what you were trying to do with the pricing "per hacker".
But really it's just confusing. Say it's $30/users/month
The price is good. I just find the hacker term unnecessary