i personally don't recommend it until they have a well written document as a lot of thing are not clear seems over encapsulated, you have to figure out yourself..
you have a better option you can try WXT (https://wxt.dev/)) also i don't find current scaled project that are using it. soo yh... try break build fix that's what we do
vzaliva 147 days ago [-]
The title may be little misleading. It is not Chrome-specific but also support Firefox and some other (Chromium-based) browsers:
I also suggest checking out WXT (https://wxt.dev/) as an alternative (it's also faster using Vite and supports more frameworks).
jazzido 147 days ago [-]
I built an extension for internal company use, using WXT. Fantastic dev experience, great docs, comprehensive examples. Exactly what a framework should do.
yas_hmaheshwari 147 days ago [-]
I will also recommend parcel (https://parceljs.org/recipes/web-extension/)
We have been using it for the last 3 months, and the only time we did anything for config was in the first day
deisteve 147 days ago [-]
this is also very interesting...not sure what parcel is for tho, just a quick way to get a server up and running?
yas_hmaheshwari 145 days ago [-]
Not the server; it's just to have a good project setup, that allows us to use Typescript, multiple context scripts, and to use React
deisteve 147 days ago [-]
whoa this is just like plasmo but open source and free ?
what is the difference?
147 days ago [-]
aabhay 147 days ago [-]
If you’re looking for a Vue-flavored dev experience as opposed to a react one, I recommend this:
Building a web extension is pretty straightforward in Vite-land. There are some rough edges around hot reloading, but I doubt it could get that much better.
devvvvvvv 147 days ago [-]
Importantly for anyone who dislikes ads: seems to support Firefox too
thenegation 147 days ago [-]
This information was needed! I had to travel 2 clicks and 5 scrolls to know that. Should have checked your commment :)
creesch 147 days ago [-]
The project might do a better job of explaining what it actually intends to solve. At least as far as the readme.md goes.
I have been active in the area of browser extension development for over a decade now. And to me, it wasn't very clear at first glance.
It isn't crossbrowser extension development (which these days is actually fairly easy if you ignore Safari.... [0]).
The README showcases adding a lot of other frameworks and scaffolding, which to me isn't what makes extension development all that challenging. In fact, using a modern modular approach can be achieved using something like rollup [1].
Of course, I do believe that Plasmo makes setting it all up a lot easier. But just looking at the terminal animation I also can't help but feel that it adds a lot of abstraction I might regret later. To be clear, I also do realize that some people don't mind this and think it is easier to not have to think about the details.
Only when digging a bit deeper into the actually documentation [2] it starts to make more sense to me. From what I gather:
- Manifest creation is done entirely by plasma. You can just declare the thing you want to use or create in the right place like an options page [3]. Which is actually quite neat and something I can see makes things a bit easier for someone freshly starting with extensions. Although I'd argue that the manifest of an extension is not the most complex thing [4], even more when I see that for that with Plasmo you still need to declare similar things just at a different spot [5]
- It provides some scaffolding and abstractions around things like storage and messing between content_scripts and background workers.
- There are some neat utilities available for publishing extensions.
Overall, it looks like it like it does take away the creation of an extension and a lot of the utility functions you would need to write anyway. However it comes at the cost, in my opinion, of extreme abstraction to the degree that a beginner basically will have learned Plasmo and still have next to no understanding of browser extensions themselves.
It's one of those things where I wish this sort of tooling was available around a decade ago but I am also glad that it was not given the knowledge it gained me.
Thank you for this thorough analysis. I've built an extension myself with React and TypeScript an honestly I don't know why I would need an extra tooling to make this work. The docs supplied by Google are quite good!
creesch 147 days ago [-]
> The docs supplied by Google are quite good!
They are okayish in my book.
Personally, I prefer using the MDN docs [0][1] for web extensions as I am using mozilla's polyfill library [2] anyway. These contain more practical examples and less abstract descriptions at times, including a very thorough getting started guide [3] going over everything including various concepts.
The point remains the same though, the basics aren't all that difficult and while Plasmo does seem to make some aspects easier it also seems like overkill in other areas in regard to abstraction.
They don’t ignore safari. It creates a bundle for it which you run through Xcode and then it just works perfectly in safari as well.
It’s really a great little framework
creesch 147 days ago [-]
I am saying that I ignore Safari, for a variety of reasons including not having a device to run Xcode on.
I am also highly doubtful of it working perfectly given my experiences with Safari's implementation of the webextensions API. Though that of course depends on what API calls you actually need.
moi2388 145 days ago [-]
My apologies for misunderstanding. Thus far I’ve not run into problems with the extension working in safari except certain api calls.
kelvie 147 days ago [-]
Tangentially related, I've always wondered why there aren't better frameworks for creating userscripts.
I like customizing websites for various things, but it would be nice if I had some library I can pull into a userscript purpose-built for customizing websites (like adding pop-up config dialogs, in-line boxes to take personal notes / comment on websites, or just tools geared toward injecting and scanning the DOM using mutationobservers).
... or is this that, since userscripts are implemented via browser extensions anyway
hnrodey 147 days ago [-]
Sounds like you're interested in Tampermonkey.
piperswe 148 days ago [-]
Are there any examples of (real, third-party) extensions built with Plasmo?
The more I write browser extensions though it seems that there’s not as much benefit to it beyond compiling and bundling everything for you (and the build process does seem to get rather slow rather quickly for me).
The author is pretty open to pull requests and feedback when they have time though!
creesch 147 days ago [-]
I wrote a more extensive comment elsewhere, but for basic compiling a browser extension you can also simply use common tooling like rollup [0] where your manifest just points to the rollup generated files [1].
And if you forgo modern frameworks entirely, you can just have everything in one directory and run everything more or less directly from there [2].
As far as I am concerned, the structure and packaging of web extensions isn't what makes them complicated, although it does seem to be what a lot of people get hung up on. The web extension APIs and their interaction is often a bigger challenge. Publishing is also somewhat of a pain to deal with, although that is more the process around it and the lack of communication from both Mozilla and Google about it at times.
Experimented with Plasmo in April and found it super easy to use! Was surprised I hadn’t heard about it until I went looking.
zipping1549 144 days ago [-]
Didn't know eztension framework was a thing
kwerk 147 days ago [-]
I love Plasmo
2Gkashmiri 147 days ago [-]
how do you build a single browser extension and then have compatible firefox/chrome files that are different in what they require for their own thing.
i mean currently we are doing terribly stupid thing. two folders /firefox and /chrome and do the updates manually in both. there should be something easier.
creesch 147 days ago [-]
The only really difference sometimes is in the manifest. If you target the webextension api and use the Mozilla poly fill library, your code base does not need to be duplicated at all.
It adds the benefit of being able to use all API calls in a promise based manner instead of needing to use callbacks.
Edit:
To give it a bit more context (although you can find that in other comments I left under this post).
Which if included allows you to swap out `chrome` callback based calls for promise based `browser` calls.
So instead of using `chrome.extension.api.call(() => { // callback})` you do something like `await browser.extension.api.call()` with the same results working in both browsers.
Then the only thing where you still need some separation is for the manifest as some keys are Firefox specific and vice versa.
This should have really said "WebExtension extensions" instead of "Chrome extensions" as it's a standard across most modern browsers these days
butz 147 days ago [-]
Interesting, that on website there is no mention of building "Chrome extension" only extensions. They should even work on Edge. Was this the result of some unfortunate editorializing of post title?
https://docs.plasmo.com/framework/workflows/faq#what-are-the...
what is the difference?
https://github.com/antfu-collective/vitesse-webext
Building a web extension is pretty straightforward in Vite-land. There are some rough edges around hot reloading, but I doubt it could get that much better.
I have been active in the area of browser extension development for over a decade now. And to me, it wasn't very clear at first glance.
It isn't crossbrowser extension development (which these days is actually fairly easy if you ignore Safari.... [0]).
The README showcases adding a lot of other frameworks and scaffolding, which to me isn't what makes extension development all that challenging. In fact, using a modern modular approach can be achieved using something like rollup [1].
Of course, I do believe that Plasmo makes setting it all up a lot easier. But just looking at the terminal animation I also can't help but feel that it adds a lot of abstraction I might regret later. To be clear, I also do realize that some people don't mind this and think it is easier to not have to think about the details.
Only when digging a bit deeper into the actually documentation [2] it starts to make more sense to me. From what I gather:
- Manifest creation is done entirely by plasma. You can just declare the thing you want to use or create in the right place like an options page [3]. Which is actually quite neat and something I can see makes things a bit easier for someone freshly starting with extensions. Although I'd argue that the manifest of an extension is not the most complex thing [4], even more when I see that for that with Plasmo you still need to declare similar things just at a different spot [5]
- It provides some scaffolding and abstractions around things like storage and messing between content_scripts and background workers.
- There are some neat utilities available for publishing extensions.
Overall, it looks like it like it does take away the creation of an extension and a lot of the utility functions you would need to write anyway. However it comes at the cost, in my opinion, of extreme abstraction to the degree that a beginner basically will have learned Plasmo and still have next to no understanding of browser extensions themselves.
It's one of those things where I wish this sort of tooling was available around a decade ago but I am also glad that it was not given the knowledge it gained me.
[0] https://news.ycombinator.com/item?id=41043974
[1] https://github.com/toolbox-team/reddit-moderator-toolbox/blo...
[2] https://docs.plasmo.com
[3] https://docs.plasmo.com/framework/ext-pages#adding-the-optio...
[4] https://github.com/toolbox-team/reddit-moderator-toolbox/blo...
[5] https://docs.plasmo.com/framework/content-scripts#adding-a-s...
They are okayish in my book.
Personally, I prefer using the MDN docs [0][1] for web extensions as I am using mozilla's polyfill library [2] anyway. These contain more practical examples and less abstract descriptions at times, including a very thorough getting started guide [3] going over everything including various concepts.
The point remains the same though, the basics aren't all that difficult and while Plasmo does seem to make some aspects easier it also seems like overkill in other areas in regard to abstraction.
[0] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
[2] https://github.com/mozilla/webextension-polyfill
[3] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
It’s really a great little framework
I am also highly doubtful of it working perfectly given my experiences with Safari's implementation of the webextensions API. Though that of course depends on what API calls you actually need.
I like customizing websites for various things, but it would be nice if I had some library I can pull into a userscript purpose-built for customizing websites (like adding pop-up config dialogs, in-line boxes to take personal notes / comment on websites, or just tools geared toward injecting and scanning the DOM using mutationobservers).
... or is this that, since userscripts are implemented via browser extensions anyway
The more I write browser extensions though it seems that there’s not as much benefit to it beyond compiling and bundling everything for you (and the build process does seem to get rather slow rather quickly for me).
The author is pretty open to pull requests and feedback when they have time though!
And if you forgo modern frameworks entirely, you can just have everything in one directory and run everything more or less directly from there [2].
As far as I am concerned, the structure and packaging of web extensions isn't what makes them complicated, although it does seem to be what a lot of people get hung up on. The web extension APIs and their interaction is often a bigger challenge. Publishing is also somewhat of a pain to deal with, although that is more the process around it and the lack of communication from both Mozilla and Google about it at times.
[0] https://github.com/toolbox-team/reddit-moderator-toolbox/blo...
[1] https://github.com/toolbox-team/reddit-moderator-toolbox/blo...
[2] https://github.com/creesch/readReddit
for anyone who is interested for an alternative to Plasmo, i chanced upon https://github.com/extension-js/extension.js
i mean currently we are doing terribly stupid thing. two folders /firefox and /chrome and do the updates manually in both. there should be something easier.
It adds the benefit of being able to use all API calls in a promise based manner instead of needing to use callbacks.
Edit:
To give it a bit more context (although you can find that in other comments I left under this post).
The polyfill library itself: https://github.com/mozilla/webextension-polyfill
Which if included allows you to swap out `chrome` callback based calls for promise based `browser` calls.
So instead of using `chrome.extension.api.call(() => { // callback})` you do something like `await browser.extension.api.call()` with the same results working in both browsers.
Then the only thing where you still need some separation is for the manifest as some keys are Firefox specific and vice versa.
An example you can find here: https://github.com/toolbox-team/reddit-moderator-toolbox
Where all code lives in one directory and there is just two manifest files, one for chrome and firefox: https://github.com/toolbox-team/reddit-moderator-toolbox/tre...
Building is nothing more than rollup packaging the code and grabbing the right manifest to put in the build directory for each browser: https://github.com/toolbox-team/reddit-moderator-toolbox/blo...
From my personal experience; most stuff just works cross platform. Currently building an extension and it just works in edge, chrome, Firefox, safari.
You can use poly fill or custom code for when it’s really needed of course