Plasmo's CEO and co-founder, Stefan, sat down with Marton Lederer, lead engineer of the ArConnect browser extension, to talk about how ArConnect migrated their browser extension over to the Plasmo Framework.
Marton Lederer is the lead developer of ArConnect, a wallet browser extension for the Arweave blockchain. He was looking for a way to refactor his codebase that would be more scalable and easier to use. He found Plasmo and was convinced that it was the right tool for the job.
The biggest selling point for Marton was that Plasmo is not just a template - it's a product that is constantly being updated and improved. He was also impressed with the storage module, which made it much easier to work with the data his extension was dealing with.
Since migrating to Plasmo, Marton has found that he can build new features much faster and that his codebase is more manageable. He advises other developers considering using Plasmo to take the time and read the docs thoroughly to take advantage of all the features the framework has to offer.
Before we get started, just wanted to share a quick note about Itero. Productionizing your browser extension is tough. That's why we've built Itero - the world's first staging environment and platform for browser extensions.
Read the full interview below!
Before ArConnect, there weren't any wallet extensions for Arweave, and it was thought it would be impossible to make them.
Marton Lederer: ArConnect is a wallet browser extension for the ArWeave blockchain. It is our browser extension and one of our main products. ArConnect is a crypto wallet for Arweave, a blockchain-based decentralized storage provider.
Essentially ArConnect is under th8ta, which was founded by Tate Berenbaum, me, and several other members. Before ArConnect, there weren't any wallet extensions for Arweave, and it was thought it would be impossible to make them.
But I made one because it was very, very insecure that people were essentially uploading their private keys to websites. At that point, it just depended on how malicious the website's intentions were.
I'm sure everyone working with Chrome Extensions also experienced that it's very, very hard to build a completely scalable code base.
Marton Lederer: ArConnect was based on a template with Webpack. It was not ideal. So then we made it use esbuild, which made it much faster. But it needed a lot of hacks because many plugins were not supported that came from webpack.
We needed to progress with the code and grow the code base. We encountered that it was not scalable, partly because of esbuild and primarily because of how Chrome Extensions worked. I'm sure everyone working with Chrome Extensions also experienced that it's very, very hard to build a completely scalable code base.
It was obvious that I needed to use Plasmo because there's really nothing like it on the market currently
Marton Lederer: I feel like it was an instant, like, it wasn't really a choice. It was obvious that I needed to use Plasmo because there's really nothing like it on the market currently. There are browser extension templates, of course, but Plasmo convinced me that this was how to do the refactoring. The development and the initiation process felt more guided. Because you have these schemes, and you have these rules that you have to call the popup file, popup.tsx – all of that stuff. It's very, basic, but these things just give such a secure feeling to the developer. This instantly convinced me over just using some random template on the Internet.
Another advantage over templates for extensions is that Plasmo is essentially, one package, and it's a product, not just a template. It's not just a GitHub repo that someone created for, you know, future use for themselves because that's usually the case or a tutorial from YouTube. What convinced me as well was that because this was a framework, I was sure it's gonna get updated. And even if it doesn't, it's much more robust and secure than just some random template.
The storage hooks for React were also compelling, as was the overall storage system. It's much easier to use than any other libraries or the basic Chrome or Firefox APIs.
I could sum this up with Plasmo is not just a template. It guides people, like how Next.js does. I don't think Next.js is very popular because of all of its features and functionalities. It's popular because it has such good and easy-to-follow standards and rules. Because of that, it guides you very well.
That's the main selling point of Next.js. Not the fancy new features they bring in. Half of the developers will not use them because they only know the core. Even I don't know the new features, and I need to be fully aware of them. So, the sense that you're being guided gives you a lot of security, I think, and the secure feeling is important.
Stefan Aleksic: That makes sense. One of the big things that we want to have in the framework is an opinion, and developers don't need to worry about it. We give them the core opinion, and then they can move from there. That's the idea.
Marton Lederer: Yeah.
Stefan Aleksic: You guys already had opinions and an entire codebase built before you migrated to Plasmo. Were there any rough edges when you transitioned to using Plasmo? Any major challenges?
Marton Lederer: This answer might not be very useful because I can't point out anything wrong with Plasmo itself. We didn't just go with the refactor. We didn't just want to integrate with Plasmo. We wanted to use one of its main features, which is Manifest v3 support and the blockers that came from Manifest v3.
Marton Lederer: I started looking into it and studying it for the refactor at the beginning of August. So that's when I read the docs. I created a few sample extensions, nothing fancy, and I think around the end of August, I started working on the refactor itself. So that's when I started using Plasmo in ArConnect.
Marton Lederer: Only positives, really. I think the goal was for the users not to notice. Any changes related to Plasmo were more for developers. Yeah, so I wasn't concerned about that at all.
Marton Lederer: I'm not tracking it, but I can definitely say that it has made things a lot easier.
What really helped a lot with the storage module is that the data that it parses and reads is all JSON
Marton Lederer: Probably the storage modules? Yeah, the storage because we're dealing with many storage-related things here, you know, storing custom settings of the wallets and the users' private keys. So yeah, that was one of the features that I really enjoyed, and I was happy to find it out because it wasn't instantly obvious from the docs. What really helped a lot with the storage module is that the data that it parses and reads is all JSON. It's not a very complicated feature, but it was so surprising that it did that by itself, and I didn't have to worry about having to JSON parse and all this stuff. So yeah, that definitely made everything a lot faster and easier.
Marton Lederer: We had a complete design refactor. So I had to recode everything from the ground up, but that's not a Plasmo thing. In terms of the functionality and how the old thing worked, the only thing I needed to change, but it was actually making things much better, was using the use storage hook. Which, you know, just removed a ton of code.
Marton Lederer: It would be scary. It depends on what unavailable means, but I feel like because it's, you know, it's already on NPM. I'd be comfortable with using the package for a long time.
So if I could rely on it that way, it wouldn't affect us in the short term, but yeah, that would be scary.
Just look at the examples and then start migrating the code base because there are a lot of smaller things you wouldn't notice at a glance which could massively reduce the lines of code you use and reduce how complicated your logic is
Marton Lederer: First off, I feel like, usually, we as developers make mistakes reading docs. Once we look at the first page of the docs or a readme, we tend to assume that we know everything about the project and just go ahead and implement it. But no, you have to read the docs thoroughly, especially in the case of Plasmo, because it has so many cool small but very useful features. I feel like first, read the entire docs twice. Just look at the examples and then start migrating the code base because there are a lot of smaller things you wouldn't notice at a glance which could massively reduce the lines of code you use and reduce how complicated your logic is.
...it feels like Plasmo is another layer on the Chrome and Firefox extension APIs because it includes other utility functions that should be built into the browsers themselves, but they're not, and you wouldn't want to implement them yourself because it's just not scalable.
Marton Lederer: It would probably be very much hard-coded, and I would not even attempt to mount a React component. It would just be simple HTML. Even though everything else is in React, I feel like that's another feature.
Another thing is that implementing a new feature was much longer, and the procedure would look much longer. Even if it's a small feature, the same amount of code in a React component will take much more time. Because, for example, we didn't have Hot Module Replacement or Live Reloading, and that's something that simplifies a lot of things.
Because of the nature of your extension, there are some functions you never reuse, but are long and complicated. Like, let's say, for example, you want to mount not necessarily on the popup, but you want to mount a component into the DOM. In ArConnect’s case, that only happens once in the entire extension, but you need to know how to implement this whole thing, that's quite a few lines of code.
That makes it much less scalable because you build this into one function. When in reality, you could have this as a utility function. You don't want to include this in your logic, but you still do because you don't use it anywhere else, so that’s where Plasmo comes in. You don't have to, essentially, spam your code base with the functions that should be built into the Chrome API, for example, but you end up implementing them because you still use them. So yeah, it feels like Plasmo is another layer on the Chrome and Firefox extension APIs because it includes other utility functions that should be built into the browsers themselves, but they're not, and you wouldn't want to implement them yourself because it's just not scalable.
With Plasmo, I liked that you could see through your code since it's readable and developer friendly.
If you're interested in migrating to the Plasmo framework, or you're ready to start your browser extension journey with a new extension, check out the Plasmo Framework. Plasmo is the easiest way to build a modern browser extension.
Read more posts like this in your inbox
Subscribe to the newsletter