100 patches to 5 browsers in 18 months

Over the last two years I've been increasingly contributing to web browsers. I recently made my 100th patch to browser engines, which I consider somewhat of a milestone. It's rewarding and enjoyable, and it's something others seem interested by, as I'm frequently asked about it. It seems to have even taken some browser engineers by surprise: what's my deal? Why all the contributions? Am I looking for a job? I read the other day that if you had to repeat something 3 times you should write an article (that's an extremely niche reference that might get a chortle from someone). Hopefully there's some advice scattered throughout this diatribe for those aspiring to do the same.

First the history; I've been working at GitHub since 2017, spending my first 5 years on the "Web Systems" team. This team managed essentially all of the JavaScript that was served to users on github.com. It has been one of the best teams I've ever worked on. Aside from the privilege of being surrounded by colleagues smarter than me, it was great to work on a team where we were all incredibly well aligned on our goal to ship as little client side code as possible to get the job done. We regularly looked for opportunities to remove code where we could, such as finding native functionality to lean on, polyfilling new features and removing old libraries, or carefully cutting back on code to support older browsers. We tried to promote new and upcoming browser features and maintained lists of browser bugs to watch for when we could remove fixes, and regularly spoke to the browser vendors about incorporating new features (fingers still crossed on a browser native emoji picker). We minimised the amount of external dependencies, at the time I think we had two third party dependencies that weren't authored by us. This wasn't because we thought we could write better code, but because it let us aggressively pare down code that didn't serve us, and kept us nimble because we only had to answer to ourselves. Even as recently as 2019 the entirety of GitHub's JavaScript, compressed, would fit inside a 1.44mb floppy disc. Small enough to internalize but large enough that we didn't want to accumulate much more complexity - we were incentivized to offload new problems. This let us think deeply about how problems got solved, and (because the entire teams output wasn't spent managing hundreds of thousands of lines of JavaScript) we had the time to make more strategic fixes to problems. One example of this; one of my team-mates - Mu-An - discovered a focus bug in Firefox was biting us and rather than introduce more JavaScript to work around this, Mu-An and our other team mate David just... fixed it. I didn't know you could just do that. I mean, I knew the major web browsers were all open source but they were intimidating and had hundreds of engineers working on them and didn't need to waste their time on fixing our issues... or did they? This piqued my interest, and Mu-An graciously guided through fixing a different focus bug we found.

Gradually, my colleagues on the Web Systems team left. Josh in 2020, David in 2021, Mu-An in 2022, Mislav & Kristján in 2023. Each departure re-affirmed my responsibility to retain some of this team's DNA and continue to extol the virtues of managing small teams with tight responsibilities, using The Web Platform as the foundational core. So I set myself a mission: contribute some code to all three of the major browser engines. There was just one problem. I didn't know a lick of C++ and all three major browsers were built on massive, sprawling C++ codebases. The first C++ I had ever altered was in that tiny focus bug patch I'd written a couple of years prior. Even without the barrier of an entirely new language to learn, these are still gigantic codebases with millions of lines of code. It was intimidating.

Leave a Comment