[HN Gopher] Plasmo - A framework for building modern Chrome exte...
       ___________________________________________________________________
        
       Plasmo - A framework for building modern Chrome extensions
        
       Author : akiselev
       Score  : 188 points
       Date   : 2024-08-20 21:56 UTC (1 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | piperswe wrote:
       | Are there any examples of (real, third-party) extensions built
       | with Plasmo?
        
         | tbrockman wrote:
         | I've built a few using it, for example: https://prune.lol or
         | https://github.com/tbrockman/browser-extension-for-opentelem...
         | 
         | 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 wrote:
           | 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.
           | 
           | [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
        
       | devvvvvvv wrote:
       | Importantly for anyone who dislikes ads: seems to support Firefox
       | too
        
         | thenegation wrote:
         | This information was needed! I had to travel 2 clicks and 5
         | scrolls to know that. Should have checked your commment :)
        
       | electricduck wrote:
       | This should have really said "WebExtension extensions" instead of
       | "Chrome extensions" as it's a standard across most modern
       | browsers these days
        
         | butz wrote:
         | 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?
        
       | FBISurveillance wrote:
       | I also suggest checking out WXT (https://wxt.dev/) as an
       | alternative (it's also faster using Vite and supports more
       | frameworks).
        
         | jazzido wrote:
         | 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 wrote:
         | 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 wrote:
           | this is also very interesting...not sure what parcel is for
           | tho, just a quick way to get a server up and running?
        
         | deisteve wrote:
         | whoa this is just like plasmo but open source and free ?
         | 
         | what is the difference?
        
       | Jackobrien wrote:
       | Experimented with Plasmo in April and found it super easy to use!
       | Was surprised I hadn't heard about it until I went looking.
        
       | kwerk wrote:
       | I love Plasmo
        
       | kelvie wrote:
       | 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 wrote:
         | Sounds like you're interested in Tampermonkey.
        
       | creesch wrote:
       | 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.
       | 
       | [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...
        
         | aflorez wrote:
         | 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 wrote:
           | > 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.
           | 
           | [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...
        
         | moi2388 wrote:
         | 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 wrote:
           | 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.
        
       | 2Gkashmiri wrote:
       | 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.
        
         | mcintyre1994 wrote:
         | Wxt was mentioned elsewhere in this thread and will build from
         | a single codebase for multiple target browsers. It's built on
         | top of a polyfill from Mozilla. Their docs on that:
         | https://wxt.dev/guide/key-concepts/web-extension-polyfill.ht...
        
         | moi2388 wrote:
         | https://github.com/PlasmoHQ/plasmo/discussions/803
         | 
         | 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
        
         | creesch wrote:
         | 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).
         | 
         | 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...
        
       | pvg wrote:
       | Some more discussion in a Show HN two years ago
       | https://news.ycombinator.com/item?id=31609896
        
       | vzaliva wrote:
       | The title may be little misleading. It is not Chrome-specific but
       | also support Firefox and some other (Chromium-based) browsers:
       | 
       | https://docs.plasmo.com/framework/workflows/faq#what-are-the...
        
       | aabhay wrote:
       | If you're looking for a Vue-flavored dev experience as opposed to
       | a react one, I recommend this:
       | 
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-08-21 23:01 UTC)