Chromium Handcuffs: Realising the limitations of Web Browsers

As a relatively new software engineer with ~3 years experience, I mostly enjoy developing for the web. I started with React and so don’t feel the framework fatigue which plagues others, and many of the modern platforms such as Vercel and Firebase mean development is easier than ever.

I’m not blind to the faults. Framework bloating can be out of hand. Javascript, as pleasant as it is to write, has all sorts of strange kinks and cross-browser debugging will forever be frustrating.

But recently I had an experience which made me hyper-aware of the box that most of us work in, and how dangerous that could be. Yes, this may come from a place of naivety, but until now I’d put little thought into the browser itself, how it’s features are maintained, and what it takes to implement a new, standard feature across multiple different web engines.

For Context

The realisation came when working with a relatively obscure browser feature - the Web Audio API. I’d found an irregularity when building my site and playing audio through bluetooth headphones which seemed to only be a problem on Chromium based browsers.

So I went and found the WC3 spec. I got excited as I didn’t know what this was, and thought I could report implementation issues for the API here. Nope. This is just a repo which tracks how / what all browsers should do to create a satisfactory implementation of the proposed API. Issues here are not fed to the respective browser implementation.

Okay, so with it being a Chromium issue, over to the Chromium bug tracker I went. Logged my report and waited. Actually, I’m still waiting on that.

Hacking around it

In the meantime, I figured surely there was a way to hack around my issue. Digging deep for niche workarounds lead me to more logged yet unsolved bugs, with veterans, tongue-in-cheek, explaining how it’s always been like this, insinuating that the fresh meat better get used to it.

Each workaround idea I had would lead to a new problem, with its own bug report, some dating as far back as 2016.

This was when I began to realise the boundaries of a web browser. I, and seemingly some before me, had hit a development wall where the implementation details go from code we are writing, to the code of the browser itself.

It sounds as if I am slating the Chromium developers, which is not my intention. It’s open source. I assume the contributors are not paid. I myself could, in theory, learn the codebase and then contribute a fix to my own problem.

What this means

Programmers of old, building an application from the ground up, would have complete control of their product. Doing the same today is a clear tradeoff between speed of development, with accessibility which users have come to expect and total jurisdiction over what you make.

Browser implementations themselves, Chrome in particular, often come under scrutiny. The latest example is their Chrome Manifest V3 controversy, which while seemingly unintentionally breaking a lot of browser extensions, also deliberately makes the decision to ban ad blockers.

These limitations and enforced policies are almost at odds with one another, in the worst possible way. Independent committees and open source development slowing down releases to maintain a more ‘free’ web, while the very browsers on top can restrict this underlying engine as they like.

Don’t forget that a significant portion of desktop and even mobile apps nowadays are just Election wrappers of Chromium based web apps. Yes, this is most of the time a blessing which allows significant code re-usage and easy cross-platform apps. However, all of which are subjected to the same limitations as a regular browser.

You might say something along the lines of ‘welcome to the real world’. I know.

I was naive to it, but I now realise most of what I develop lives inside a playground, a box, that is outside of my control.

It makes me wonder if there have been great ideas that get sacrificed due to their inability to work inside a browser. Or if, with a different method of browser development, what capabilities could be unlocked for web developers.

I’ve been living in the cushioned world of web development, which has been mostly adequate and easy-going. But this box has limits, and we may be tied down in our Chromium Handcuffs.