People think of browser extensions as brittle: a site changes its CSS selectors, and bam the extension breaks.

But I think the opposite: it's wild how *resilient* browser extensions often are!

Consider the context: I can extend any aspect of a webapp UI, with zero support or foresight by the original app devs... and it actually works?

I've built extensions that kept working for years w/ no updates, even as the underlying app changed a lot. Obviously it's not always that easy, but sometimes it really is.

feels a bit like wikipedia to me: bad idea in theory, but somehow it works. wait so why does this work??

hmm.. well, If my extension had been a code patch to the app codebase, probably would have required a lot of rebasing to deal with constant churn of changes.

Instead, my extension was only coupled to the original app by the barest of threads: a few assumptions about the structure of the DOM. A lot could change while leaving those assumptions untouched.

I guess a key thing here is that browser extension "content scripts" run in an isolated world separate from the main page. So you can't access the program state or modify the original program -- you only get access to the DOM.

This sandboxing is often super annoying when writing an extension... so much stupid scraping... but it also means you're avoiding depending on lots of implementation details, which saves you later.

Another thing: UI tends to be fairly stable because people don't like change. And so by hitching extensions to the UI, we benefit from that conservative force.

Finally -- human-readable CSS selectors are a dying thing, but they were great while they lasted for extension authoring. There's a deep pattern there: stable "addressability" -- which was originally there to manage coordination btwn HTML and CSS inside of the app, but also had the side effect of hooks that extensions could latch onto (more on this here: twitter.com/geoffreylitt/s)

hmm ok what are my overall takeaways here.

"unanticipated" or "adversarial" customization, where you're not building on official extension APIs, is hard mode, and never gonna be perfectly stable. but it's awesome and important because we're never gonna get all the extension APIs we want.

And it seems like browser extensions hint at an interesting pattern for how to achieve this: Couple extensions to the original app only through a user-facing UI tree -- which represents a relatively stable artifact with addressable parts.

I think the biggest flaw with this idea (and with browser extensions in general) is that they focus on client-side / UI modifications, and don't have as much to offer in full-stack feature changes. What would it look like to apply these loose coupling ideas to deeper changes...?

Sublime browser extension guide

Geoffrey Litt • Tweet