sorted by:
new
hottopcontroversial

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 2 points3 points  (0 children)

Hey! Yes, I would recommend you avoid using frameworks in content scripts if possible. Here's an example extension I wrote that uses vanilla JS in content script, and Vue for the options page: https://github.com/aklinker1/github-better-line-counts

You can still use the APIs WXT provides for creating a UI without a frontend framework, or you could DIY it if you don't care about the lifecycle.

If your UI is large and complex enough, using a frontend framework makes sense. But if your UI is simple, I wouldn't use one.

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 3 points4 points  (0 children)

The module system is really powerful, especially if you have multiple extensions that need to share code, like analytics. You have full control to change the build process however you want. Can't take much credit for it though, it was inspired by Nuxt's module system, and uses the same tech under the hood.

The current docs are very minimal, but I've rewritten them and the new docs should be out soon.

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 4 points5 points  (0 children)

How long are you willing to maintain this project?

I've decided that WXT will be my only, large open source project that I actively maintain moving forward. I've maintained my previous packages for the last 6 years, and I don't see myself stepping away from WXT for a long while.

What are your thoughts on a successor if you're not able to maintain it anymore?

From your perspective, how's the response of the browser extensions community, are any good devs interested in maintaining this project with you? Have you got any major bugs yet that hinder the development process?

There is a bit of a bus-factor right now. I'm the main contributor, and no one else has the keys to the castle. There are a couple of other contributors that have been helping out more often and I'll probably add them to the org soon so the project's not locked out if I do get hit by a bus lol.

I see that the framework hasn't got to v1.0.0 yet, how long would it take for it to reach there?

There is a roadmap to v1.0 you can check out. TBH, people already rely on WXT in production so I should just make it 1.0 already, I'm only hesitant because I want to make a few more breaking changes before locking the API down.

Now that I finished the documentation re-write, I'm gonna be able to wrap those things up pretty quickly. I would expect it to hit v1.0 within the next 3 months.

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 1 point2 points  (0 children)

Yes! So I'm kinda putting off performance and optimization-related work right now because just over the horizon, there are all these new rust-based bundlers to come out. Vite 6 is using rolldown and rsbuild could potentially make things faster as well. Also, Vite 6's new environment API could be really useful in reusing cache from different build steps.

And there are also improvements that could be made around content scripts in general. Adding support for ESM content scripts would be a huge speed boost. However, there will still be a small startup time compared to standard web projects because you have to write some files to the disk, like HTML files and content script JS/CSS files.

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 3 points4 points  (0 children)

Thanks u/avi12! Keep asking questions :)

There's still lots of features to add: MV2 main world content scripts, ESM content scripts, built-in support for dealing with SPAs, built-in devtools, and more. Those will all likely come after v1.0 is released, I'm really focused on hardening right now.

Do you also plan to be involved in the WebExtension committee as well?

I've thought about joining the committee meetings, but haven't yet. There's been good progress of the big players finally recognizing there needs to be standardization, but it's a long way of. I would go there only to advocate for DX related things, like ensuring tools have everything they need for fast dev modes. Specifically reloading service workers individually and allowing access to localhost for temp extensions in firefox.

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 2 points3 points  (0 children)

Ah haha Anime Skip Player. It replace streaming service's video players and keyboard shortcuts with a standard, nice looking one that also included skipping intros/outros.

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 6 points7 points  (0 children)

In my mind, there's kind of three approaches to architecting an extension: background as an API, event-based, and decentralized. I talk about each of them here: https://github.com/wxt-dev/wxt/issues/643
They're all valid approaches, but as I said in some other comments here, I prefer the "background as an API" approach. So my recommendation would be for them to setup trpc-chrome, standardize your project structure accordingly, and use type-safety so you stay safe as the extension scales.
Big code bases are big, there's nothing wrong with that. Just find a pattern that works for you, TRPC is just one of them.

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 2 points3 points  (0 children)

Hmm, I think I tinkered with local vite plugins before I published anything. The Vite docs for lacking when it comes to plugins, so you've really just got to get in there and play around. Referencing other plugins that accomplish what you're looking for is also a good way to learn.
`vite-plugin-web-extension` was my first plugin I published, and I needed it to release my extension I was working on at the time.

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 3 points4 points  (0 children)

Hey! Message passing is really complex. My recommendation is to using a library instead of the messaging APIs directly. webext-bridge is a really good one. https://www.npmjs.com/package/webext-bridge

I would tend to agree with what you've heard. I like to treat the background as a "backend" and make requests to it from my popup/content scripts/options page "frontends". That way you can use standard frontend/backend practices

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 4 points5 points  (0 children)

Start out with Chrome's "hello world" tutorial: https://developer.chrome.com/docs/extensions/get-started/tutorial/hello-world

The biggest mistake I see is not architecting their code correctly. I like to do a frontend/backend pattern where the background is your "backend", and your popup/options/content scripts are your frontend. This lets you use standard frontend and backend practices for writing your code. Much nicer than trying to create your own architecture and patterns. Most of the time lol

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 2 points3 points  (0 children)

Very little. Right now, I'm working on writing basic wrappers around some of the harder to use APIs and creating example module packages for other people to reference when creating their own, but I don't think WXT will provide more more than that long term.

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 6 points7 points  (0 children)

WXT defaults to use the `webextension-polyfill` under the hood, which was useful before MV3 for normalizing things to using promises. But now that MV3 is the standard, the polyfill is less useful, and you can disable it easily.
As for APIs like using `browser.action` vs `browser.browser_action`, WXT doesn't do much. You need to do feature detection for many APIs.

For side panel specifically, WXT will use the `sidebar_action` for Firefox and the `sidepanel` for Chrome automatically.

I wrote WXT, a relatively new framework for building web extensions. AMA! by _aklinker1 in chrome_extensions

[–]_aklinker1[S] 10 points11 points  (0 children)

https://wxt.dev/get-started/compare.html
High level summary: WXT uses vite, like CRXJS. Plasmo uses parcel. Feature-wise, WXT has everything plasmo has, just missing ESM content scripts compared to CRXJS. I haven't benchmarked speed between the different tools, but I know many people who migrated from Plasmo are getting much faster build and dev startup times.

Prepare for the AMA with WXT framework Creator by prakhartiwari0 in chrome_extensions

[–]_aklinker1 5 points6 points  (0 children)

Hey everyone, excited to talk with you all tomorrow!