Building Web Extensions With Your Favourite Framework

Hi everyone, my name is Alba Silvente and I work as a Fullstack Engineer at Servlug. Today I want to talk about unlocking the power of web extensions using your favorite JavaScript framework. In my case, I will use Vue because it's the one I love, but you can use any framework you like. So first I want to show you a little sneak peek on how the demo will look like. Here you have the preference where the user can select what they want to see when they are navigating between pages. And then in the options page I have the same component, just showcasing the different preferences, so every time you change it you can see the real-time changes between them. And once you select a word in the page you are navigating, you will see a menu out of the preference that you selected, where we are calling the built-in AI APIs from the browser to generate the response.

So in this talk I want to show you how you will build this and what do you need to know in order to do it. So the agenda will look like. First we will talk about what, why and how we build our extension. Then we will see the standard behind them and the structure that our project needs to follow in order to create a web extension. Later we will see the open-source packages and frameworks that we can use to build web extensions easily and without the pain of configuring the entire project. And later we will see the practical use cases that I build with this demo, so we understand how to convert our ideas to a web extension.

And what is a web extension? Well, it's as simple as a small page. It's like a single-page app, it's just a small program developing HTML, CSS and JavaScript that integrates into a browser to customize and add new functionalities to it. So you can imagine that if you want to add a DevTools tab, you will need to do something else than creating a website. That's why web extensions are needed in order to develop more things inside the browser itself. So it helps the user to have more capabilities thanks to that. And what's in it for me? Of course you will think maybe creating an extension can be really overkill for something you don't want to spend so much time doing. But imagine that you have a repetitive task that you are doing every day and you can automate somehow using web extensions. That's why I saw the potential and I wanted to develop my own demo so you can see what is the power of web extensions and how many things you can build with them. And there's web extensions for everything you can imagine. For translating content, there's web extensions for formatting the JSON that you are seeing in a page so you can see it more beautifully and easy to read.

There's also extensions that fill out forms for you, so you create the content in one extension and then when you go a page and you fill the form, you fill it automatically with this data that you already saved. So you are saving a lot of time and that's a really powerful tool.

But what do you need to build a web extension nowadays? Well, first you will need to know the Manifest V3, that is the standard behind web extensions, and use your trusted JavaScript framework, that for me will be Vue. So the Manifest V3 is just the standard, as I told you, for creating web extensions in browsers such as Chrome, Firefox, and X. Also you can create for Safari, but there's differences between the APIs, but of course we have open source tools to help with that.

The structure of a web extension will be just files, JavaScript, HTML, and JSON files, components like the pop-up, the sidebar, the content scrape, well, we will see them now, or the context that make up this web extension. So there are so many different things that we need to know when we start that we want just to jump into it directly, so you can see them all, or at least a sneak peek of the most used ones, and then you can start exploring deeper in each of them.

So the first file we want to talk about is the manifest.json. It's the file where the essential details of the web extension are defined. So the name of the extension, its description, its version, the functionalities we want to use from the browser, and we need permissions for that. Not everything is available unless you request it, this is important, and where the components in your code are located to make it work in the browser, so you will need to point them out in this file. So this is an example of how a manifest.json will look like for a really simple web extension. Here we see the name, the version, the description that are also the ones that you can see in the Chrome Web Store.

Then let's talk about the background JavaScript file. So this background is a component of the web extension and it has its own context. The context for a background is a service worker. So everything that happens in the background is happening in a service worker. So these are just scripts that run in the background as the name says and handle browser events. So every time you are closing a tab or navigating, they know about it. If you are adding event listeners and you request the permissions that you need, you will get all the information of these navigations and take actions with your web extensions, in case you want to perform actions when that happens.

Then we have the popup and sidebar pages. This is a component that you see when you click on the icon, isn't it? And they have their own context, the popup context. They are just user interfaces, as we will build a single page up. And you can build it, of course, with JavaScript, with Vue, with React, with Angular, with Svelte, any framework of JavaScript or just plain JavaScript. Here we see an example of a popup. In the HTML, you can see that we have some title and we are also rendering some HTML. But the important part is that we are calling a JavaScript file. This JavaScript file is located also in the root of the project, but it's not important for the essential manifest.

So it's really important that they are in a different context. Then we have the popup and sidebar pages. This is a component that you see when you click on the icon, isn't it? And they have their own context, the popup context. They are just user interfaces, as we will build a single page up. And you can build it, of course, with JavaScript, with Vue, with React, with Angular, with Svelte, any framework of JavaScript or just plain JavaScript.

Here we see an example of a popup. In the HTML, you can see that we have some title and we are also rendering some HTML. But the important part is that we are calling a JavaScript file. This JavaScript file is located also in the root of the project, but it's not important for the essential manifest. So we are calling it there as a script to load all this JavaScript in our popup. Every time someone clicks on the button, we will generate all the H1s of the page in red. So it's important to know that when this happens, you will change the color of the H1s of the context of the popup.

What we want is to change the H1 of a page we are navigating. So it's important to understand that they have their own context because they are not able to reach other contexts without communicating with them. If you want to actually change the H1, you will need the content script. Because the content script is inside the page context, the page you are navigating. Instead of having its own context, it's part of another context, the content script. They are just scripts that interact with the web pages we are navigating, injecting functionality, modifying the content, and passing information to the extensions parts.

And they are just scripts that interact with these web pages we are navigating, injecting functionality, modifying the content, and passing information to the extensions parts. So that's how you need to communicate with the content script because content script has more access to the web page than the other contexts. So if we see what we will do in order to actually render the H1s from the page we are navigating in red, what we will need to do is every time we click on the popup button, we will go to search in the browser of Chrome, the tabs. We will see the one that is active, the one we are navigating. And we will say, okay, send a message with this tab so the content script knows about it. And then the message change color will execute the action we want. Here we are just doing a listen to the messages that are being sent to the content script. And then we read the message. If the message is same color, we will change the colors of the H1s to red.

So if in my case I want to perform an action on the web page, I will do the communication between popup and content script. But if I want to execute the action directly on the popup page, then you don't need to communicate with any other component. But just to let you know, you can do that. And last, we have the options page. The options page is just a dedicated page that they created in order for the users that use the web extension to configure the settings. Of course, you can do this configuration in every part of the web extension, if I'm honest. But the options page is a dedicated page that opens. So you can have a really detailed specification of which settings they can have.

There is much more about web extensions that you can do. You can override home pages entirely. You can override the bookmarks and do it whatever you like with all the information that the bookmark page will provide you. You can also change the history entirely or add a new tab. So every time you open a tab, it will appear a different page. We can see that with daily.dev, for example. We can also extend DevTools. So for example, Vue.DevTools is built as a web extension, so you can open a new tab in DevTools and see a different behavior that you would see by just inspecting the code. And you can also add options to the context menu. So every time you right-click on something, you will see a list of options coming from the web extension that you installed. This is amazing.

So every time you right-click on something, you will see a list of options coming from the web extension that you installed. This is amazing. You can change everything you want. But of course, how we will build this? And it is needed to know these browser APIs, know how to interact with them, know the basics in such a level when you are starting. Nah, there's no need for that. We have packages in OpenSearch that will help you. The first one I will explain to you is the WebExtension Polyfy. Basically, Mozilla had a problem when they were migrating from B2 to B3 manifest, and they needed to have a way to get a sense of all the APIs that they have and make it work together. And that's why they created this package that you can use, and it provides a browser, a standard. And then you don't need to actually go chrome.tabs, as I did before. You can use browser, and then you will have a better API in order to build web extensions.

Then we have the webext package also from Mozilla. That is a command tool that allows you to make the development, testing, and packages of web extension much more better. So you can run a command, and then you will see your web extension being run in a new Chrome or Firefox, for example, instance without a profile, and you can actually start testing your web extension free of things you have installed in your own profiles. So it's like a clean slate to start building web extensions. It's really cool, and, of course, I recommend you to learn about it, but most of the frameworks I will show you or the templates that we have already contain this one.

Then we have the storage part. So when we are storing things in web extensions, we are storing things in a special part of the browser. It's not the same we use for web pages. For web pages, we use local storage, system storage. But for extension, we have a special place where we have also local storage, system storage, sync storage. I mean, there's so many types. But the idea is this browser APIs are kind of tedious to learn, and that's why they created this package in order to have a grouper that simplifies the API, and it's easier to maintain also for you in the future. So I really use it with the web extension I build, but, of course, you can do it from scratch if you don't want to use a package, but I recommend to use these ones because they're really cool, and they work really pretty well, and they are pretty well documented also. And then we have the messaging. So every time we are communicating between all these components, we need to know also the browser APIs and how they are called and how you need to actually communicate from one to another. It differs. So this package, the WebX Bridge, just helped my life because it just adds send message, and you specify to which component, for example, background, and it does it out of the box, all these browser APIs that I need to memorize. So it's really cool to use it because you don't need to think about it. Just say exactly what you want, and the WebX Bridge will communicate with Firefox or Chrome in the way that it needs to.

So you don't need to think about it. And, of course, there's no need to use all these packages because they are already in a template. And if you are using React, you can use Vite web extension. If you are using Vue, you can use Vite WebExt created by AMPful. And they have whole model reload, reactivity, reusability, TypeScript, everything set up out of the box, and most of the packages I just explained. So you have everything configured, and you can start without thinking about the configuration of your project. But, of course, if you want to go deeper into it, when you finish using these templates, because then you will get a sense of how to build web extensions, you need to try the framework WXT. It's crazy. It's just the same as we have with Next and Next, but for web extensions. It's really powerful. It provides you a lot of opinionated structure, and that's why I'm telling you first start with a template that is easier that you get a sense of how to create web extensions, and then go with WXT because it's amazing, and it will help you a lot to develop a web extension in just minutes.

It's crazy. So now I wanted to show you the practical use cases I prepared for this talk. For each functionality I thought, the idea I have of them, I need to know what components I need to use in order to have this idea into the web extension. And I need to also thought how we communicate between these components in order to achieve what I want and from where we want to execute the action I want to perform. It's a lot of questions, but it's easy to see with a visual graphic that I created, so let's jump into it. Let's think about as an extension user, I want to configure my preference once, so the settings, and I want them to apply consistently across the entire application. In order to achieve that, I need to use different components. The first one will be the pop-up and options page where I will make the user set up these preferences. Then I will store them in the web extension storage, and in order to do that, I need to ask permission to the browser using the storage permission in the manifest.json. And once I have the permission and I store my data there, I want to consume it from where? From the content script. So this is how the communication flow will look like. From the pop-up or the options page, I will set the value into the web storage, and then I will get the value from the different places I want to render these options. So in this case, in content script, but also in the pop-up and options page because I want to have it aligned with what is stored, isn't it? And it has sense. So now it's time for a little demo on the code I built in order to achieve this. And basically, I use, as I told you, WXD. And it has this opinionated structure, but you can see in the website, the important part here is how I define the storage. So initially, I define the storage using their package. They have a package, as I told you, for open source, of course, for creating the storage without thinking about all the browser APIs. So if I call storage, I'm already calling the web extension storage.

And I'm defining an item so I can have a fallback and a default value for my preferences. And I specify here that I want local storage and not CCN storage or whatever. So here with the local storage, I provide the options I want. Then in order to use them, I created a composable so I can use them between all of the different components without the need of recreating everything again. And the only thing I do is I create a reactive variable. I just set it initially to the value that is already in the storage. And then I create a method where I can set the value. It's as simple as this, but of course, if I want to also the reactive variable to know every time we change in the different components, the new value has changed, I need to add a watcher. But there's also a watcher in this open source package that they have for storage. So you can see that it's really simple. And the only thing I do is use it in the settings component that I'm using in all the places I want to render the settings. So basically, I'm getting everything from the composable I created. And here, I just basically have in the values and setting the values with the update preference. Of course, this is an object that's a mess, I could have done it better, but still, this is not the point. The point is how we use a local storage from the web extensions.

And then in the content script, that is just an empty point in a web project, what I do is call to the preference also, to the reactive variable, and just render the options of my content script menu every time I change them. So let's see a demo of how this looks like. So basically, this is the web extension pop-up, and every time I change something, I'm just saving it into the storage of the web extension that actually, if I go to the options page, we can see. So basically, here, we can see the reactivity being made because of the watcher, of course. And if I inspect, and I go to application, we will be able to see exactly. So here, the extension storage, you can see local, and here we have the preferences. So it's basically the same as we have with local storage, but they have their own extension storage, because at the end, every time you install an extension, you have its own world context, in order to be synchronous between every part of the browser, isn't it? Because you are using the extension everywhere, not just in a web page. So it's important that you know there's a context for that. But yeah. So here, when we do that, the content script now is showing some options here, and are related to the ones I'm selecting here. You can see that it changed in real time also, because of the reactive variable. But yeah, basically, that's how you can use this storage. So now, let's jump into another use case.

Now, I want, as an extension user, to see a menu when I select a test, as I showed you right now. So I can perform actions on that text, and extract its meaning using AI. This is another topic. So basically, we have some components that we need to use. First, the content script, every time we select a text, we want to know that this text was selected in order to render a menu. Then we need also the built-in AI APIs, and to have access to these features from the browser, we need to provide the permission, AI language model origin trial. Yeah, origin trial, because they are in trial. There's no jet something actually out of the box. It's a trial they are building, but it's so cool, you need to try it. So once you have that in the manifest.json, you will need to ask for the trial tokens for each built-in AI API. But I put everything in the readme of the project, so you will be able to do it yourself. Don't worry. And then the background script, where we will actually call these built-in APIs. So this is how the communication flow will work. From the content script, we click on an action, and that will send a message to background. Why? Because background is the one that has access to the built-in APIs, not the context of the page. So that's why we need to go from background to the built-in AI APIs, and then when we get the generated AI text, it will go back to background, and background will send back that text to the content script.

There's a lot of promises around this, but of course it is simpler than you expected. And now let's see the code for this to work. So let's start first with the content script. The content script, at the end... Sorry for this mess, but yeah. So at the end, it has a component where we added the basic action that we are executing, and every time we click on the action, it will show the result, but also if we click on the sparklers, that is just the star, it will generate this AI. So this is the method we are calling and where we are sending the message to background. Here I said, okay, send the message, get AI response with the action type, so basically the description, the usage, everything that we set in preferences, and the text selection from the user. And then the background is the one that should receive this message.

So if we go to the background, to the index file, we will see we have an onMessageListener. This onMessageListener is just getting this information that we sent, and then if the action is what is expected, it will call a method that will select which API we want to use. So here, based on action type, if it's translate, we will go to the translator API. If not, we will use the user summarizer. And if it's any other action, we will use the prompt API that is just a session like a chat.

Just to let you know, to finish the talk, you need to understand that every time you create our extension, it doesn't mean it will go to production. It can be local for yourself, you can open source it, and everyone can download it to use it. So you can make it available without actually publishing it. And in order to do that, you just need to go to extensions, set the developer mode to true, and then load your Unpack extension after you build it. And then if you want, of course, to deploy it, there's a way to do that. You have Chrome Web Store, you have also the Firefox one, and you can just publish it there so everyone can download it, and maybe at some point you can make money out of it. But of course, for this talk, the demo I created, you can use it locally. Just go to the repo, and in this QR code, you have it. So just scan it, go to the repo, download it, try it out, change it, do whatever you want. And thank you so much for listening. I also left in the readme a lot of resources, as you can see here in this slide. And of course, if you have any questions about any developer program like Google Developer Experts, MVP, Women Developers, let me know because I'm part of them, and I would love to help you to join if you want because they give you access to these kind of original trials before anyone else, and that's really cool. So you can find me at Dan Traus in every social media, and let's keep in touch. Thank you so much. Have a nice day.