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!
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...
How 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.
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.
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...
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
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...
> 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.
