WXT vs. Plasmo. Some thoughts on migrating from Plasmo to WXT.

[aiktb]

TL;DR

This is the conclusion I got after spending a day migrating my extension from Plasmo to WXT:

Plasmo takes extension development out of the primitive world, and WXT really brings it into the modern world!

Something better than Plasmo in WXT.

Effective HMR

Plasmo HMR is not "React-only", in fact in the extensions I've written using React, HMR only works when the page is very small, most of the time HMR doesn't work.

But WXT HMR works really well, I rarely have to refresh Popup and Options pages, content script changes trigger automatic page refreshes, and I can use the Alt + R shortcut that is automatically registered in development mode when I have to reload the extension due to manifest changes. It's amazing!

Based on Vite

No Parcel.

Anyone familiar with plasmo will have encountered a bunch of Parcel bugs upstream, yet I can't do anything but sidestep them with some ugly code, and I haven't encountered any weird Vite bugs tripping me up in my time with WXT!

WXT allows us to fully utilize Vite existing features and plug-ins, while Plasmo does not allow us to intervene at all.

Vite documentation is much better than Parcel, and I know how to do something with Vite, but Parcel I don't.

Vite is one of the most popular tools out there and many people are willing to invest in it, but Parcel is not.

This is probably Plasmo biggest mistake.

Better maintenance of the status quo

Plasmo is dead. The maintainers have spent very little time on maintaining Plasmo in one year. No one is handling PRs and issues, and most of the bugs do not exist in WXT.

If you want help, don't use Plasmo.

Expose UI framework mount process

Just using Vue as an example, Plasmo completely hides the app.mount process, the problem is that many libraries rely on app.use(...) , hiding this makes it impossible for developers to use these libraries smoothly, especially component libraries.

WXT will add some boilerplate code by exposing this process, but I think it's worth it compared to the flexibility it brings.

Hooks and Assets

Plasmo doesn't make any hooks public, nor does it have a public directory, and can't even do the simple function of adding a few files to the build product, whereas that flexibility should be necessary.

Config File

Plasmo doesn't support plasmo.config.ts, manifest.json overrides can only be written in package.json, and wxt.config.ts lets me utilize TypeScript to prevent spelling errors and more.

Not to mention that WXT has many configurable items and hooks that can be used, a separate configuration file is very necessary.

More DX improvements

• WXT formats the manifest.json file in development mode.
• Automatically generate types for browser.runtime.getURL.
• WXT tree-shaking is much more efficient than Plasmo, and you may see noticeable bundle size reductions if you migrate.
• WXT does not add hashcode to file names in the build product, which helps speed up store reviews.

Breaking Changes

1. WXT does not have a built-in messaging module now. Plasmo built-in messaging tool is very useful and can automatically generate types. Migration can use @webext-core/messaging, but the types need to be written manually. This may change in the future.

2. wxt/utils/storage is not compatible with Plasmo. The behavior of wxt/utils/storage is closer to chrome.storage.*. The two have inconsistent formats for the same object stored in storage. The migration strategy of wxt/utils/storage is useful for this, but you may need to write some deserialization logic. This is the most important issue to pay attention to in migration.

Apart from the two points I mentioned, I believe that you can reuse most of the code in the Plasmo project.

[aklinker1]

Thanks for the feedback! I haven't used plasmo for an extended period of time, so it's good to hear positive feedback from someone who has used it for longer.

I could add sharp to generate smaller icons and make them greyscale in development. Not sure if I want to include that dependency directly, so maybe in a WXT module? With tools like Figma, it's really easy to generate assets of multiple dimensions nowadays. But the greyscale thing is a good idea.

[aklinker1]

Great example of how to write a module!

[Timeraa]

Made a module for it: #851

[vanarok]

WXT is the best tool I've found for developing browser extensions. Previously, I had to set up EVERYTHING manually, from hot reloading to building the extension. When I decided to write my own extension, I came across WXT, and from start to finish, I had NO issues during development. Special thanks for the detailed documentation.

[stevebeauge]

Moving from plasmo to wxt has the benefits of decreasing my bundled extension (I mean the zip file) from 5MB to 500KB. I guess the tree shaking is effective here, and wasn't using plasmo

[GorvGoyl]

We also migrated our browser extension from Plasmo to WXT and wrote about our migration process, including the challenges we faced and how we resolved them. Here's the article for anyone looking to migrate as well: https://chatgptwriter.ai/blog/migrate-plasmo-to-wxt

[remusris]

I decided to upgrade plateJS (an RTE) from v36 to v40 to match my web app and fix some bugs inherent to that library but parcel refuses to bundle/compile this new library. Just took a peek at WXT and it didn't have any problems bundling the code so it looks like I'm going to make the switch. Plasmo has paid functionality to deploy it via enterprise feature of chrome on their paid plan. I'd love for WXT to have something similar to this. If anyone knows how to match that functionality in WXT let me know.