WXT vs CRXJS: Which Extension Framework Wins in 2026? | ExtensionBooster

Let's talk about something that matters if you're working with Chrome extensions right now.

The Key Points

• WXT vs CRXJS: Which Extension Framework Wins in 2026
• | ExtensionBooster If you started a new Chrome extension project last year, you probably Googled “vite chrome extension” and landed on CRXJS
• Fast, minimal, familiar Vite setup
• But then you noticed the GitHub commit history going quiet

---

The Details

WXT vs CRXJS: Which Extension Framework Wins in 2026. | ExtensionBooster If you started a new Chrome extension project last year, you probably Googled “vite chrome extension” and landed on CRXJS. Fast, minimal, familiar Vite setup. But then you noticed the GitHub commit history going quiet. You found a discussion thread asking whether the project is still alive. You wondered if you should switch to WXT instead. That tension, CRXJS’s elegance vs. WXT’s momentum, is exactly what this post unpacks. By the end, you’ll know which one to use for your specific situation, with no hand-waving. What CRXJS Actually Is First: CRXJS ( @crxjs/vite-plugin ) is not a framework . That distinction matters. You add it to a standard Vite project, one you configure yourself, and it adds two things: native HMR across popup, content scripts, and sidepanel, plus smart manifest handling that turns your manifest. ts into a fully typed entry point. ts import { defineConfig } from "vite" ; import { crx } from "@crxjs/vite-plugin" ; import manifest from ". config" ; export default defineConfig ({ plugins: [ crx ({ manifest })], }); That’s essentially all the CRXJS-specific code in your project. Everything else is plain Vite: React/Vue/Svelte via their standard plugins, TypeScript via ts-loader , bundling via Rollup. CRXJS intercepts the manifest, resolves entry points, and injects the HMR runtime. The latest release is around 2. 0 , with Vite 8 support landing mid-2026. The API surface is small and stable, which is both a selling point and the reason it doesn’t need constant updates. What WXT Actually Is WXT is a full framework. Its comparison page at wxt. dev/guide/resources/compare says it directly: file-based entrypoints, auto-imports, automatic manifest generation, a dev server with HMR, and first-party cross-browser builds to Chrome, Firefox, Edge, and Safari from a single codebase. wxt/ src/ entrypoints/ popup/index. ts components/ MyWidget. ts You define entry points by creating files in entrypoints/ . WXT reads the directory, generates the manifest, wires HMR, and produces browser-specific zips for distribution. ts you write yourself, WXT wraps Vite internally and exposes a wxt. The framework also ships: wxt/storage , type-safe wrapper over browser. storage wxt/messaging , type-safe message passing between contexts Auto-imported browser APIs (no manual import browser from "webextension-polyfill" ) Built-in wxt submit commands for store publishing WXT is the most actively developed option in the modern chrome extension framework space as of mid-2026, with frequent releases and a growing ecosystem. Head-to-Head: The Comparison Table CRXJS WXT Type Vite plugin Full framework Manifest handling manifest. ts via defineManifest() Auto-generated from file structure + wxt. ts Cross-browser Chrome + Edge only Chrome, Firefox, Edge, Safari Framework support React, Vue, Svelte, Solid, Vanilla React, Vue, Svelte, Solid, Vanilla Maintenance activity Slower cadence in 2025-2026; maintenance team added Very active; most-updated modern option Learning curve Low if you know Vite Moderate (Nuxt-like conventions to learn) Config you own Full vite. ts Abstracted via wxt. ts Best for Lightweight additions to existing Vite apps New projects, cross-browser, teams Is CRXJS Still Maintained in 2026. This is the question everyone asks. The honest answer: yes, but with reduced velocity . Development slowed noticeably through 2025 and into 2026. In response, the community organized, @colearendt joined as a CRXJS Maintenance Team Coordinator to keep the project going, and Vite 8 support was eventually added. The plugin isn’t abandoned. The core maintainability concern is structural: CRXJS has a small team maintaining a project that has to track every Vite major release and every Chrome extension platform change. One missing maintainer stalls things for months. You can follow the ongoing conversation in the CRXJS future/maintenance discussion on GitHub , it’s open and honest about the challenges. For a long-running production extension, that fragility is worth pricing in. For a small personal tool or a prototype, it matters much less. Cross-Browser Development: Where WXT Pulls Ahead If you need to ship to Firefox or Safari, CRXJS stops being a viable choice. It targets Chrome and Edge only. WXT handles the differences automatically: polyfilling browser vs chrome namespaces, building separate manifest files with browser-specific fields, and producing separate zips per target.

This is a condensed version of a deeper guide. The full article covers additional context and examples.

---

Worth Bookmarking

If you're working with Chrome extensions, you'll eventually need tools for:

• Generating icons at multiple sizes
• Creating store screenshots that look professional
• Converting MV2 extensions to MV3
• Analyzing bundle size

ExtensionBooster has free versions of all of these. I keep it bookmarked for every extension project.

---