DEV Community

ExtensionBooster
ExtensionBooster

Posted on

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

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

There's a gap between "it works" and "it's production-ready" in extension development. Here's how to close it.

Key differences

  • 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
  • But then you noticed the GitHub commit history going quiet
  • You found a discussion thread asking whether the project is still alive

Here's the thing

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. 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 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. 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 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.

💡 Quick tip: Chrome.storage.sync has stricter quotas than chrome.storage.local.


If you build Chrome extensions

You'll eventually need tools for icons, screenshots, MV2→MV3 conversion, and bundle analysis.

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

Top comments (0)