A modern set-up for Chrome Extensions

How we chose the tech stack for our chrome extension

This is a reedition of an old post. This chrome extension (“LinkedIn to Notion” and then “recruitivity” is no longer being maintained).

Intro

LinkedIn to Notion was first shipped as a vanilla html/css/js chrome extension. Imo, it’s the best path to go down when you need to ship a first MVP.

But once you decide to turn it into a proper SaaS, you must switch to a proper tech stack.

Expect to learn why and how 🧵

Who’s this post for?

This is a post for those want to develop chrome extensions and already feel constrained by vanilla js (rightfully so).

Thanks to Gauvain’s research, I’m confident we now have a killer tech stack to iterate on an extension that wants to become a SaaS.

Beware: I’m not gonna dive 10 miles deep into tech, but deeply enough so that you could get lost if you’re not tech-savvy.

Problems you’d encounter if you didn’t change your stack

Problems you’d face if you didn’t switch:

  • Lots of debugging

  • No node packages!

  • In chrome extensions, the “front” and the “back” communicate with “messages” → you’d get a shit load of them to handle.

Bottom-line: (messy code + shitty developer experience) ⇒ (slow development cycles + low resilience).

The biggest enabler

This is all a thing of the past since Gauvain revamped our tech stack. We can now focus on (product-led) growth and iterate at lightning speed.

Here’s the biggest enabler in this new stack 👇

Plasmo

Plasmo! A well-documented development framework with ~400 contributors on Github that somehow “buttons up” the development of chrome extensions. Some say it’s an extension next.js.

We now have access to the whole toolbox of the modern software engineer (more about that below), starting with node packages.

React

In the toolbox of “the modern software engineer”, there’s react, obviously. Plasmo lets you use it and, that too, is a game-changer.

You’ve never coded with React? Fear not: here’s a top-notch youtube vid to get you up to speed in no time.

Typescript

Combining typescript and react is now standard procedure too.

Even though I had already coded in react ~4y ago, I had never written a single line of ts.

Small digression on recruitment standards for software engineers

Which makes me realise something.

I found 80% of typescript to be fairly simple. It’s something that any software engineer could learn on the spot if they already know js (I did)—which makes me wonder why ts is such a hard requirement for some hiring companies.

Anyway.

Tailwind

Forget the hours of brainstorming just to find suitable class names for your button that needs a 5px border radius and a blue background colour on hover.

Like most people, we don’t like css and Tailwind is the best pain-killer we’ve come across. A few pre-defined class names in your react components will suffice to get a decent design.

Development speed

Gauvain and I run on tight schedules.

And you guys know that there’s a price to pay to use react, ts and other node modules: development speed.

Two utilities have been pivotal for that matter: pnpm (frees up space on your machine + speeds up downloads) and vite.

Not 100% clear on the latter, but bottom line is: you can dev and build your code faster than ever.

Storybook

We’re using Storybook to create a proper design system. Why you ask?

For reusability oc, consistency across the app(s) but also for the product-led growth of the extension.

It’s easy to see how growth and design intersect (and if you don’t, check this out).

Project management

Last but not least: we’re heavily relying on Notion (especially boards and databases) for resources, documentation, roadmaps, meetings, etc.

So we created a KanBan board for development issues and synced it with Github—only to realise that it’s probably sub-optimal not to use Github’s project management features.

We’ll most likely switch by the EoM.

Final words

Reply

or to participate.