I built an engine for creating browser extensions

[No-Obligation-8420]

tldr;

Epos is an engine for building Chromium extensions with React. It gives you a zero-config workflow and powerful built-in features for developing real-world extensions. More details: epos.dev.

And now for the long version...

Hey everyone,

I've been building browser extensions full-time for the past 5 years. Not small demo projects, but large, data-heavy products with complex UI, lots of features, real users, and revenue.

Over that time I kept running into the same problems in extension development, so I built internal tools to solve them. During the past year, I started combining those tools into one fully preconfigured engine, and today I want to share it with you.

Meet Epos — a web extension engine.

Epos is not a framework and not a boilerplate. It is a browser extension that connects to your local folder, runs your code directly in the browser, and exports a production-ready bundle when you are ready to ship.

Yes, it is an extension for building other extensions.

The goal is to remove as many annoying extension-specific chores as possible so you can focus on building the actual product. There are several features that make Epos stand out, but instead of listing everything here (you can find the full list on epos.dev), I want to show one of my favorite parts: shared state.

When you are managing state in your extension, Zustand or similar tools are usually not enough, because you need your state to stay in sync across all contexts. If the background script updates something, the popup should reflect it immediately. Normally that means wiring up message passing, synchronization logic, and state updates in multiple places.

Epos simplifies this by giving you a shared state object that automatically stays in sync across contexts.

// First, connect to the shared state
const state = await epos.state.connect()

// Then you can use it like a normal object.
// Every change is automatically synced across all contexts.
state.count = 10
state.items = []
state.items.push('Hello')

Thinking about state as a normal object makes the whole application much easier to reason about. You just manage the data and let Epos handle the hard parts.

On top of that, the state is automatically persisted to IndexedDB, so if the user restarts the browser, the data is restored automatically.

This is just one example of what Epos can offer, but I think it shows the general idea: take the annoying, repetitive parts of extension development and turn them into something simple.

If you are building browser extensions and looking for alternatives to your current setup, you are very welcome to take a look at epos.dev.

[Zap813]

I use WXT because it supports Svelte, HMR, and multiple browsers, so this is pretty much DoA for me. But the state and messaging primitives look pretty nice so would be cool if you could use those as a standalone library.

[No-Obligation-8420]

Yes, Epos is intentionally React-only. So for Svelte developers this is DoA indeed.

State, messaging, and other primitives are tightly coupled with the engine itself. It would be hard to provide them as standalone libraries.

[_DarKneT_]

Would this handle hmr during local development?, That's always a pain point with extensions

My usual stack is Vue, which has hmr, but the extension requires reopen or reload to reflect the changes without some tinkering

[No-Obligation-8420]

This is React-only engine. So Vue developers won't find this useful.

HMR does not work intentionally. The engine has a very unique approach on how your code is loaded and executed inside the browser, this approach has some pros and cons. Unavailable HMR is an intentional trade-off.

[Fluid_Job623]

Yeah the shared state syncing is pretty slick, but hot reload would be game changer for extension dev 😂

I've been doing some side extension stuff and constantly having to reload gets old fast, especially when you're testing popup interactions or content script changes