21–30 of 37 posts
Does the dev mode use HMR? Can the cli upload bundles extensions to respective browser's stores? Does it work with any web framework supported by vite? Does it work with all vite/roll-up plugins?
This project is very interesting to me because I currently have a published Firefox extension that uses Vite, NPM, and Solid.js.
I'm somewhat confused about what problem this is solving, but I also have a lot of questions. Does the dev mode use HMR? Can the cli upload bundles extensions to respective browser's stores? Does it work with any web framework supported by vite? Does it work with all vite/roll-up plugins? This project is very interesting to me because I currently have a published Firefox extension that uses Vite, NPM, and Solid.js.
> what its trying to solve:
I want a Next.js + Vercel dev experience but for building browser extensions: push to main > run a workflow > determine if it should publish > publish (to all my chosen web stores)
I want an actual dev workflow (like I'm used to in regular web/app development in 2023) but again, tailored for browser extensions.
Basically I wanted something that doesn't abstract the usual Vite setup. Just give me the usual niceties of working with client-side react w/ Vite. So yes, you get the vite/rollup plugins as usual.
Does the name of this organization seem suspicious to anyone else?
How does this position with something like plasma.dev? I’ve been happy with it, especially the testing / beta deployment and messaging libraries.
Definitely a much-needed area for development. However, having gone down the browser extension rabbit hole, I've largely shifted my focus to user scripts. Granted, there will always be a need for specialized browser extensions like ad blockers (uBlock[1]), keyboard shortcuts (Vimium-C[2]), and password managers (Bitwarden[3]). That said, I find user scripts superior for most tasks, despite some lacking UI niceties. T…
* Attaching to page DOM with custom HTML/CSS/JavaScript
* Shadow DOM
* Iframe
Shadow DOMs seem like a good hybrid between iframes and attaching to the page DOM.
For extension experts, when should developers use a framework like this versus these options: * Attaching to page DOM with custom HTML/CSS/JavaScript * Shadow DOM * Iframe Shadow DOMs seem like a good hybrid between iframes and attaching to the page DOM.
Idea is, depending on what kind of extension you're building you can use content scripts to render you extension in shadow dom or iframe. Bedframe lets you do this.
The CLI is a project generator for: - popup (default kind of extension) - side panel (relatively new in Chrome / https://developer.chrome.com/docs/extensions/reference/sideP...) - overlay (what you describe above) - devtools extensions (https://developer.chrome.com/docs/extensions/mv3/devtools/#d...).
Bedframe goes further and lets you add a mvp.yml workflow to your (Github) repo and have any versioned changes landing in 'main' branch get published to firefox, edge, chrome web stores
Basically productionizes the extension dev process.
wow this look awesome!
Earlier quoted context omitted.
I’m in the same boat. I got in the world of extension development last year, and oh my, what a crazy mess. Apart from browser compatibility, I was really hoping for some product to help out with the operational stuff.
Ooof!! It is an... interesting time right now in extensions land. The switch from MV2 to MV3 is a bit chaotic but hopefully tools like this (Bedframe) and tools like [Plasmo]( https://github.com/PlasmoHQ/plasmo ) start to inject some freshness in the space.
I just recently came across Plasmo [1], which is very mature and a good entry point for anyone starting on the browser extension environment (like I am). It would be nice to see some comparisons in the future when Bedframe's docs are published [1] https://docs.plasmo.com/framework