DAILY NEWS

Stay Ahead, Stay Informed – Every Day

Advertisement
TECH & AI
Plasmo vs CRXJS vs WXT: Which Chrome Extension Framework Should You Use in 2026?
jackminion 0



If you are starting a browser extension in 2026, you no longer hand-roll a manifest.json, wire up a Webpack config, and pray that hot reload works on content scripts. Three projects now own this space: Plasmo, CRXJS, and WXT.

They look similar from the README, but they make very different bets. One is a full opinionated framework. One is just a build plugin. One tries to be the “Nuxt of extensions.” Pick wrong and you will feel it six months in, usually when you try to ship to Firefox or upgrade a dependency.

This post breaks down all three by the things that actually matter day to day, then gives you a straight decision guide. No “it depends” cop-outs.

TL;DR comparison table

Dimension
WXT
Plasmo
CRXJS

What it is
Full framework
Full framework
Vite plugin

Bundler
Vite
Parcel (custom)
Vite

Frontend frameworks
React, Vue, Svelte, Solid, vanilla
React-first
Any (you wire it)

Cross-browser
Chrome, Firefox, Safari, Edge
Chrome, Firefox, Edge
Chrome / Edge (Chromium)

MV2 + MV3
Both, simultaneously
Both, per build
Pick one

File-based entrypoints
Yes
Yes
No (manual manifest)

Auto-imports
Yes
No
No

Built-in storage / messaging
Yes (+ i18n)
Yes
No

Content-script HMR
Good (UI)
React only
Best (state-preserving)

Publishing / zip
Zip + Firefox source + publish
Zip + publish + Itero TestBed
None

GitHub stars (mid-2026)
~9.5k
~12k
~3.5k

Maintenance
Active
Maintenance mode
Revived (v2.0, Jun 2025)

Best for
Most new projects
React teams, more tutorials
Experts who want control

Sources for these claims are linked at the bottom. Star counts and bundle numbers move, so treat them as a snapshot, not gospel.

The 30-second answer

Starting fresh and want the safe default? Use WXT.

All-in on React and want the biggest pile of existing tutorials? Plasmo still delivers, with caveats.

You are a power user who wants minimal magic and full control of your Vite config? CRXJS.

Now the why.

WXT: the modern default

WXT brings Nuxt-style conventions to extensions. You drop files into an entrypoints/ directory and WXT generates the manifest, registers content scripts, and handles routing for you.

// entrypoints/content.ts
export default defineContentScript({
matches: (‘*://*.github.com/*’),
main() {
console.log(‘Hello from a WXT content script’);
},
});

Enter fullscreen mode

Exit fullscreen mode

Storage is a type-safe, reactive wrapper over browser.storage:

import { storage } from ‘#imports’;

const theme = storage.defineItem’light’ | ‘dark’>(‘local:theme’, {
fallback: ‘dark’,
});

await theme.setValue(‘light’);

Enter fullscreen mode

Exit fullscreen mode

Why people pick it:

Vite under the hood. Near-instant dev server start, fast builds.

Framework-agnostic. React, Vue, Svelte, Solid, or vanilla, all first-class. Want to use Svelte to shave bundle size? Go ahead.

True cross-browser. One codebase builds for Chrome, Firefox, Safari, and Edge, and it papers over the chrome.* vs browser.* namespace mess and MV2/MV3 differences.

Best-in-class dev mode. It opens a browser with the extension already installed and gives you HMR for UI.

Publishing built in. It can produce per-browser zips and even the Firefox source archive reviewers ask for.

Healthy project. Around 9.5k stars and active maintenance as of mid-2026, with production users like Eye Dropper (1M+ users) and ChatGPT Writer (600k+).

Watch-outs: it is the newest of the three, so there are fewer Stack Overflow answers than Plasmo. The conventions are opinionated, which is the point, but you do have to learn them.

Choose WXT if you are starting a new project and want speed, cross-browser support, and a maintained foundation without locking yourself into one UI library.

Plasmo: the React-first framework with the most tutorials

Plasmo was the framework that made extension dev feel like Next.js. Create a popup.tsx, export a React component, done. It still has the largest content library and the slickest first-run experience for React developers.

// content.tsx
import type { PlasmoCSConfig } from “plasmo”

export const config: PlasmoCSConfig = {
matches: (“https://www.github.com/*”)
}

const Overlay = () => div>Injected by Plasmodiv>
export default Overlay

Enter fullscreen mode

Exit fullscreen mode

Storage and messaging ship as dedicated packages:

import { Storage } from “@plasmohq/storage”

const storage = new Storage()
await storage.set(“theme”, “dark”)

Enter fullscreen mode

Exit fullscreen mode

Strengths:

React DX is excellent. Content Script UI with automatic Shadow DOM isolation is genuinely nice.

Biggest learning resource pool. ~12k stars and years of blog posts, videos, and starter repos.

Itero TestBed. A commercial product from the same team for staging and beta distribution before you hit the store, which none of the others offer.

The elephant in the room: maintenance. Multiple sources (including WXT’s own comparison) describe Plasmo as “in maintenance mode with little to no maintainers.” It is still on an older major version of Parcel, and that lag has real consequences, for example it blocks TailwindCSS v4. The high star count is partly legacy momentum, not current velocity. The framework is also still labeled alpha.

Choose Plasmo if you are React-only, you value the depth of existing tutorials and the Itero workflow, and you can accept the risk that feature development has slowed.

CRXJS: not a framework, a superpower for your Vite config

CRXJS (@crxjs/vite-plugin) is the odd one out: it is a Vite plugin, not a framework. You keep full ownership of your vite.config.ts and your project structure. CRXJS just teaches Vite how to build an extension, generate the manifest, and do hot reload.

// vite.config.ts
import { defineConfig } from ‘vite’
import { crx } from ‘@crxjs/vite-plugin’
import manifest from ‘./manifest.json’

export default defineConfig({
plugins: (crx({ manifest })),
})

Enter fullscreen mode

Exit fullscreen mode

Its killer feature is content-script HMR that preserves page state. Edit a content script, see it update on the page without a full reload or losing your place. For UI-heavy content scripts, that feedback loop is the fastest of the three.

The trade-off is that you get no abstractions. No built-in storage wrapper, no messaging helper, no i18n. You bring your own libraries (or raw chrome.* APIs) for everything. Cross-browser is effectively Chromium-only (Chrome and Edge); Firefox support is not the strength here.

CRXJS also has history: it sat in beta for over three years before v2.0 shipped in June 2025. It was recently revived with new maintainers, which is encouraging, but it is the smallest project of the three (~3.5k stars).

Choose CRXJS if you are an experienced developer who wants minimal magic, total control over the build, and the best content-script HMR, and you are happy to assemble the rest of the stack yourself.

Head-to-head on what matters

Build speed and bundle size

WXT and CRXJS both ride Vite (native ESM in dev, esbuild pre-bundling), so dev server start is near-instant. Plasmo’s custom Parcel bundler is the slowest, and developers migrating off it consistently report faster builds afterward. On output size, one benchmark put a WXT build around 400 KB versus roughly 800 KB for the Plasmo equivalent, though a lot of that comes down to your UI library choice (Svelte vs React) rather than the framework alone.

Cross-browser

This is where WXT pulls clearly ahead: one codebase to Chrome, Firefox, Safari, and Edge, with MV2/MV3 handled for you. Plasmo covers Chrome, Firefox, and Edge. CRXJS is realistically Chromium-only. If Firefox or Safari is on your roadmap, that decision is basically made.

Built-in APIs

WXT and Plasmo both give you storage, messaging, and content-script UI out of the box; WXT adds i18n. CRXJS gives you nothing here by design. Less code to maintain vs more control, pick your philosophy.

Maintenance health

For a project you will maintain for years, this is arguably the most important column in the table. WXT is actively developed. CRXJS is freshly revived. Plasmo’s slowdown is the real risk, and a stalled bundler dependency tends to quietly block the modern tools you will want later.

A simple decision tree

Need Firefox or Safari? WXT.

React-only team that lives in tutorials and wants Itero TestBed, and you accept maintenance risk? Plasmo.

Senior dev who wants a bare Vite setup and the fastest content-script HMR? CRXJS.

Anything else, or you just want the boring safe choice? WXT.

Building is only half the job

Here is the part nobody puts in the framework README: the framework decides how fast you build. It does nothing for whether anyone finds and installs your extension.

The Chrome Web Store is a discovery black box. New extensions launch invisible, ranking is heavily influenced by early reviews and keyword placement in your title and description, and you get almost no analytics on where your install funnel leaks (impressions to listing to install to retention).

A few practical things that move the needle once your code is shipped, regardless of which framework you chose:

Get your first real reviews early. Ranking and social proof both stall without them, and fake reviews get your listing pulled.

Make the listing assets convert. Icon, screenshots, and the small promo tile do more for install rate than another feature.

Watch your category. Knowing what competing extensions rank for and what users complain about is cheaper than guessing.

This is the gap ExtensionBooster is built for. It is a growth platform for extension and app developers: a credit-based system for getting real, store-compliant reviews and installs (with rating protection so low-star reviews do not cost you credits), market and competitor analytics to track ratings/users in your category and mine common complaints, and showcase pages that double as SEO backlinks. It also ships free developer tools that are genuinely useful no matter your stack, an icon generator, a screenshot maker, and a promo-tile cropper for the Web Store listing.

Worth bookmarking the free tools before your first submission, since you will need those listing assets the day you ship.

FAQ

Is WXT better than Plasmo?For most new projects in 2026, yes, mainly because it is actively maintained, Vite-fast, and works across all browsers. Plasmo still wins on React-specific tutorial depth and its Itero TestBed.

Is CRXJS a framework?No. It is a Vite plugin that adds Chrome extension support to a Vite project. You keep full control of the config and provide your own storage/messaging/i18n.

Can I migrate from Plasmo to WXT?Yes, and it is a common move. Expect to rewrite entrypoint conventions and swap @plasmohq/storage for WXT’s storage API, but builds and dev startup get noticeably faster.

Which is best for a React extension?Both WXT and Plasmo handle React well. Plasmo is React-first with more examples; WXT gives you React plus a maintained, cross-browser foundation and the option to use a lighter UI library later.

Which has the best hot reload?CRXJS for content scripts (state-preserving). WXT for overall UI dev experience. Plasmo’s HMR is tuned for React and falls back to full reloads otherwise.

Bottom line

WXT is the default I would hand a new team in 2026.

Plasmo is still a strong React experience if you accept the maintenance risk and want the Itero workflow.

CRXJS is the connoisseur’s choice for control and content-script HMR.

Pick the build tool that fits your team, then put real energy into the part that frameworks ignore: getting discovered and installed.

Sources: WXT official comparison, WXT homepage, Plasmo docs, The 2025 State of Browser Extension Frameworks, and project GitHub repos.



Source link

TECH & AI
Learning Linux from Scratch: My First Week in DevOps
jackminion 0


Hello everyone! 👋

Welcome to Week 1 of my DevOps learning journey.

As a final-year BCA student specializing in Cloud Computing, I have decided to document my journey toward becoming a DevOps Engineer. This blog series will cover everything I learn, from Linux fundamentals to cloud computing, containers, CI/CD, Kubernetes, and monitoring tools.

Since Linux is the backbone of most DevOps environments, I decided to start my journey by learning Linux fundamentals and essential commands.

Why Linux Matters in DevOps

Most servers in cloud environments run Linux. Whether you’re working with AWS EC2 instances, Docker containers, Kubernetes clusters, or CI/CD pipelines, Linux knowledge is essential.

As a DevOps Engineer, you’ll frequently:

Manage Linux servers
Deploy applications
Troubleshoot issues
Monitor system performance
Automate tasks using shell scripts

That’s why Linux is often considered the first skill every DevOps engineer should master.

What I Learned This Week

Understanding the Linux File System

One of the first things I learned was how Linux organizes files and directories.

Some important directories include:

/ – Root directory

/home – User home directories

/etc – Configuration files

/var – Logs and variable data

/tmp – Temporary files

/usr – User programs and utilities

Understanding the file system structure helps navigate servers more effectively.

Basic Navigation Commands

I practiced several commands used daily by Linux administrators.

Check Current Directory

pwd

Enter fullscreen mode

Exit fullscreen mode

List Files and Directories

ls
ls -l
ls -la

Enter fullscreen mode

Exit fullscreen mode

Change Directory

cd /home

Enter fullscreen mode

Exit fullscreen mode

Create Directory

mkdir project

Enter fullscreen mode

Exit fullscreen mode

Remove Directory

rmdir project

Enter fullscreen mode

Exit fullscreen mode

File Management Commands

Working with files is a common task in Linux.

Create a File

touch file.txt

Enter fullscreen mode

Exit fullscreen mode

Copy Files

cp file.txt backup.txt

Enter fullscreen mode

Exit fullscreen mode

Move Files

mv file.txt documents/

Enter fullscreen mode

Exit fullscreen mode

Delete Files

rm file.txt

Enter fullscreen mode

Exit fullscreen mode

View File Content

cat file.txt

Enter fullscreen mode

Exit fullscreen mode

Viewing System Information

I also learned how to check system details.

Check CPU Information

lscpu

Enter fullscreen mode

Exit fullscreen mode

Check Memory Usage

free -h

Enter fullscreen mode

Exit fullscreen mode

Check Disk Usage

df -h

Enter fullscreen mode

Exit fullscreen mode

Check Running Processes

ps -ef

Enter fullscreen mode

Exit fullscreen mode

Monitor Processes in Real Time

top

Enter fullscreen mode

Exit fullscreen mode

Understanding Permissions

Linux uses permissions to control access to files and directories.

I learned about:

Read (r)
Write (w)
Execute (x)

Viewing permissions:

ls -l

Enter fullscreen mode

Exit fullscreen mode

Changing permissions:

chmod 755 script.sh

Enter fullscreen mode

Exit fullscreen mode

Changing ownership:

chown user:user file.txt

Enter fullscreen mode

Exit fullscreen mode

Permissions are critical for maintaining system security.

Service Management

One interesting topic was managing services using systemctl.

Check Service Status

systemctl status nginx

Enter fullscreen mode

Exit fullscreen mode

Start a Service

systemctl start nginx

Enter fullscreen mode

Exit fullscreen mode

Stop a Service

systemctl stop nginx

Enter fullscreen mode

Exit fullscreen mode

Restart a Service

systemctl restart nginx

Enter fullscreen mode

Exit fullscreen mode

This is especially useful when managing web servers and applications.

Viewing Logs

Logs help identify issues and troubleshoot systems.

tail -f /var/log/messages

Enter fullscreen mode

Exit fullscreen mode

journalctl -xe

Enter fullscreen mode

Exit fullscreen mode

Understanding logs is one of the most important skills for troubleshooting production systems.

My First Bash Script

I wrote a simple script to check whether Nginx is running.

#!/bin/bash

if systemctl is-active –quiet nginx
then
echo “Nginx is running”
else
echo “Nginx is not running”
fi

Enter fullscreen mode

Exit fullscreen mode

This helped me understand:

if-else conditions
shell scripting basics
automation concepts

It was my first step toward infrastructure automation.

Challenges I Faced

During my learning, I encountered a few challenges:

Understanding Linux permissions
Navigating directories quickly
Reading system logs
Writing Bash scripts correctly

After practicing commands repeatedly and experimenting on AWS EC2 instances, these concepts became much clearer.

Key Takeaways

This week taught me that Linux is much more than just a command-line operating system.

I learned:

✅ Linux file system structure

✅ Essential Linux commands

✅ File and directory management

✅ System monitoring basics

✅ Service management

✅ Log analysis

✅ Bash scripting fundamentals

Most importantly, I realized that strong Linux fundamentals make learning DevOps tools much easier.

What’s Next?

In Week 2, I plan to learn:

Advanced Linux Commands
User and Group Management
Networking Basics
SSH and Remote Access
Package Management
More Bash Scripting

Final Thoughts

Every DevOps Engineer starts somewhere, and Linux is the perfect place to begin.

This week gave me a solid foundation and increased my confidence in working with servers and cloud environments. I’m excited to continue learning and sharing my progress through this blog series.

If you’re also starting your DevOps journey, feel free to connect and share your experiences.

See you in Week 2! 🚀



Source link

TECH & AI
You Can’t Govern the AI You Can’t See
jackminion 0



AI governance starts with visibility: a policy, a budget, or a guardrail can only act on the AI traffic a team can actually see. This guide explains why so much AI use stays out of IT’s view, why that gap stops governance before it starts, and how the Bifrost AI gateway and Bifrost Edge close it by making endpoint AI both visible and governable.

Every AI governance control an organization owns, from budgets and access rules to guardrails and audit trails, can only act on the AI traffic it can actually see. That ability to see what AI is running and what it is sending, often called AI visibility, is the precondition for everything else. The trouble is that most AI used at work now runs on the endpoint, inside desktop apps, browser tabs, and coding agents that reach a model provider directly, so the activity never reaches the systems security teams watch. A request that leaves a laptop for a third-party model without crossing a monitored path is, for governance purposes, a request that did not happen. The gap is wide, as a 2025 Gartner survey of cybersecurity leaders found that 69 percent have evidence or suspicion that employees are using public generative AI at work, which is exactly the usage most teams cannot account for.

Why you can’t govern what you can’t see

Governance is a chain of steps, and visibility is the first link. To act on an AI request, a system has to see it, attach an identity and a policy to it, enforce limits on it, and record what happened. When the first step is missing, none of the steps after it can run, because a control that never observes a request has nothing to act on.

This plays out the same way across every control a security or platform team relies on. A data guardrail that never inspects a prompt cannot redact the secret inside it. A budget that never counts a call cannot cap spending on it. A policy that never sees a tool cannot decide whether the tool is allowed. The result is not weak governance but absent governance, applied with confidence to the fraction of AI traffic that happens to be visible while the rest moves untouched.

Where AI goes out of view

AI goes out of view wherever it runs close to the user and connects straight to a provider, which describes most of where it now runs. Four blind spots account for the bulk of it:

Desktop assistants such as the ChatGPT app or Claude Desktop, signed in with personal accounts the organization does not manage.
Browser AI, including in-page assistants and extensions that an employee turns on without review.
Coding agents such as Claude Code, Codex, and Cursor, which read source code and call external services from the developer’s machine.
MCP servers wired into those tools, which can read files, call APIs, and act on a user’s behalf with standing access.

The list of tools an IT team can name is routinely a fraction of what employees actually use, because every new app, browser feature, and MCP server is one more thing to find, and discovery has no natural endpoint. The tools no one tracks are not necessarily malicious; they are simply outside anyone’s view, which is what places them beyond the reach of any control. Gartner has predicted that by 2030, more than 40 percent of organizations will experience security or compliance incidents tied to the use of unauthorized AI, a direct consequence of governing only the share of activity a team can see.

Why traditional tools don’t close the gap

Traditional controls do not close the visibility gap because they were built to watch the network, while endpoint AI mostly avoids the network they watch. Network proxies and data loss prevention systems inspect what crosses the corporate perimeter, yet a large share of AI traffic leaves the device for a provider directly, over an encrypted connection that resembles ordinary web browsing and that often never passes through a corporate proxy at all.

Three gaps recur across these approaches:

Network filtering and data loss prevention sit on the corporate network path, so requests sent straight from a device to a provider, including from machines off that network, never reach them.
Blocklists work from a known list of destinations, and new apps, browser features, and MCP servers appear faster than any list is updated.
SaaS and expense audits catch tools that bill the company, but they miss free tiers, personal accounts, and anything installed locally.

Each of these methods produces a partial list at a single moment, while the real usage is continuous and changes by the day. Closing the gap calls for visibility at the point where the AI actually runs, which is the endpoint itself.

How the Bifrost AI gateway and Bifrost Edge make AI visible and governable

Making AI governable takes two things in sequence: a place where AI traffic can be seen and governed, and a way to route the AI on every machine into that place. Bifrost, the open-source AI gateway built by Maxim AI, is that place, and Bifrost Edge is what brings the endpoint into it.

On the gateway, every request that passes through is recorded by built-in observability, which captures the prompt, the response, the model, the token counts, the cost, and the latency for each call, with no change to the application. The same gateway holds the virtual keys, budgets, and rate limits that tie usage to a person or project, along with the guardrail profiles that inspect prompts and responses. The limit, until now, has been reach: the gateway could see and govern only the traffic that something had already pointed at it.

Bifrost Edge closes that reach by routing all supported AI traffic on a machine through Bifrost rather than letting it go straight to the provider. The AI that used to leave the laptop unseen now appears in the same logs, under the same policies, as the rest of an organization’s AI. The division of labor is straightforward: Edge supplies the sight by inventorying endpoint AI and routing it through the gateway, and the gateway supplies the governance by recording, inspecting, and enforcing on the traffic it can now see. The gateway stays the single control plane, and Edge becomes its reach to the endpoint, so there is no separate visibility tool and no second policy model to maintain.

See what is running across the fleet

Visibility begins with knowing what is present. Bifrost Edge discovers the MCP servers configured in each app and the AI applications in use on every machine, then assembles a live view across the fleet of which assistants and which servers are running, on which apps, and on how many devices. New apps and servers surface as they appear rather than during a periodic audit, and each one can be allowed or denied from a single console, with the decision enforced on the device.

Govern and record the traffic you can now see

Once endpoint AI is visible, the same controls that protect gateway traffic apply to it. The guardrail profiles configured in Bifrost run before a prompt reaches a model and before a response returns, so secrets and personal data are caught or redacted before they leave the machine. Virtual keys and budgets tie each request to a person and a limit, while an administrative audit trail records who changed which policy and when, signed and retained for later review.

Roll it out and keep it current

Bifrost Edge deploys through the device management platforms an organization already runs, including Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE, and JumpCloud, across macOS, Windows, and Linux. Identity and keys come from the user’s single sign-on, so no secrets sit on the device, and central changes to policy and routing reach the fleet on their own once a machine is signed in.

Common questions about AI visibility

What is AI visibility?

AI visibility is the ability to see which AI tools, models, and services are in use across an organization, and to see the individual requests they send and receive. Without it, governance controls have nothing to act on, which is why visibility is treated as the first step rather than a report generated at the end.

How do you discover shadow AI?

Shadow AI is discovered by observing AI activity where it originates. Because most of it runs on endpoints, an agent on the device, such as Bifrost Edge, can inventory the apps and MCP servers in use and route their traffic through a gateway, which turns a guess about what employees might be using into a current list of what they actually use.

Can you get visibility without blocking AI?

Visibility does not have to mean blocking AI. Routing endpoint AI through the Bifrost gateway makes each request visible and subject to guardrails and budgets while the tools keep working normally, so an organization can approve and govern AI rather than ban it. Blocking remains available for tools a team decides to disallow, but that is a policy choice rather than a side effect of gaining visibility.

Visibility first, then governance

Shadow AI is, at its core, a visibility problem before it is a policy problem, because the strongest policy in the world cannot reach a request no one can see. The organizations that handle it well start by making endpoint AI visible, then apply the controls they already trust to the usage that visibility reveals.

Pairing the Bifrost AI gateway with Bifrost Edge gives security and platform teams both halves at once: the gateway records, inspects, and enforces, and Edge, currently in alpha, brings the AI on every machine into view so those controls have something to act on. Teams working through their own visibility gap can see how the combined approach fits together on the Bifrost Edge overview and register there for alpha access.



Source link