Building my first browser extension: should I use a framework?
Tags: webdev, programming, extensions, javascript
Published: 2023-11-22 17:44:41

A few months ago, the Product team I work with came up with this new project in mind: let’s create a Browser extension to help our users.
All the tech team got excited about it as it was new to all of us.
But then, during our first technical refinement, one of the developers raised a very good question: should we use a framework or not?

So here is this article, to help you with this question if you face the same situation.

_PS: This article will focus solely on Chrome, as it is currently the only browser we have experience with._

---

## ⚠️ Spoiler ⚠️
**We decided to use a framework!**

We chose [_Plasmo_](https://www.plasmo.com/) because the other options available were not suitable for us:
— [_CRXJS_](https://crxjs.dev/): Chrome specific, we had the ambition to deploy to other browsers in the future;
— [_Bedframe_](https://www.bedframe.dev/): early access only.

In this article, I will compare building an extension with _Plasmo_ and without it.
_Please feel free to compare the same bullet points on Bedframe and CRXJS, and share them in the comments._


Here is why we chose to use a framework:

### Better developer experience: live reload

- Without Plasmo framework:
![Without Plasmo framework](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/suq4u6r2pog1ve620fak.gif)

- With Plasmo framework:
![With Plasmo framework](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fuxq15ul8j9eqbw0galp.gif) 
With Plasmo, you have got live reloading.
Whereas without it, you need to close and reopen the extension to see your changes.


### Easier QA validation

Chrome extensions are subject to a [review](https://developer.chrome.com/docs/webstore/review-process/) to be published. It can take a few days to be reviewed (depending on the content of your extension).
But then how do you do QA?

Here are the 2 ways:
**Without _Plasmo_ framework:**
— the developer bundles the extension => got a zip file
— the developer sends it to QA
— QA manually uploads the new file in [Chrome extension developer mode](https://developer.chrome.com/docs/extensions/mv3/getstarted/development-basics/#load-unpacked)
✅ Free
🚨 Error-prone and time-consuming for both dev and QA teams

**With _Plasmo_ framework:**
_Plasmo_ proposes a service ([_Plasmo Itero_](https://docs.plasmo.com/itero)) to have a staging environment for your extension.
Process: at merge, a CD job is automatically run, it builds and deploys the browser extension on a private store. QA testers install the extension once, and then just need to update the extension on _chrome://extensions/_ to get the last update.
✅ Fully automated process
🟠 Paid service: $65/month

### Automatic permissions management

One of our learning on Chrome publication is “The more [permissions](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) your browser extension asks, the more time the Google review will take”
(and from our experience it can be quite long, for us it was often 1 week)
![Us waiting the Google review](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/92p3ocaahq89vot6c2si.png)

As a consequence, you do not want to mess up by asking for permissions that are not required.
It is yet another _Plasmo_ framework benefit: as the _manifest.json_ file (the file containing all your browser extension configuration, permissions included) is generated by _Plasmo_, permissions asked by your extension reflect the permissions actually needed by the codebase, nothing more.

### One codebase for all browsers

One promise of _Plasmo_ is: “you can build an extension once and easily [target it to multiple browsers](https://docs.plasmo.com/framework/workflows/build#with-a-specific-target)”.
We did not experience it, so I can not give feedback on that point. But that was an additional point that made us choose to use _Plasmo_.

### Easier communication with external services

Finally, you will probably need your extension to communicate with external services (your API, external APIs, etc).
If you call the external API naively from the current page, chances are you will run into a **CORS issue**: your request origin is the current page and your API is expecting another origin. So to bypass this, you can use a **background service worker** to proxy the communication with your API.

- Without framework:
![Without framework](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rhcsmj0ijs2w6d189brc.png)

- With _Plasmo_:
![With Plasmo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gceq6emqwp8k6t10z69g.png)

Advantages here:

- _Plasmo_ defines listeners and does the cleanup for you.
- Again, _Plasmo_‘s code is not Chrome specific
- Code organisation: your messages are split into different files, and _manifest.json_ background key is generated automatically for you
- Message name is type-safe, which can save you not pleasant debugging time:
![type safety on message name](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y4ajug1friaw4qm4oclk.png)

---

## Before I leave you, one advice:

I advise you to try a first publication to Chrome Web Store as soon as possible (you will be able to publish it as Private as a first step).
It will allow you to:

- See the list of elements required by the store (description, category, images with precise sizes, etc) and ask the right team in your company to give you those elements on time for your expected release in production.
- Get a sense of the time a publication review can take.

_If you have any questions, please comment on this article, I hope we can have an answer to help you with our experience of building a browser extension._