Browser Extension Starter

All three plug into WXT's build the same way, so the honest tradeoffs are ecosystem size and bundle weight rather than raw capability. React has the deepest ecosystem and the most extension tutorials to copy from, which matters if you're new to Manifest V3's message-passing patterns and want examples to reference. Vue.js trades some of that ecosystem for a gentler learning curve and less boilerplate, a fair swap for the small popup and options-page component trees most extensions actually ship. Svelte compiles away its framework at build time, so it produces the smallest bundle of the three, and bundle size matters more here than in a typical web app: a popup's script loads every time the user clicks the toolbar icon, not once per session. Pick React by default, Svelte if the extension is UI-light and load time is the priority, and Vue.js for React's component model without React's ecosystem weight.

Supabase is only worth adding if the extension needs data to follow the user across devices or browser reinstalls, or needs real sign-in. A purely local extension, a note-taker, a productivity timer, a per-site settings tool, can skip it entirely and store its state with the browser's own storage.local or IndexedDB APIs, which work offline with no external dependency and no account requirement. What you give up by skipping Supabase is exactly what it adds: cross-device sync and any concept of a user account. If the extension might grow a sync feature later, it's fine to start on storage.local and add Supabase when that need becomes real; retrofitting cloud storage onto local-first code mainly means writing a sync layer, not restructuring the WXT or React parts of the codebase.

Supabase's free tier caps out around 500 MB of database storage and 50,000 monthly active users, limits sized for typical web-app traffic rather than an extension's usage pattern. An extension with many users each storing a small amount of data, settings, bookmarks, short notes, tends to hit the storage ceiling well before the MAU one, since each user's footprint is tiny but the user count can climb fast once the extension shows up in a store's search results. The jump to Pro at $25/mo removes those caps and adds daily backups; see the Pricing section for the full breakdown. Watch database size specifically, not user count, as the leading indicator the free tier is running out.

Not out of the box. Supabase Auth's default OAuth flow redirects the browser to a callback URL, but an extension's popup closes the moment the user clicks away to a provider's login screen, which kills the redirect before it finishes. The fix is to route the flow through the extension APIs built for this: chrome.identity.launchWebAuthFlow (or Firefox's equivalent) opens the OAuth screen in its own window, and you register the extension's chrome-extension callback URL as a valid redirect URI in the Supabase project's Auth settings. Once that's wired up, you exchange the returned token by calling supabase.auth.setSession() directly instead of letting the client library manage the browser redirect itself. It's a one-time setup cost specific to running Supabase Auth inside an extension context, not a limitation of Supabase Auth on its own.

Yes. WXT compiles down to a standard Manifest V3 extension, plain manifest.json, background service worker, content scripts, popup HTML, so the output isn't locked into a proprietary format. If a feature genuinely needs manual manifest.json control WXT's config doesn't expose, you can inspect the built output in .output/ and hand-maintain a manifest from there, keeping the same React and TypeScript source files and swapping only the build step. Most projects never need this: WXT's config covers the manifest fields real extensions actually vary, permissions, content-script matches, icons, and ejecting means taking over cross-browser packaging and hot module replacement yourself. It's a real escape hatch, but a rarely-used one.