The 2025 State of Browser Extension Frameworks: A Comparative Analysis of Plasmo, WXT, and CRXJS

Section 1: Executive Summary

1.1. Historical Scope and Current Corrections

This article retains its September 3, 2025 title, publication date, and URL. The 2026-09-25 UTC correction distinguishes architectural comparisons from historical opinions and current documentation. We have not reconstructed every framework’s 2025 release and issue history. Today’s documentation therefore cannot establish that a feature never existed in 2025, or validate the original maintenance rankings. No controlled three-framework performance benchmark was performed.

1.2. The Contenders at a Glance

The market is primarily defined by three key players, each with a distinct philosophy and set of trade-offs:

• WXT: Consider it when file-based entrypoints, configurable browser targets, storage helpers, and shared modules fit the project. Messaging still uses browser APIs or a separately selected library.
• Plasmo: Consider its conventions when the team wants a React-oriented workflow, Content Scripts UI, and the ecosystem’s storage and messaging packages. Its official documentation also lists optional Vue and Svelte support.
• CRXJS: Consider this Vite plugin when an explicit manifest and content-script HMR match the workflow. The team selects application-level storage and messaging libraries. A narrower build-tool scope can be intentional, not evidence of declining relevance.

1.3. Key Strategic Imperative

A central finding of this report is that the technical landscape for browser extensions has matured to a point where minor feature differences between leading frameworks are less critical than the health and activity of their respective open-source ecosystems. The ability of a framework to provide timely updates for new browser versions, patch security vulnerabilities, and keep pace with the evolution of the broader JavaScript toolchain is paramount. Consequently, the demonstrable health of a framework’s community and the activity of its maintainers have become the single most important factors in technology selection, directly impacting long-term project risk and total cost of ownership.

Section 2: The Modern Browser Extension Development Landscape

To fully appreciate the value proposition of modern extension frameworks, it is essential to understand the complex technical environment in which they operate. Three primary challenges define the current landscape: the architectural shift to Manifest V3, persistent cross-browser API fragmentation, and the inherently disconnected nature of an extension’s core components. These challenges have collectively raised the baseline complexity of development, making the adoption of a robust framework a near necessity for any project of significant scale.

2.1. The Unavoidable Shift: Manifest V3 (MV3)

The transition from Manifest V2 to Manifest V3, driven primarily by Google for the Chrome browser, represents the most significant paradigm shift in extension architecture in years. The core change is the replacement of persistent background pages with ephemeral service workers.Under MV2, a background script could run indefinitely, maintaining state in memory for the entire browser session. Under MV3, the service worker is event-driven and can be terminated by the browser at any time to conserve resources, with no guarantee of its persistence.

This architectural change fundamentally alters how extensions must be designed. It forces developers to adopt a stateless, event-driven model, where any critical information must be persisted to storage before the service worker is terminated. This introduces significant complexity in managing application state, handling asynchronous operations, and ensuring that event listeners are properly registered upon worker reactivation. The move to MV3 enhances browser security and performance but places a much greater architectural burden on the developer, making the abstractions provided by modern frameworks more valuable than ever.

2.2. The Cross-Browser Conundrum

While the WebExtensions API has created a degree of standardization, developing for multiple browsers remains a significant challenge due to subtle but critical implementation differences.These inconsistencies fall into several categories:

• API Namespace: Firefox and Safari primarily use the browser.* namespace for APIs, which returns Promises for asynchronous operations. Chromium-based browsers (Chrome, Edge, Opera) have historically used the callback-based chrome.* namespace, though they have been progressively adding Promise support.
• Feature Availability: Entire API modules or specific methods within an API may be available in one browser but not another. For example, Firefox supports container tabs through the contextualIdentities API, a feature not present in Chrome.
• Behavioral Differences: Even when an API is supported, its behavior can vary. A notable example is how content scripts interact with the host page’s JavaScript environment. Chrome uses a concept called “isolated worlds” to prevent conflicts, while Firefox employs a different security model known as “Xray vision”.

Frameworks can share configuration and normalize some API access, but cannot implement every missing browser capability. Treat resource generation, API behavior, debugging, packaging, and store submission as separate questions, rather than promising one build that behaves identically everywhere.

2.3. The Intricacies of the Extension Lifecycle

A browser extension is not a monolithic application but a collection of distinct, often isolated, components that must communicate to function correctly.These components typically include:

• Background Service Worker: The central event handler and state manager for the extension.
• Popup UI: A transient HTML page displayed when the user clicks the extension’s toolbar icon.
• Content Scripts: JavaScript and CSS files injected directly into web pages to read or modify their content.
• Options Page: A persistent HTML page for user configuration.

These components operate in different contexts and cannot directly call functions or share memory. All communication must occur through a message-passing system, typically using the runtime.sendMessage and runtime.onMessage APIs.Managing this asynchronous communication, especially for complex interactions involving multiple components, often leads to a significant amount of boilerplate code and can be a common source of bugs. Frameworks aim to simplify this process by providing higher-level messaging APIs or other state management solutions. The combined weight of MV3’s lifecycle management, cross-browser API fragmentation, and the inherent complexity of the message-passing architecture makes building a non-trivial extension from scratch an inefficient and error-prone endeavor. Frameworks are no longer a development luxury; they are a strategic necessity for building maintainable, scalable, and robust browser extensions.

Section 3: In-Depth Analysis: Plasmo Framework

The Plasmo Framework positions itself as a “battery-packed browser extension SDK made by hackers for hackers,” aiming to provide a development experience for extensions analogous to what Next.js provides for web applications.It is built on a highly opinionated, declarative philosophy designed to minimize configuration and accelerate development, particularly for teams within the React ecosystem.

3.1. Architectural Deep Dive: The “Next.js for Extensions”

Plasmo’s core architectural principle is the abstraction of the manifest.json file. Instead of requiring developers to manually configure entrypoints and permissions, the framework generates the manifest automatically based on the project’s file structure.Files placed in specific directories or named according to convention (e.g.,

popup.tsx, options.tsx, content.ts, background.ts) are automatically recognized and wired into the final extension bundle.This declarative, file-based routing system is intentionally similar to that of Next.js, providing a familiar pattern for web developers.

A differentiating architectural decision is Plasmo’s use of Parcel, while WXT and CRXJS use Vite. These choices affect configuration, plugins, caching, and debugging. The bundler name does not measure startup speed or establish technical debt. Evaluate the actual resolved dependency versions and the integration your project requires.

3.2. Developer Experience (DX): Opinionated and Streamlined

Plasmo is explicitly designed with the React and TypeScript developer in mind, offering first-class support for this stack out of the box.The development workflow is initiated with a simple scaffolding command,

pnpm create plasmo, which can be augmented with flags to include integrations like TailwindCSS or Supabase from the start.

The development server refreshes code during development. Distinguish a module update from a page or extension reload: only testing the chosen UI integration establishes which state survives. Plasmo’s framework documentation describes first-class React support and optional Vue/Svelte support. This distinction does not establish a measured productivity disadvantage for other frameworks.

3.3. Core Features and Abstractions

Plasmo’s “battery-packed” nature is evident in its rich set of built-in features and high-level abstractions designed to simplify common extension development tasks.

• API Wrappers: The framework includes its own high-level APIs for core extension functionalities. The Storage API provides a simplified interface for persisting data, and the Messaging API abstracts the complexity of the underlying chrome.runtime.sendMessage system, making communication between the background, popup, and content scripts more straightforward.
• Content Scripts UI (CSUI): This is one of Plasmo’s most compelling features. It provides a streamlined way to render complex UI components, such as those built with React, directly onto a webpage via a content script. Crucially, Plasmo can automatically wrap these UIs in a Shadow DOM, which isolates the extension’s CSS from the host page’s styles, preventing conflicts—a common and difficult problem to solve manually.
• Deployment and Publishing: The Plasmo ecosystem extends beyond the core framework to include tooling for the entire extension lifecycle. The open-source Browser Platform Publisher (BPP) is a GitHub Action that automates the process of deploying an extension to the Chrome, Firefox, and Edge web stores.Additionally, Plasmo offers a commercial Software-as-a-Service (SaaS) product called
  Itero TestBed, which provides a staging environment for testing extensions and pushing updates to beta testers without undergoing the official store review process.

3.4. Maintenance Evidence to Collect

Maintenance matters, but the original star counts, competitor commentary, and community anecdotes did not form a dated maintenance audit. They are not retained as an enterprise-risk score. A star count reflects interest, not the time needed to resolve a blocking dependency or browser issue.

For Plasmo, inspect its own release history, the package manifest for the selected tag, and issues relevant to your dependencies. Record the inspection date, installed version, blocking issue, workaround, and whether a fix is released or only on a development branch. Repeat the same procedure for the other candidates.

The existence of a paid service does not establish how maintainers allocate effort to an open-source package. Evaluate service terms separately if the team plans to use that service. A team using only the local framework should not inherit a risk score inferred from an unrelated commercial offering.

For a long-lived product, document who can diagnose build failures, pin a working dependency graph, contribute a patch, or maintain a temporary fork. Those obligations exist with every candidate. An unresolved issue can be a practical blocker without proving the whole project is abandoned; an active release feed does not guarantee that your blocker will be fixed.

Section 4: In-Depth Analysis: WXT Framework

WXT takes inspiration from Nuxt-style conventions, including discovered entrypoints and auto-imports. Its browser targets help share source code, but browser APIs, manifest versions, native packaging, and store submission remain separate compatibility questions.

4.1. Architectural Deep Dive: Nuxt-Inspired and Framework-Agnostic

The most significant architectural advantage of WXT is its frontend framework agnosticism. Unlike the React-centric approach of Plasmo, WXT is designed to work with any modern UI framework that has a Vite plugin. It provides pre-configured, official modules for the most popular choices—React, Vue, Svelte, and SolidJS—but does not preclude the use of others.This flexibility makes WXT an exceptionally versatile and future-proof choice, as it does not lock development teams into a specific UI technology.

WXT builds on Vite, making Vite plugins and configuration relevant to the project. In the current tested tutorial baseline, WXT 0.21.4 uses explicitly installed Vite 6.3.6. That build succeeded, but it was not compared against equivalent Plasmo or CRXJS projects. It supports no relative speed or bundle-size conclusion.

4.2. Developer Experience (DX): Conventions and Tooling

WXT has been meticulously engineered to minimize developer friction and reduce boilerplate code through a suite of powerful DX features.

• File-Based Entrypoints: Similar to Plasmo, WXT employs a file-based system where the manifest.json is generated automatically from the files present in the entrypoints/ directory.However, WXT enhances this pattern by allowing for inline configuration options directly within the entrypoint files, offering a greater degree of granular control over the manifest generation.
• Auto-Imports: A standout feature inspired by Nuxt, WXT provides automatic, on-demand importing of components, hooks, and utility functions.This eliminates the need for dozens of manual
  import statements, resulting in cleaner, more concise code and a significant boost to developer productivity.
• Dev Mode: Distinguish UI HMR from content-script and background reloads. Test a popup field, an injected component, and a background listener separately; a working update in one context says nothing about state preservation in another.
• CLI: Project scaffolding is handled by an interactive Command Line Interface (CLI), invoked via npx wxt@latest init. This tool guides the developer through selecting a project name, a UI framework template (including vanilla TypeScript), and other initial setup options, enabling a new project to be bootstrapped in seconds.

4.3. Core Features and Abstractions

WXT provides a comprehensive set of features that address the primary pain points of cross-browser extension development.

• Browser API Access: WXT provides a browser import for extension API access. It does not implement APIs absent from a browser or guarantee identical behavior. Use capability checks, target-specific configuration, and runtime tests where APIs differ.
• Comprehensive Build & Publishing: The framework offers robust, built-in tooling for the entire deployment pipeline. It includes commands to generate optimized ZIP packages tailored for different browser stores, including the creation of a separate source code ZIP file, which is a requirement for submission to the Mozilla Add-ons store.Furthermore, WXT provides utilities to automate the process of uploading and publishing the extension.
• Module System: For organizations that maintain a suite of related extensions, WXT offers a powerful module system. This feature enables the creation of reusable modules that can share both build-time configuration and runtime code across multiple extension projects, promoting code reuse and simplifying maintenance.

4.4. Maintenance and Upgrade Boundaries

WXT’s showcase can identify projects worth inspecting, but their user counts do not measure framework reliability or establish how much application-specific engineering those projects required. Review the WXT releases and the upgrade notes for the version you actually intend to install.

The current 0.21 upgrade notes require Node >=22, direct installation of Vite, and attention to changed source-ZIP rules. They also remove url: imports. These are concrete migration obligations, not evidence that the corresponding 2025 behavior was incorrectly documented.

UI choice can reduce coupling between extension logic and rendering, but it does not make upgrades free. Review framework modules, Vite plugins, injected-style behavior, and lifecycle cleanup together. CRXJS is also framework-agnostic, while Plasmo documents optional Vue/Svelte support; this flexibility is not exclusive to WXT.

Section 5: In-Depth Analysis: CRXJS Vite Plugin

CRXJS occupies a unique position in the extension development ecosystem. It is crucial to understand that CRXJS is not a comprehensive, all-in-one framework in the same vein as Plasmo or WXT. Instead, it is a highly-focused Vite plugin designed to solve the specific and complex challenges of bundling a browser extension using the modern Vite toolchain.Its philosophy is one of minimalism and control, providing essential build-time capabilities while intentionally avoiding application-level abstractions.

5.1. Architectural Deep Dive: A Tool, Not a Framework

The core purpose of @crxjs/vite-plugin is to bridge the gap between Vite’s development server and the unique requirements of the browser extension environment. It provides a zero-configuration setup that allows developers to leverage the full power of Vite and its extensive plugin ecosystem for extension development.

Unlike the file-based routing conventions of WXT and Plasmo, CRXJS adheres to a more traditional approach where the manifest.json file serves as the single source of truth for defining the extension’s entrypoints (background scripts, content scripts, popups, etc.).The plugin parses this manifest and configures Vite’s build process accordingly. This model appeals to developers who prefer the explicit configuration of the manifest over the convention-based “magic” of a full framework.

5.2. Developer Experience (DX): Lean and Unopinionated

CRXJS documents content-script HMR as a feature. Evaluate it on the actual injected UI: edit a component, retain page input, and check whether listeners or styles accumulate after repeated updates. Module acceptance boundaries still matter, so neither universal state preservation nor a speed advantage follows from the HMR label alone. The official introduction also lists support for multiple UI frameworks.

The setup process is lean and straightforward: a developer initializes a standard Vite project, installs the @crxjs/vite-plugin package, and adds it to the vite.config.js file, pointing it to the project’s manifest.json.This minimalist approach grants developers maximum control, as they are free to structure their application and choose their own libraries for tasks like storage and messaging without being bound by framework conventions.

5.3. Core Features

CRXJS focuses on a narrow but critical set of responsibilities:

• Vite Integration and HMR: Its main function is to correctly bundle all extension components using Vite and to manage the HMR connection for both extension pages (popups, options) and content scripts.
• Web Accessible Resources: It automates the process of declaring assets in the web_accessible_resources field of the manifest. This is a common source of manual error for developers, and the plugin’s ability to automatically manage these entries based on static asset imports in the code is a significant quality-of-life improvement.

It is important to note what CRXJS does not provide. There are no built-in wrappers or abstractions for the browser’s Storage, Messaging, or Internationalization (i18n) APIs. Developers using CRXJS are expected to interact directly with the native chrome.* or browser.* APIs or to select and integrate their own third-party libraries for these purposes.

5.4. Maintenance and Application Ownership

The original analysis used beta duration and community discussion to infer future maintenance risk. This correction does not reconstruct that historical timeline or treat it as a present-day reliability score. Consult the project’s release history for dated releases and their supported Vite versions.

For a candidate version, check whether the target manifest, asset imports, and UI plugin work together. Record unresolved blockers and whether the team can pin or patch the integration. Apply the same threshold used for WXT and Plasmo instead of inferring enterprise suitability from repository size.

CRXJS leaves storage, message schemas, and state management to the application. That can fit an existing codebase with established libraries; a new team may prefer more conventions. WXT supplies storage helpers but not a built-in messaging wrapper, so messaging ownership must be considered for both. Choosing libraries does not necessarily mean reimplementing them.

Section 6: Comparative Framework Analysis: A Head-to-Head Evaluation

A feature comparison describes ownership and workflow, not an overall winner. The following correction records current documented boundaries; it is not a reconstructed package-by-package snapshot of September 2025.

6.1. Detailed Feature Matrix

Sources for this matrix are WXT messaging, WXT upgrading, Plasmo’s framework guide, and CRXJS’s introduction. Undocumented or untested combinations are left as checks, not marked universally supported.

Feature Category	Feature	WXT	Plasmo	CRXJS
Maintenance	Release/dependency audit	Check selected tag	Check selected tag	Check selected tag
Developer Experience	First-class TypeScript	✅	✅	✅
	Entrypoint Discovery	✅ (File-based)	✅ (File-based)	❌³
	Inline Entrypoint Config	✅	✅	❌
	Auto-imports	✅	❌	❌
	Reusable Module System	✅	❌	❌
	UI integration	Official modules and Vite plugins	React; optional Vue/Svelte	Framework-agnostic Vite integration
Build Tools	Underlying Bundler	Vite	Parcel	Vite
	Create Extension ZIPs	✅	✅	❌
	Create Firefox Sources ZIP	✅	❌	❌
	Automated Publishing	✅	✅	❌
	Remote URL imports	Removed in WXT 0.21	Check selected version and policy	Not a core promise
Dev Mode Features	.env File Support	✅	✅	✅
	HMR for UIs	✅	🟡⁵	✅
	HMR for Content Scripts	🟡⁶	🟡⁶	✅
	Reload Background on Change	🟡⁶	🟡⁶	🟡⁶
API Wrappers	Storage API	✅	✅	❌⁷
	Messaging API	❌⁷	✅	❌⁷
	Content Script UI	✅	✅	❌⁷
	Internationalization (i18n)	✅	❌	❌
Browser/Manifest	Cross-browser execution	Test each target	Test each target	Test each target
	MV2 Support	✅	✅	🟡⁸
	MV3 Support	✅	✅	🟡⁸

Table Footnotes:
Maintenance grades and star counts have been removed because this article does not contain a reproducible, dated maintenance audit.

³ Entrypoints are configured exclusively in manifest.json.

⁴ First-class React and optional Vue/Svelte describe support routes, not measured speed.

⁵ Check HMR with the selected UI integration; do not infer identical update behavior.

⁶ Distinguish UI HMR, content-script reinjection, background reload, and page reload.

⁷ No built-in wrapper is provided; developers must use native browser APIs or third-party libraries.

⁸ Inspect the chosen plugin version and manifest target. A single output has one manifest version; that alone does not prove shared-source builds are impossible.

6.2. Analysis of Key Differentiators

The feature matrix highlights several critical areas where the frameworks diverge significantly, with important practical implications for development teams.

• Maintenance: Collect dated releases, dependency compatibility, and project-specific blockers. No candidate receives a guarantee of future support.
• Development workflow: Compare entrypoint discovery, generated configuration, and HMR in the contexts the team edits. Auto-imports are a convention, not a measured productivity score.
• Runtime ownership: WXT includes storage helpers; messaging uses native APIs or an optional library. Plasmo supplies ecosystem messaging APIs. CRXJS leaves both choices to the application.

For browser support, use a second matrix. WXT’s target documentation and publishing guide distinguish these stages:

Target	WXT 0.21.4 resource build in the companion example	Runtime and distribution
Chrome MV3	Built	Browser loading and store submission not tested
Firefox MV2	Built; sources ZIP generated	Temporary loading, consent metadata, ID, and AMO review remain separate
Safari MV2	Built	Apple packaging, signing, device tests, and submission not performed

WXT does not create the Safari native wrapper or automate Safari publication. Apple offers both a command-line packaging route and App Store Connect web packaging. Plasmo and CRXJS target combinations were not built in this correction; do not read their framework-level support descriptions as equivalent test results.

Section 7: Performance and Build Tooling Deep Dive: Vite vs. Parcel

The choice of an underlying bundler is a foundational architectural decision that profoundly impacts both the developer experience during development and the performance of the final extension. The divergence between Vite (used by WXT and CRXJS) and Parcel (used by Plasmo) is a key technical differentiator that reflects a broader trend in the modern web development ecosystem.

7.1. The Bundler’s Impact

A bundler’s responsibilities include resolving module imports, transforming code (e.g., TypeScript to JavaScript, JSX to JS), optimizing assets, and packaging everything into files that a browser can execute. The efficiency of this process directly affects how quickly a developer can see their changes (dev server speed and HMR) and the size and speed of the final product (production build performance).

7.2. Vite (WXT, CRXJS): Build Architecture

The original 2025 discussion described Vite’s ESM development server, dependency pre-bundling, and Rollup-based production builds. These explain the architecture of that generation, not a timeless description of every Vite release or a benchmark of extension frameworks:

• Development modules: On-demand transformation affects startup work, but extension entrypoint discovery, plugins, dependencies, and browser loading still take time.
• Dependency pre-bundling: Cold and warm dependency caches are different experimental conditions. A component benchmark for esbuild cannot be transferred to an entire WXT or CRXJS workflow.
• Production bundling: For the Vite 6 baseline used by the companion example, Rollup creates production output. Measure the resulting extension with the same source and optimization settings before comparing size.

The Vite guide is a reference for the version being adopted. Preserve the lockfile and identify the installed Vite major when reporting results; a later toolchain change should not silently become evidence about a 2025 release.

7.3. Parcel (Plasmo): What to Measure

Parcel handles transformations and assets through its build pipeline and caching. Its official documentation describes development behavior, but does not establish how a particular Plasmo application compares with an equivalent WXT or CRXJS application.

Use the same popup, content script, storage setting, UI framework, and browser target for all candidates. Pin Node, package manager, framework, and bundler versions. Record cold startup, warm startup, one UI edit, one content-script edit, and a production build separately. Keep dependency download time outside startup timing unless installation is the question. Repeat runs and report spread as well as a median; publish the commands and machine details. No such comparison was run here, so this article assigns no speed winner.

7.4. Bundle Size and Runtime Performance

In the resource-constrained environment of a browser extension, every kilobyte of the bundle and every millisecond of execution time matters.Large extensions can contribute to browser lag, increase memory consumption, and lead to a poor user experience.

UI dependencies contribute to output, but their effect depends on the application and compilation settings. Compare the same UI implementation before attributing a bundle difference to the extension tool. WXT and CRXJS permit multiple UI integrations, and Plasmo documents optional alternatives to React. A compiler-based UI still produces runtime code; it is not automatically smaller or faster for every workload.

Use the chosen version’s bundle-analysis tools to identify duplicated dependencies and code that reaches each entrypoint. Treat raw output size, archive size, popup startup, content-script work, and background wakeups as separate metrics. Code splitting and lazy loading change execution timing as well as packaging; measure the actual user interaction after applying them.

Section 8: Strategic Framework Selection: Recommendations for Project Archetypes

The optimal framework choice is not absolute but is contingent upon the specific context and constraints of a project. Factors such as team expertise, project scale, strategic priorities, and target platforms must be considered. This section provides a strategic decision matrix and detailed scenario analysis to guide technical leaders in selecting the most appropriate framework for their needs.

8.1. Framework Decision Matrix

The following table maps common project requirements to the suitability of each framework, translating the preceding technical analysis into actionable strategic guidance.

Project Requirement	WXT	Plasmo	CRXJS
Team Expertise
React-Heavy Team	Evaluate official React module	Evaluate React conventions and CSUI	Evaluate Vite React integration
Vue/Svelte/SolidJS Team	Check official modules	Check optional Vue/Svelte route; verify other choices	Check chosen Vite plugin
Polyglot / Agency Team	Shared WXT modules	Shared Plasmo conventions	Shared Vite configuration
Project Scale
Small Prototype / MVP	Test one complete workflow	Test one complete workflow	Test one complete workflow
Mid-Sized Product	Audit upgrade and testing needs	Audit upgrade and testing needs	Audit application-library ownership
Enterprise Suite	Assign maintenance ownership	Assign maintenance ownership	Assign maintenance ownership
Strategic Priority
Time-to-Market	Measure team workflow	Measure team workflow	Measure team workflow
Long-Term Maintainability	Dated release/dependency audit	Dated release/dependency audit	Dated release/dependency audit
Explicit Configuration	Generated manifest conventions	Generated manifest conventions	Manifest-driven setup
Target Platforms
Chrome-Only	Test target manifest and APIs	Test target manifest and APIs	Test target manifest and APIs
Multiple Browsers	Build and test separately	Check each supported target	Check plugin version and target

8.2. Detailed Scenario Analysis

The decision matrix can be further illuminated by examining several common project archetypes.

• Scenario A: The Enterprise React Team
  • Context: A large organization with deep in-house React expertise is tasked with building a complex, mission-critical browser extension that will be supported for many years. Stability, security, and long-term maintainability are the highest priorities.
  • Analysis: Compare Plasmo’s React conventions with WXT’s React module and CRXJS’s Vite integration using the existing component library. Include permissions, background restart, storage migration, and the team’s ability to diagnose generated output.
  • Decision boundary: Select after a dated dependency audit and a representative workflow test. None of these tools removes maintenance risk, and enterprise scale alone does not disqualify a plugin-based approach.
• Scenario B: The Lean Startup / Indie Developer
  • Context: A small, agile team or a solo developer is building a Minimum Viable Product (MVP). The primary goal is to validate an idea and ship a functional product as quickly as possible.
  • Analysis: Compare the time to complete one actual workflow, not just create a template. WXT’s storage helper can be useful, while messaging still needs native APIs or an optional library. Plasmo provides ecosystem wrappers; CRXJS lets the team retain existing libraries.
  • Decision boundary: Prefer the conventions the team can explain and test through a release rehearsal. There is no measured fastest path in this article.
• Scenario C: The Multi-Framework Agency
  • Context: A digital agency or consultancy that builds browser extensions for a variety of clients. These clients may have existing technology stacks and preferences for different UI frameworks, such as React, Vue, or Svelte.
  • Analysis: This scenario perfectly highlights the strategic advantage of WXT’s architecture. Its framework-agnostic nature is a killer feature for this use case.An agency can standardize its core extension development and build process on WXT, creating a consistent, efficient workflow across all projects. This allows them to accumulate institutional knowledge and reusable code (potentially using WXT’s module system) while retaining the flexibility to use the specific UI framework required by each client.
  • Decision boundary: WXT is one candidate for shared modules and multiple UI integrations. CRXJS is also framework-agnostic; Plasmo lists optional Vue/Svelte support. Test the actual plugin combinations, injected styles, and update behavior before standardizing.
• Scenario D: The Performance Purist / Tooling Expert
  • Context: A developer building a highly-performant, lightweight extension where every kilobyte of bundle size and every millisecond of latency is critical. This developer is a tooling expert who prefers to have full, granular control over every dependency and build step, and is wary of framework “magic.”
  • Analysis: A manifest-driven Vite plugin can fit explicit dependency ownership. That does not prove smaller output: a hand-selected library can outweigh a framework helper, and repeated listener registration can dominate runtime cost.
  • Decision boundary: Include CRXJS when explicit configuration is valuable, then measure the same workload. Minimal abstraction is a design preference, not a speed result.

Section 9: Conclusion and Future Outlook

9.1. Final Verdict

The original universal recommendation is withdrawn because the article did not establish comparable benchmarks or a dated maintenance audit. WXT, Plasmo, and CRXJS organize different parts of the work. Entrypoint conventions, application-library ownership, UI integration, and release targets provide concrete selection criteria.

For a complete WXT example, use the version-pinned tutorial. Its typecheck and browser-target resource builds are reproducible checks of one example, not a comparative runtime benchmark. A product decision still requires browser execution and a release rehearsal.

9.2. The Future of the Ecosystem

Future changes should be evaluated through release notes, API requirements, and migration experiments rather than a prediction that one tool will absorb the others. For example, WXT’s removal of url: imports is a current upgrade consideration; it is not a reason to retroactively mark every 2025 remote-import statement false.

Keep the selected version, dependency lockfile, browser matrix, known blockers, and upgrade owner with the decision. The references below retain the original 2025 reading list for historical context; current corrections link to the relevant official documents beside each claim. Historical forum opinions are not evidence of today’s maintenance status.

Works cited

1. WXT: Next-gen Web Extension Framework, accessed September 3, 2025, https://wxt.dev/
2. WXT: Next-Gen Web Extension Framework - Hacker News, accessed September 3, 2025, https://news.ycombinator.com/item?id=42347638
3. Plasmo Framework – Plasmo, accessed September 3, 2025, https://docs.plasmo.com/framework
4. PlasmoHQ/plasmo: The Browser Extension Framework - GitHub, accessed September 3, 2025, https://github.com/PlasmoHQ/plasmo
5. I wrote WXT, a relatively new framework for building web extensions. AMA! - Reddit, accessed September 3, 2025, https://www.reddit.com/r/chrome_extensions/comments/1fs9om2/i_wrote_wxt_a_relatively_new_framework_for/
6. Comparing frameworks for extension development: WXT vs Plasmo vs CRXJS - Reddit, accessed September 3, 2025, https://www.reddit.com/r/chrome_extensions/comments/1k1c8gv/comparing_frameworks_for_extension_development/
7. crxjs/vite-plugin - NPM, accessed September 3, 2025, https://www.npmjs.com/package/@crxjs/vite-plugin
8. Compare - WXT, accessed September 3, 2025, https://wxt.dev/guide/resources/compare
9. Build a cross-browser extension - MDN - Mozilla, accessed September 3, 2025, https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Build_a_cross_browser_extension
10. Creating a Browser Extension using SolidJS + WXT II | by Michael Essiet - Medium, accessed September 3, 2025, https://devshogun.medium.com/creating-a-browser-extension-using-solidjs-wxt-ii-2ff10fcafc98
11. Building AI-Powered Browser Extensions With WXT - Marmelab, accessed September 3, 2025, https://marmelab.com/blog/2025/04/15/browser-extension-form-ai-wxt.html
12. Best Browser Extension Framework: Choose the Right One - iotric, accessed September 3, 2025, https://www.iotric.com/blog/best-browser-extension-framework/
13. Chrome Extension with React, Vite (No CrxJS Plugin) | Medium - Ajay n Jain, accessed September 3, 2025, https://ajaynjain.medium.com/how-i-built-a-chrome-extension-with-react-and-vite-without-crxjs-plugin-b607194c4f5e
14. More on @crxjs/vite-plugin - Honwhy Blog, accessed September 3, 2025, https://honwhy.wang/blog/java/more-on-crxyjs-vite-plugin/
15. Beyond the Popup: Crafting Next-Level Chrome Extensions with CRXJS - zerodays, accessed September 3, 2025, https://www.zerodays.dev/sl/blog/beyond-the-popup-crafting-next-level-chrome-extensions-with-crxjs
16. The 3 Chrome extension framework you’ll ever need - Ful.io, accessed September 3, 2025, https://ful.io/blog/the-3-chrome-extension-framework-youll-ever-need
17. Plasmo - the browser extension framework : r/chrome_extensions - Reddit, accessed September 3, 2025, https://www.reddit.com/r/chrome_extensions/comments/14346cu/plasmo_the_browser_extension_framework/
18. Plasmo: Supercharge your browser extension development, accessed September 3, 2025, https://www.plasmo.com/
19. Introduction to Plasmo – Plasmo, accessed September 3, 2025, https://docs.plasmo.com/
20. Plasmo - GitHub, accessed September 3, 2025, https://github.com/plasmohq
21. Welcome to WXT – WXT, accessed September 3, 2025, https://wxt.dev/guide/introduction
22. wxt-dev/wxt: Next-gen Web Extension Framework - GitHub, accessed September 3, 2025, https://github.com/wxt-dev/wxt
23. Frontend Frameworks - WXT, accessed September 3, 2025, https://wxt.dev/guide/essentials/frontend-frameworks
24. Developing web extensions with the WXT library - LogRocket Blog, accessed September 3, 2025, https://blog.logrocket.com/developing-web-extensions-wxt-library/
25. Frameworks for developing browser extensions - Chuniversiteit.nl, accessed September 3, 2025, https://chuniversiteit.nl/programming/developing-chrome-extensions
26. Create a project | CRXJS Vite Plugin, accessed September 3, 2025, https://crxjs.dev/vite-plugin/getting-started/vanilla-js/create-project
27. Releases · crxjs/chrome-extension-tools - GitHub, accessed September 3, 2025, https://github.com/crxjs/chrome-extension-tools/releases
28. crxjs - GitHub, accessed September 3, 2025, https://github.com/crxjs
29. crxjs chrome-extension-tools · Discussions - GitHub, accessed September 3, 2025, https://github.com/crxjs/chrome-extension-tools/discussions
30. Parcel vs Vite: Choosing the Right Frontend Build Tool | Better Stack Community, accessed September 3, 2025, https://betterstack.com/community/guides/scaling-nodejs/parcel-vs-vite/
31. Vite vs. Webpack: A Head-to-Head Comparison - Kinsta®, accessed September 3, 2025, https://kinsta.com/blog/vite-vs-webpack/
32. Why Vite, accessed September 3, 2025, https://vite.dev/guide/why
33. Why I switched from Parcel to Vite ? - Anoop Jadhav | Blogs, accessed September 3, 2025, https://blog.anoopjadhav.in/why-i-switched-from-parcel-to-vite
34. Why Your Browser Extension is Slower Than It Should Be (And How Svelte Fixes It), accessed September 3, 2025, https://hexshift.medium.com/why-your-browser-extension-is-slower-than-it-should-be-and-how-svelte-fixes-it-15a71063d7f0
35. Impact of Extensions on Browser Performance: An Empirical Study on Google Chrome, accessed September 3, 2025, https://arxiv.org/html/2404.06827v1
36. Create a Production Build - Plasmo Docs, accessed September 3, 2025, https://docs.plasmo.com/framework/workflows/build
37. Mastering Bundle Size: Inspect and Minify Your Web App’s Main Chunk | by Bachri, accessed September 3, 2025, https://javascript.plainenglish.io/inspect-and-reduce-your-web-apps-main-bundle-bd3fce587aa7
38. 8 Ways to Optimize Your JavaScript Bundle Size - Codecov, accessed September 3, 2025, https://about.codecov.io/blog/8-ways-to-optimize-your-javascript-bundle-size/