Browser extensions: Plasmo Has 12k Stars. I'm Still Recommending WXT
The browser extension framework conversation usually starts with “Plasmo has 12,600 stars” It’s the most-starred option. It pioneered the “Next.js for extensions” paradigm. Every tutorial from 2023-2024 points to it.
Here’s why I’m recommending WXT instead.
As of today (14 January 2026), Plasmo hasn’t had a release in 8 months. 339 open issues. Still labeled “alpha” after years of development. The Parcel bundler it relies on is multiple major versions behind. TailwindCSS v4 doesn’t work with it.
GitHub stars measure past enthusiasm. Maintenance trajectory predicts future reliability. For a framework sitting between your code and three different browser stores, I’ll take active development over popularity every time.
What These Frameworks Actually Solve
Building browser extensions without a framework involves real friction. I have experienced this personally developing Layerpath Chrome extension.
You manually write manifest.json files. You synchronize them across Manifest V2 and V3 versions. You implement custom hot-reload. You handle service workers, content scripts, and popup UIs communicating across different contexts.
Every change requires understanding how Chrome’s extension sandbox actually works.
The core problems:
| Pain Point | Without Framework | With Framework |
|---|---|---|
| Manifest configuration | Manual JSON for each browser | Auto-generated from project structure |
| Hot reload | Custom implementation or full reload | Built-in HMR |
| Cross-browser builds | Separate build configs | Single codebase, multiple outputs |
| MV2/MV3 compatibility | Maintain two codebases | Automatic abstraction |
| Content script injection | Manual DOM manipulation | Shadow DOM components |
Three frameworks dominate this space: WXT, Plasmo, and CRXJS. Each approaches these problems differently.
The Framework Breakdown
WXT (8,500+ stars, 196 contributors) positions itself as the “Nuxt for browser extensions”. Vite-powered builds. Automatic manifest generation from file-based entrypoints. Equal support for React, Vue, Svelte, and Solid.
The maintenance story is strong. Version 0.20.11 shipped in September 2025. Updates continued through late December 2025. Production extensions built on WXT include Eye Dropper (1M+ users) and ChatGPT Writer (600k+ users).
Plasmo (12,600 stars) pioneered React-first extension development. Content Scripts UI (CSUI) elegantly injects React components into pages using Shadow DOM. The @plasmohq/storage and @plasmohq/messaging APIs abstract cross-context communication beautifully.
But the last release was May 2025. The project’s GitHub activity tells a concerning story. The framework’s commercial focus on Itero TestBed ($30/month) may be pulling resources from open-source development.
CRXJS (3,800 stars) takes a minimalist approach as a Vite plugin. It’s not a full framework. After a period where stable Manifest V3 support required beta versions, development resumed with v2.3.0 in December 2025. The community even created a fork to handle Chrome v130+ CSP changes.
| Framework | Stars | Last Release | Bundler | Open Issues | Production Examples |
|---|---|---|---|---|---|
| Plasmo | 12.6k | May 2025 | Parcel | 339 | - |
| WXT | 8.5k | Sep 2025 | Vite | 172 | Eye Dropper (1M+ users) |
| CRXJS | 3.8k | Dec 2025 | Vite | - | - |
| Extension.js | 4.5k | Aug 2025 | - | 33 | - |
The Maintenance Problem Isn’t Theoretical
WXT’s documentation states plainly: Plasmo “appears to be in maintenance mode with little to no maintainers nor feature development happening”.
Reddit discussions increasingly warn newcomers away. The evidence is concrete:
- 339 open issues vs WXT’s 172
- 8-month release gap vs WXT’s continuous updates
- Long-standing bugs unresolved since July 2023
- Outdated Parcel bundler breaking modern toolchain compatibility
This matters for production. When Chrome pushes a Manifest V3 change, you want a framework that responds. When a security update breaks something, you need maintainers who ship fixes. 339 open issues and 8 months of silence isn’t responsive.
Developers who migrated from Plasmo to WXT report 40-90% reductions in bundle size. One documented case: 700KB to 400KB. Hot module replacement works reliably across all UI frameworks, not just React.
Developer Experience Head-to-Head
Hot Module Replacement quality varies significantly.
WXT provides fast HMR for all UI frameworks. Content scripts and background scripts trigger quick extension reloads. Plasmo’s HMR is optimized specifically for React. Vue and Svelte changes trigger full extension reloads instead of targeted updates. CRXJS offers true HMR but requires more configuration.
TypeScript integration is first-class everywhere. WXT’s Nuxt-style auto-imports reduce boilerplate significantly. You spend less time writing import statements.
Cross-browser builds favor WXT’s unified approach. From a single codebase, it generates properly configured builds for Chrome, Firefox, Edge, Safari, and all Chromium browsers. Brave, Opera, Arc, Vivaldi. One command, multiple outputs.
WXT automatically produces Firefox-specific source ZIPs required for Mozilla’s AMO review. Plasmo doesn’t do this. If you’re targeting Firefox, that’s hours of manual work saved.
The critical runtime difference: Plasmo bundles robust Storage and Messaging APIs for cross-context communication. WXT provides a Storage wrapper with type-safety and migration support. But it lacks a built-in Messaging wrapper. For complex extensions with heavy background-content script communication, you’ll use browser globals or third-party packages with WXT.
Chrome Dominates. Cross-Browser Still Matters.
Chrome holds 66-68% global market share. Chrome Web Store is your essential target.
| Browser | Desktop Share | Mobile Share | Extension Store |
|---|---|---|---|
| Chrome | 64-65% | 65-67% | Chrome Web Store (~137k extensions) |
| Safari | 8-9% | 23-24% | Safari Extensions (Apple Developer Program required) |
| Edge | 12-14% | 0.5% | Edge Add-ons (Chrome extension compatible) |
| Firefox | 6-7% | 0.9% | Firefox Add-ons (~30k extensions) |
Regional variations matter. Safari exceeds 25% in North America due to iPhone penetration. Firefox maintains 5%+ in Europe. Russia sees significant Yandex Browser usage (6-16%).
The priority is clear:
- Chrome Web Store first. This reaches 66%+ of users. Edge users can install Chrome extensions directly.
- Firefox Add-ons second. Privacy-conscious users, Linux enthusiasts.
- Safari only if the business case justifies Apple Developer Program fees and macOS-only tooling.
WXT’s seamless cross-browser builds make reaching Firefox trivial. Same codebase. Automatic manifest handling. Generated source ZIPs for Mozilla’s review process.
The Cross-Browser API Reality
Manifest V3 improved compatibility. All major browsers now support promises for async extension APIs (Chrome since version 121). The fundamental architecture remains consistent: background service workers, content scripts, popup UIs, storage/messaging APIs.
Meaningful gaps persist.
The sidebar API fragments badly. Firefox and Opera use sidebarAction. Chrome introduced an entirely different sidePanel API. Safari supports neither. The webRequest API has Firefox-specific behaviors around proxy handling and request timing. Safari diverges more significantly in several areas.
Mozilla’s webextension-polyfill (66,100+ dependent repositories) remains essential. It provides promise-based browser.* APIs that work across Chrome, Firefox, Edge, and Opera. It’s a NO-OP on Firefox (which natively supports the namespace). It wraps Chrome’s callback-based chrome.* APIs.
All three major frameworks handle cross-browser builds. WXT’s approach is most streamlined. Separate browser-targeted builds from the same source. Automatic manifest version handling. Firefox sources ZIP generation.
Extension.js: The Zero-Config Alternative
Extension.js (4,500 stars, August 2025 release) deserves consideration.
Zero-configuration development. A unique capability: running extensions directly from GitHub URLs during development. It supports Chrome, Edge, and Firefox. Safari is planned.
Extension.js may suit teams who find WXT overly complex. Or developers wanting framework support without heavy abstraction. Its 33 open issues versus 172 for WXT and 339 for Plasmo suggests a smaller but more tractable scope.
When to Choose What
For new projects starting in 2026, WXT is the recommendation. Active maintenance. Vite-powered performance. Framework flexibility. Comprehensive cross-browser support. Main caveat: no built-in messaging API.
For existing Plasmo projects, continue short-term. But plan migration paths. Avoid deepening dependencies on Plasmo-specific abstractions. Monitor GitHub activity for signs of revival.
For minimal framework overhead, CRXJS (Vite users) or Extension.js (zero-config preference) provide build tooling without heavy opinions.
For enterprise or long-term projects, WXT’s active maintenance (196 contributors, ~10 new stars daily) and production track record (1M+ user extensions) offer the strongest sustainability signal.
| Use Case | Recommended | Risk Level |
|---|---|---|
| New project, any UI framework | WXT | Low |
| React-specific, rapid prototyping | Plasmo (with migration plan) | Medium |
| Minimal abstractions, Vite-based | CRXJS | Low-Medium |
| Simple extensions, zero-config | Extension.js | Low |
| Existing Plasmo project | Continue + plan migration | Medium-High |
| Multi-browser support critical | WXT | Low |
The Bottom Line
The browser extension framework landscape has consolidated. Clear winners. Concerning trajectories.
WXT represents the safest bet for new development. Active maintenance. Modern Vite tooling. Comprehensive cross-browser support. No framework lock-in.
Plasmo pioneered this space. Its features remain impressive. But the maintenance status poses material risk for new projects. The best features become liabilities when bugs go unfixed and dependencies fall behind.
For teams evaluating frameworks today: prioritize maintenance trajectory over raw feature counts.
Chrome’s dominance makes Chrome Web Store essential. But WXT’s seamless cross-browser builds enable meaningful reach expansion with minimal additional effort.
Stars measure what people liked 18 months ago. Active commits measure what you can rely on tomorrow.
Building a browser extension? I’d love to hear what framework you’re using. Reach out on LinkedIn.