The starter post

We all start somewhere

Hello all, happy to start this first post!

Around five years ago, I had my first experience with browser extensions. It was with Brave's first attempt to build their desktop browser, then a fork of Electron. It was a good experience because as I got to know more about extension capabilities, the tooling to make it work was bad. At the time, I blamed Electron and our effort to make it a browser. "it's not good because it's not standard," I thought then.

I kept hacking with extensions here and there until Brave moved from Electron to Chromium, and my first task was to move Shields (the native Brave browser extension) to the new codebase. The extension was bundled with React and some magic to make it reload on file save. Worked great! I started getting more effective with extension changes, got more work to do, and more issues assigned. Browser extensions "clicked."

As I got interested in the topic, I was surprised to know that a total of one book about Chrome extensions was released, and zero about developing cross-browser extensions. How do people learn to develop browser extensions? In the web development world, six months away can take you easily one year to catch up. Chrome introduced the current extension API (JavaScript) back in 2010. Extensions, as we know today, are ten years old technology.

10-year-old technology. Supported by all major browsers. One book about how to do it in one browser. No book about how to do it in a cross-browser way.

The documentation around building browser extensions from both MDN and Chrome is great, but I feel I miss a "glue," something that could guide me step-by-step, not a reference manual to check whenever I'm stuck. I really wanted a book.

Then why not write a book myself?

10-year-old technology. Supported by all major browsers. One book about how to do it in one browser. No book about how to do it in a cross-browser way.

Why no one (actually one, but no free propaganda) ever cared about writing a browser extensions book?

I would easily write a book about extensions. But not just "a book" but "the book". If it's the first, it can be the only, too.

A great book with everything you need to know to get up to speed with browser extensions. Not only browser extensions. Cross-browser extensions. If I'm planning to do this, let's do it cool.

The book needs to teach how to create extensions for most (if not all) possible scenarios: an extension to hack the browser theme; an extension to hack the URL bar; an extension to replace the new tab page; an extension to inject styles and scripts into a website. You get the point.

The book needs to provide trust to readers so they can expect to learn everything needed to create a real-world browser extension, and why not, to use the book to their own advantage when answering questions on StackOverflow, helping peers, or advancing/switching their careers.

I like the part of helping people through education. So much I planned that the book source would also be available on GitHub. This way, I can reach and help as many people as possible (the book is easily discoverable on GitHub to its target audience).

The browser extensions book was created. I opened my writing app (again, no propaganda. At least not until I feel "it's good") and immediately started theorizing chapters and typing down ideas.


It's dangerous to go alone

As I advanced in the writings and things started making sense as a whole, I often caught myself reminding readers how to perform basic operations like visiting the debug page, unpacking, loading, and reloading extensions, really boring work. At this point, I started thinking that maybe that's the reason there isn't much material about browser extensions: they are hard for the wrong reasons. Much manual work has something ready, an ecosystem much poorer than the web, with lots of workarounds to have page-reload and cross-browser support. The browser extensions ecosystem somehow got suck in 2010.

So did my book.

Now there was my "book" full of comments such as "go to your browser of choice and type: <browser_vendor>://extensions to see your extensions".

That's ridiculous.

As a programmer working for the web in the past years, I got familiar with tools like Yeoman, next.js, create-react-app, CLI tools that could generate "work-ready" code in no time. I wish browser extensions could have such a tool so I can bootstrap as many extensions I want without asking the user to install anything. The closer program I found to my taste was web-ext from the fine folks at Mozilla. But web-ext wasn't really what I wanted. I wanted convenience. Full convenience. The book must be focused on teaching how to develop browser extensions, not how to download and install stuff.

Saw a cool browser extension hosted on GitHub? A one-line command not only downloads it for you, but kick starts a server with your extension loaded.

A browser extension with React support? Pass a one-line command with a flag to download a template.

Your favorite browser isn't Chrome or Firefox? Do nothing to have your main browser loaded or pass a one-line flag to choose between Edge, Brave, Opera, or any other browser with extension support.

The birth of extension-create

Using web-ext was tempting, but in the end, I thought it would be better to take a step back and build this tool myself, despite being close to having enough book material to share with publishers confidently, but I knew if this step back didn't happen now, I'd have trouble getting the time needed to build it in the future, under the pressure of other people now also interested in my book, including readers.

The project started without code but a wiki page. On a page that I call "this initiative", I type down my reasons for writing such software:


I want to have the same experience I have developing cross-browser web apps while developing cross-browser web extensions.


  1. I don't want to worry about cross-browser compatibility. It should work everywhere.

  2. I want support for familiar web dev tools such as page auto-reload, JS module import, new JS syntax, etc. Without the integration hassle.

  3. Actually, from init to test, to build, to deploy, I don't want to worry about tooling at any development step.

  4. Sometimes I want to use a JS framework or TypeScript in web extensions. The tool should allow me to do that.

With that in mind, the book stopped momentarily, and the extension-crate project started to gain form.

This newsletter currently focuses on the development of both. extension-create is a CLI tool to bootstrap the many variations of a (cross) browser extension. The browser extension book is my book about writing cross-browser extensions using extension-create.

In the next email, I'll get deeper into the development process behind extension-create, the current status, and what to expect next. Good stuff!

See you,