Ben:
Hello, and welcome to PodRocket. Today, I'm here with Stefan Aleksic, and Louis Vilgo, who are the co-founders of Plasmo. How are you guys doing today?

Louis Vilgo:
Very well.

Stefan Aleksic:
Yeah, not too bad. How are you?

Ben:
I'm doing well and excited to have you on the show. So, maybe you could begin by telling us a bit about what you're building?

Stefan Aleksic:
Yeah so, basically we're building Plasmo, which is the developer kind of uh, tools for browser extensions.

Ben:
Got it, so developer tools for browser extensions. I've built a couple of Chrome extensions back many years ago so I haven't done much recently. So maybe take us through for folks who aren't familiar, what does it look like before Plasmo to build, let's say, a Chrome extension? What does that process look like? And then, how does Plasmo help make that easier or better or faster, or whatnot?

Stefan Aleksic:
That's kind of the basis for why we got started with Plasmo, because Louis and I were building a Chrome extension and it's pretty tricky. So right now, if you want to build a very simple extension, for example, let's say, you want to have a pop-up open up when you click on the Chrome extension's icon, and then maybe you want to have an increment, something super straightforward. You can probably do it in less than five minutes with any standard front-end framework. With a Chrome extension, it's actually very tricky. So, right now what you have to do is, first of all, you have to know what a manifest file is. And this is the basis for all Chrome extensions. It's what Chrome reads whenever it loads your Chrome extension. And this file basically tells Chrome, hey, the pop-up HTML file is in this file path, the background service worker is in this file path, it's a JavaScript file and so on and so forth. It defines the metadata.

Stefan Aleksic:
So, first of all, you need to understand that sort of voodoo magic of what is this manifest JSON file and figure it out. And then, the next interesting thing is, how do you actually React to... First of all, how do you bundle all of this stuff together so that it all works with this entry file, defining your manifest? And then secondly, how can you actually mount or React onto the pop-up? So, once you've solved all of those issues, now you have a web pack config that you've kind of mastered and it's been several hours. And then, finally, you're at a point where you can maybe set up an increment thing with a React app. So that's the idea at the moment with, before Plasmo, what you would need to do to set this stuff up.

Ben:
Got it. So, Plasmo kind of streamlining that process to go from an idea to building your Chrome extension with our...

Stefan Aleksic:
Yeah so what works basically before Plasmo, you need to create a manifest, you need to compile your React app, you need to also handle the index, the HTML page, and so on and so forth. After Plasmo, all you do is just exporting a React component, you done, that's it. All you do is just exporting a React component, very simple, it's like an AGS page, an AGS page is like you make a page directory, add an index like TXX, exporting a React component, done. You got a page. Exact same way with Plasmo, you make a pop-up dot TXX file, you export a React component, done, that's it. The rest is handled by Plasmo, everything. Yeah, that's a stash contrast.

Ben:
If I was going to build a Chrome extension today, I didn't know about Plasmo. I would probably Google... And I knew it needed React, kid of because I wanted to build a live UI, I would look on GitHub for some sort of boilerplate of a stack that someone's already built that has React, Chrome extension, everything, and just kind of clone some GitHub repo that has a lot of stars and use that. That would probably be my process. So does that even exist? And then how does Plasmo improve upon some kind of prebuilt set of tools that someone's glued together and provided documentation for?

Stefan Aleksic:
We actually saw a lot of... actually Plasmo right now is, I think, one of the highest star out there in terms of the Chrome extension framework. Actually we're at 4K star compared to, I think, one of the few contender out there, with a thousand star and so on. So I think we would be at a pretty high ranking in terms of the search results on this tool on GitHub. Let's say a month ago when Plasmo was... Just a month ago, we were only at 25 stars. So we grow pretty fast. So just a month ago you would find a lot of these extension kind of daff pack that it looked like Create React App. It looked like a Create React App Boilerplate, that has custom router, very basic bare-bone kind of set up. So that new Developer has a lot of flexibility, but the Developer will still have to go and read the official documentation from the Chrome API team, which is horrendous because it is just very, very technical.

Stefan Aleksic:
And they are still migrating from MV2 to MV3 so it gets a little confusion now. Hey, which one should I use? Is this MV2? Is MV3 ready guys. Oh, by the way, MV3 means Manifest Version 3. So there is actually a diversion between the API from the Chrome extension team, moving from Manifest V2 to V3 and there is still a lot of confusion within the documentation that Developer has to sort out. And furthermore, there is... So it's either using Webpac or some of them actually use Grow Up or Create React App. So that is a bundler to bundling your extension code.

Stefan Aleksic:
So now you have to learn the same task for that bundler. How do I use this bundler right? Because sometimes you might want dev tooling. You might want to add dev tool. You might want to add an option page so on, so forth. So now you have to learn the bundler. And lastly, the manifest is still a problem because now you actually have to managing three different manifests for each browser. With Plasmo model, you only have because Plasmo actually compile that manifests for you. So you can actually targeting all three or any browser combination like Chrome, MV3, Firefox MV2, Opera MV3, Safari MV2 or iMV3. And because we actually take in the parameter and we compile the manifest, you don't have to manage all three. You don't have to basically re-run your manifest anymore. Tied up in Plasmo, it's all the same code base, producing all the bundle for you, for each browser and off you go. So that is the key type differences

Ben:
Enjoying the podcast, consider hitting that follow button from more great episodes.

Stefan Aleksic:
One of the things that we think about a lot is, with all of these sort of boiler plates you have, as Louis said, all these different configs. And it's all in this imperative sort of way. If you want to add... Let's say the boiler plate had a simple... This is how you would have a pop-up with a React app and then maybe a background service worker. And then when you wanted to add an options page, now you had to mess with the web pack config. Then you had to add it, then you had to know what to add in your manifest config and so on and so forth. It's all these configs. And the idea behind Plasmo is we want to kind of think about it in the file system level, where when you add a file on the file system, all the configs are properly generated for you. So you don't have to think about things in terms of configs, but rather in terms of files. So that's kind of the abstraction.

Ben:
And taking a look at Plasmo's website, there's kind of the three main tenants of the platform or develop test publish. We've touched on some of the ways where Plasmo helps with development, help me understand a bit more of what you do on the testing side of things and what are some of the problems that you solve.

Stefan Aleksic:
So one of the things that kind of we've heard a lot from Chrome extension developers is, it's really hard to iterate and you have to really be conservative. The reason why is because submitting to these web stores like Chrome web store, Firefox add-on store, that takes time because your extension, every update needs to be reviewed. Sometimes the review takes hours. Other times it could take days, sometimes weeks. I've heard horror story from one developer where they actually had a bug in their Chrome extension and due to a... So they fixed it within 30 minutes or an hour. They sent it out and unfortunately the fix it took two months to actually get through and approved. So this is why Chrome extension developers really need to be conservative. So that is not conducive to iterating quickly. You could do tricks like AB tests and so on and so forth, but that's sort of a bandaid to the problem.

Stefan Aleksic:
The thing that we've kind of built in this space is this thing called test beds. So we offer this SaaS product, which basically allows you to have beta users. So for example, let's say it's your dev team. So right now, if you want to have your developers use the latest version of your Chrome extension, you typically need to send them a zip file. They need to enable developer mode. They need to do all these other steps and then drag and drop the extension locally. And then you do that for every update, it's super annoying. So we built this thing called test bed and what it does is, it automates all of that for you. So that way, whenever you push a change, it automatically pushes it out to all of your beta testers, and then they can get the latest update of your extension. So you can iterate quickly. That's kind of the idea, yeah.

Stefan Aleksic:
So you can think of test bed as the... It's a Chrome web store, but target specifically for that developer.

Ben:
Yeah, I mean, it sounds very analogous to using test flight for a mobile app. And I'm curious to understand a bit more about the Chrome... This is actually something I'm not familiar with, Chrome's process for reviewing and approving extensions. If I want to put a new extension in the Chrome app store, what does the approval process look like? What are some of the gotchas that can cause a slow down in that? And then, for future upgrades, do you go through the same level of rigor or is it less for upgrades and original approval? How does that all work?

Stefan Aleksic:
Yeah so, the way that it works is I think obviously with these sorts of things, you sometimes have to reverse engineer them because they're not so transparent, but from what we've seen, it's sort of a two step process. So they perform some sort of static analysis where they kind test your extension to see, is it doing something malicious and so on and so forth. And then once it goes through that static analysis approach, then we've had cases where... Like, when we built our own extension, where we actually saw someone in Kentucky or something like that on our analytics use our beta version, which we just submitted. So it seems like they actually have humans that install your extension and then actually test it out.

Stefan Aleksic:
So some Google contractors or engineers. So that's kind how the process looks and in terms of gotchas and things, I mean, it's really riddled with that because I think it's sort similar to any sort of complaints you've heard about the iOS app store or anything. There's times where things go through and get passed an approval. And then later they fail, even though you haven't changed this specific thing that was failing. It seems kind of arbitrary and Google has a list of, sort of errors or things that the reasons why extensions haven't passed review. So these things can include even things like having permissions set on in your manifest file and then not using them. This is a common thing that happens often, but this sort of stuff.

Ben:
And what does it look like on some of the other platforms, Firefox, and I think safari has extensions now, and I'm not sure some of the newer browsers like Brave, is it a similar process or different for each one?

Stefan Aleksic:
Yeah, so in terms of Firefox, from what I've heard, Firefox is actually the quickest. So typically turnaround time is very, very fast in Firefox. So it doesn't have that problem. Whereas, I think Chrome and Edge, they have their own web stores respectively, and both of them seem to have this kind of turnaround time. Now the interesting thing is Brave and then I think a bunch of other Chromium based browsers, they actually piggyback off of the Chrome web store. So they don't actually have their own web store. They simply use the Chrome web store.

Ben:
And let's talk now about the final of the three tenants of developed test publish. So once it comes time to publish, how does Plasmo streamline that, especially when we're talking about publishing to multiple platforms.

Stefan Aleksic:
So we actually have... There's a solution that we create called Browser Platform Publisher. It's a key of action going on top of your extension repository story. And what it does is basically using the official Chrome Web store API and also Firefox Mozilla. They call it the Ammo Mozilla, add on Mozilla whatever API and also the Edge add on API. So it use those API to actually submitting your extension package for you, assuming that you're supplying all the keys, for example, API keys, authorization and develop key, so on and so forth. So with all the key, that action will actually submitting your extension for you.

Stefan Aleksic:
So that will streamline the process for all extension store. And we are actually looking to... We have been working on the safari store for a while now. There's a lot of rigorous engineering required for the Safari store because it's actually a Safari process converting a Chrome extension to Safari extension. The tricky thing is, it only supporting MV2, the official one. But safari right now is actually MV3. So the official command line to do so actually obsolete and basically, there's a lot of... There's iteration, a lot of working to be done over there until we actually can supporting MV3 fully on Safari. So we haven't fully publishing that yet, but actually using Fastline underneath to do all the submissions, similar to how expo also using Fastline to submitting apple app store to the test part.

Emily:
Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts, so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right, back to the show.

Ben:
Super helpful to understand the full scope of the platform. Looking now at kind of the business, so help me understand a bit more about Plasmo as a business. Is it a free product, a paid product, or what does that all look like?

Stefan Aleksic:
Yeah so in terms of the business, so Louis and I were both really strong proponents of Freenove software. And so that's something that we really wanted to kind of think about when we thought about how do we want to structure Plasmo. So the way we're kind of thinking about it is, we have the Plasmo framework and that makes it as easy as possible to develop from extensions from scratch. And then the idea is when developers want to productionize their app or productionize their Chrome extension, why they want to kind of make sure that it's solid, they want to iterate quickly on it, stuff like that. Then they would use the SaaS offering that we provide, which is called Itero. And then that's sort of the idea.

Ben:
Got it, and is that something that's already launched or that's a feature roadmap for Itero?

Louis Vilgo:
We on better right now, it's on better. We have a wait-list of people that trying it out right now. It's like three bucks a month. We are slowly launching it, but we are not properly launching it yet. Because there's a lot of rough-ash internal [inaudible 00:18:30] especially with the Chrome update mechanism. So Itero or the test-bed actually use the Chrome native update mechanism, but it's quite buggy at the moment in that somehow the update checking of the Chrome browser itself could be a quite buggy. So we are still debugging right now, but the updating mechanism and the uploading mechanism, and also we are recently shipping also the ability to uploading a new version of your extension using your COI. So basically, we close the entire loop of the dev off on the dev side for the test bed. But yeah, we have yet to launch it publicly yet.

Ben:
So I'm curious to learn a bit more about the backstory. So what led you to want to go and build this company and start Plasmo both in terms of the why now and your personal story, but also why now Chrome extensions. Rather extensions have been around for a long time and maybe what's changed recently that's kind of opened the door for this kind of opportunity to build a platform around launching and publishing.

Stefan Aleksic:
Yeah, so just to give some context around Louis and I. So we were roommates in college and we were both kind of hackathon fanatics and we worked on a ton of projects together. We were super fascinated by browsers, just the internet in general, agriculture and so on. And one of the projects that we worked on was this thing called Hyper proxy. So we kind of made a browser that can allow people to access these sort of websites that were on the dash protocol. So the dash protocol was sort of this native protocol, and we basically poured over to the browser. So we kind of had experience there, building some sort of browser stuff. And a few years later, which was about a year ago, we chatted again about browsers. And at the time I was working on a cyber security job and I was kind of complaining about how... One of the things we got in that job was people would report suspicious website, suspicious emails and things like that.

Stefan Aleksic:
And I noticed that reporting suspicious websites was really annoying because people had to screenshot it and then tell me, where did it come from and stuff like that. So I was like, oh, maybe a Chrome central would be good for this. So we built one, but we didn't really get a lot of... It was the problem that we were solving wasn't enticing enough to people. So we decided to go back to the drawing board and think about, kind of brainstorm and stuff. And after a week of brainstorming and we thought through a bunch of problems and the one that really stuck up out to us was dang, building that extension that we just built was actually much harder than it needed to be. And we both came from these mobile app development and front end backgrounds. And we were just like, maybe we can do something about that.

Stefan Aleksic:
So that's why we decided to build this developer tooling. And one of the things that we thought about a lot is this idea that right now, the internet browser, that everyone uses is built for everyone. I think Chrome reached some crazy number of users and things like that. It's not specific to people and this is what people use every day to do their jobs. Yet it is so generic. It's sort of a marathon runner using shoes that they picked up from a local store.

Stefan Aleksic:
It's not tailored to the marathon, it's just for everyday use. And that doesn't make sense to us. So we had this big thesis of the browser companies themselves are likely not going to do anything about this. And the Chrome extensions and browser extensions in general, are where this sort of problem will be solved. And the idea is, in 5 to 10 years and it's already happening now, you'll see that there's going to be a salesperson stack of browser extensions, where if you don't use these browser extensions, you will not be as efficient as someone using them. And you probably won't do well in your job compared to that other person. So that's sort of the idea and we decided, why is this not coming faster than it should? And it's because, it's super hard to make these Chrome extensions and browser extensions. So that's our thesis is, we want to make it as easy as possible so that this thing of this market can really flourish.

Ben:
Got it, yeah, makes sense. I mean, definitely anecdotally seeing lots of companies continue to launch Chrome extensions. Sales has been a use case. I've seen a bunch of different tools out there that give different UIs on top of Salesforce or things like that for sales people where the nice thing is that an individual salesperson can just find that extension, install it. They don't need to get permission from someone at the company because it's just like modifying data they can already see in their browser. So that's certainly one of the advantages of Chrome extensions from a business tools point of view is the ease of adoption by an individual employee without going through an IT process.

Stefan Aleksic:
Yeah, exactly.

Ben:
And so, curious to learn a bit more about the roadmap in the future, we talked a bit about Itero and the eventual paid product, but beyond that, what does the next year look like in terms of what your product roadmap?

Stefan Aleksic:
So on our end, we want to become all in one platform for developers to create extensions. So as you said, going through those stages, boost strap, testing, publishing. So sort of like, similar to Expo or Vercel, but for browser extensions, and then eventually thinking long term, we have so many ideas of where to go. The key theme though is, we really want to innovate in other areas in contexts where extensions have been underutilized. So that includes stuff like enterprise and so on, and really think of more about how to solve other unique challenges with extensions and enable that.

Stefan Aleksic:
One other thing I want to add to the testing side of Plasmo is the idea of end-to-end testing and testing cross browser for extension. I thought, an extension can be published to different multiple browser, but to test and make sure that extension can work on all extension, on all browser, using it the same code base, I think the solution for that in the long term would be mainly end-to-end testing and likely using some kind of a test suite, basically a hundred standard test suite that we are thinking about. So we are planning some kind of a standard test suite on end-to-end side, that would... Basically you submit your extension, and we run your extension through this standard test suite and also run it through a million of other website to make sure that the extension actually working on those website and on those browser kind of simulation, right? The browser kind of using puppeteer play, right? And that hopefully can actually streamlining the review process on the web store. And yeah, it's a certification of your extension.

Ben:
Got it. Well, Stefan, Lewis, it's been great having you on the show, really appreciate you coming on. And I've enjoyed learning about Plasmo. For folks that want to check out the product it's Plasmo.com, P-L-A-S-M-O .com. Aside from going to the website, is there anything else you'd recommend in terms of ways to learn about the product or get started?

Louis Vilgo:
Definitely joining... take a look our documentation docs.plasmo.com and also join our Discord community. We have a large community of people on this board that talking about extension, how to work with Plasmo and asking for feature requests. You can join the Discord by using Plasmo.com/s/d. So S for social and D for Discord.

Ben:
Great. Well, thanks again, guys.

Stefan Aleksic:
Thanks for having us.

Speaker 5:
Thanks for listening to PodRocket. You can find us @PodRockedpod on Twitter, and don't forget to subscribe, rate and review on Apple podcasts, thanks.