Extension frameworks in 2026: how to pick the right one for your next project

Picking a browser extension framework shouldn't feel like a gamble. But with Plasmo stalling, CRXJS going through a leadership change, and two newer contenders entering the mix, the decision in 2026 is more nuanced than "just use the most popular one." I've spent the last few weeks benchmarking all five production-grade options so you don't have to.

Here's what actually matters — and which framework fits your situation.

The framework landscape has shifted

If you started building extensions a couple years ago, Plasmo was the default recommendation. It had the biggest community, the most tutorials, and a React-first developer experience that felt familiar.

That's no longer the case. As of early 2026, Plasmo's feature development has slowed dramatically. The framework is stuck on an older version of Parcel, which blocks compatibility with tools like Tailwind CSS v4. GitHub stars (12,800) tell you about past popularity. Commit activity tells you about current health — and Plasmo's isn't great.

Meanwhile, WXT has quietly become the framework most developers reach for. It has around 9,100 GitHub stars, 200+ contributors, and regular releases throughout 2025 and into 2026. The architecture is inspired by Nuxt — file-based entrypoints, auto-imports, and a framework-agnostic core that works with React, Vue, Svelte, and Solid equally well.

Five frameworks, head to head

Let me break down the current field. These numbers come from the DevKit.best framework comparison and my own testing.

WXT — the production default

• Build time: ~1.2s
• Bundle size: ~387 KB
• HMR speed: ~200ms
• Browser support: Chrome, Firefox, Edge, Safari, and all Chromium browsers
• UI framework: Any (React, Vue, Svelte, Solid, vanilla)

WXT's file-based entrypoint system is genuinely pleasant to work with. You create popup/index.html and WXT registers it in your manifest automatically. Same for content scripts, background scripts, options pages — drop a file in the right directory and it just works. No manifest editing.

Here's what a basic WXT project structure looks like:

my-extension/
  entrypoints/
    popup/
      index.html
      main.tsx
    background.ts
    content.ts
  public/
    icon-128.png
  wxt.config.ts

That's it. WXT infers your manifest from the file structure. Your wxt.config.ts handles the rest:

import { defineConfig } from 'wxt';
 
export default defineConfig({
  modules: ['@wxt-dev/module-react'],
  manifest: {
    permissions: ['storage', 'activeTab'],
    name: 'My Extension',
  },
});

The module system is where WXT really shines. Need React? Add @wxt-dev/module-react. Need auto-imports? Built in. Need to target multiple browsers from one codebase? Just pass --browser firefox to the build command.

Plasmo — still good for React, but watch the maintenance

• Build time: ~3.8s
• Bundle size: ~812 KB
• HMR speed: ~800ms (reportedly unreliable ~40% of the time)
• Browser support: Chrome, Firefox, Edge, Safari
• UI framework: React-first (others via workarounds)

Plasmo's killer feature remains CSUI (Content Script UI) — it lets you inject React components directly into web pages with shadow DOM isolation. If your extension is primarily a content script that overlays complex UI on third-party pages, this is still the easiest path.

But the trade-offs are real. The bundle size is roughly double WXT's. HMR is inconsistent. And the dependency on an aging Parcel version means you're stuck with older tooling.

I'd still consider Plasmo if you're building a React-heavy content script extension and your team already knows the framework. For anything else, look elsewhere.

CRXJS — minimal abstraction, uncertain future

• Build time: Comparable to WXT
• Bundle size: Smallest (it's a Vite plugin, not a full framework)
• HMR speed: ~180ms for content scripts (fastest in class)
• Browser support: Chrome-focused
• UI framework: Whatever Vite supports

CRXJS isn't a framework — it's a Vite plugin that adds extension-specific build features to your existing Vite project. If you already have a Vite + React/Vue setup and want to turn it into an extension, CRXJS is the path of least resistance.

The 2.3.0 release in December 2025 showed signs of revival after years in beta, but the long-term commitment from maintainers is still uncertain. Use it if you want minimal abstraction and you're comfortable maintaining your own build pipeline if the project goes quiet.

Extension.js — the prototyping speed demon

• Setup time: Under 60 seconds from zero to working extension
• Browser support: Chrome, Firefox, Edge (simultaneous preview)
• UI framework: Any, plus WebAssembly support

Extension.js is the "create-react-app" of browser extensions. One command, zero config, working extension. It's the fastest way to validate an idea or learn extension development.

npx extension create my-extension
cd my-extension
npx extension dev

That opens a browser with your extension loaded. Done.

The trade-off is that Extension.js optimizes for onboarding, not for production complexity. As your extension grows, you'll likely want to migrate to WXT for its module system, better build optimization, and more mature ecosystem. Think of Extension.js as your prototyping tool and WXT as your production tool.

Bedframe — the team-scale option

• Browser support: Chrome, Firefox, Edge, Safari, Opera, Brave, Arc (widest coverage)
• UI framework: React, Vue, Solid, Svelte, plus vanilla JS/TS
• Built-in: Vitest + Playwright testing, CI/CD pipelines, git hooks

Bedframe is the newest framework, and its pitch is different: it focuses on the full development lifecycle, not just the build step. When you scaffold a Bedframe project, you get pre-configured testing, CI/CD, and a publish workflow out of the box.

This is compelling for teams. If you're building an extension at a company and need PR-based workflows, automated testing, and multi-browser deploys from day one, Bedframe saves you hours of DevOps setup. The trade-off is a smaller community and fewer tutorials compared to WXT or Plasmo.

How to choose: a practical decision tree

Stop overthinking it. Here's the shortest path to the right choice:

"I'm starting a new production extension." Use WXT. It has the best balance of DX, performance, and maintenance health. You can use any UI framework, and the Nuxt-inspired file structure makes onboarding new contributors easy.

"My team already uses Plasmo and it works fine." Don't migrate just because. But watch the maintenance situation. If Plasmo blocks a critical dependency upgrade, have a migration plan ready.

"I need to inject complex React UI into web pages." Give Plasmo a serious look for its CSUI feature. Alternatively, build the content script injection yourself in WXT — it's more work upfront but avoids the maintenance risk.

"I want to prototype fast and learn." Extension.js. Zero config, instant feedback. Graduate to WXT when the project gets serious.

"We need CI/CD and testing from day one." Bedframe, if you're comfortable with a younger ecosystem. Otherwise, WXT + manual Vitest/Playwright setup gives you more control.

"I already have a Vite project." CRXJS plugin. Minimal changes to your existing setup. Just have a backup plan if the project goes quiet again.

Common pitfalls when adopting a framework

A few things I've seen developers get wrong:

Chasing GitHub stars. Plasmo has 12,800 stars. WXT has 9,100. But stars are a lagging indicator of past popularity, not current health. Look at commit frequency, issue response times, and release cadence instead. As WXT's own comparison notes, GitHub stars don't indicate current maintenance status.

Ignoring bundle size. Your extension lives in the browser. Every kilobyte matters for install time and memory usage. WXT's ~387 KB output is roughly half of Plasmo's ~812 KB for equivalent functionality. Over millions of users, that adds up. You can check how real extensions compare on size and permissions in the Extenshi catalog.

Not planning for Manifest V3. As of mid-2025, Manifest V2 is completely unsupported. If you're using a framework or starter template that still defaults to MV2, stop. All five frameworks in this article support MV3 natively.

Over-committing to a framework's ecosystem. Frameworks come and go — 60% of extensions last fewer than 12 months in the Web Store. Write your core logic as plain TypeScript modules, then wire them into whatever framework you're using. If you need to migrate later, the business logic moves with you. The Extenshi extension security reports can help you understand how your permissions profile compares to competitors regardless of which framework you use.

What I'd pick today

If I were starting a new extension tomorrow, I'd use WXT. The file-based entrypoints make the initial setup fast, the build output is lean, and the maintenance trajectory gives me confidence it'll still be actively supported a year from now.

For any production extension, framework-agnostic tooling and small bundle sizes should be non-negotiable — and WXT aligns with those requirements.

The tooling I run regardless of framework

Whatever framework you land on, a few jobs sit outside it — and I lean on free tools for all of them:

• Manifest sanity. All five frameworks emit a manifest, but none of them check it against current store policy. My Manifest V3 generator validates the permissions and host_permissions you'll actually ship and previews the install prompt your users see — free, no sign-up.
• Pre-publish scanning. Wire @extenshi/cli (npx @extenshi/cli) into your build so a risky bundle never reaches the store; it drops straight into GitHub Actions as a build-blocking gate. You get 5 scans and 25 reads a month free, with prepaid packs when your CI runs more.
• Competitor research. The Extenshi MCP server pulls catalog search, permission breakdowns, and market stats into Claude or Cursor, so you can size up the category before you commit a line of code.

Framework-agnostic core logic plus framework-agnostic tooling is what keeps a future migration from turning into a rewrite.

Further reading

• WXT documentation and getting started guide
• DevKit.best Chrome extension framework comparison
• The 2025 state of browser extension frameworks — Redreamality's analysis of Plasmo, WXT, and CRXJS
• Extension.js docs
• Bedframe docs
• Browse the Extenshi extension catalog to see how real extensions score on security and privacy

Explore extension analytics →

This article is based on publicly available developer documentation, framework benchmarks, and community analysis. Extenshi does not independently verify all claims made by third-party sources. References to specific frameworks reflect publicly available data and do not constitute endorsements. If you believe any information is inaccurate, please contact us at [email protected].