I’ve spent most of my career working on Gecko, the browser engine behind\nFirefox. Years in a big, mature codebase teach you a lot. You learn how things\nfit together, where the hard problems hide, and which ideas have already been\ntried (sometimes more than once).
\nThey also change how you think, and you don’t really notice it happening. Some\nabstractions become so familiar that they stop looking like design choices.\nThreading models, IPC boundaries, ownership rules, API layers: after a while,\nthat’s just how things are done. Most of the time this helps. But it also makes\nit harder to imagine doing things any other way.
\nGetting involved with Servo was one of the reasons I joined Igalia. Early in my\ncareer, there was a point where I finally understood enough of Gecko to make\nreal changes in it. It took a while, and I remember how good that felt.
\nWorking on Servo gave me some of that feeling again. Obviously I knew a lot\nmore this time. Still, I was back to reading unfamiliar code and slowly\nfiguring out how a browser engine works, only now most of it was Rust. A lot of\nthe problems looked familiar to me, mostly storage, concurrency and async\nstuff. But the code around them was organized differently, and I kept running\ninto things I’d stopped thinking about years ago.
\nRust is a big part of why. The compiler wants you to be explicit about who owns\nwhat and how long it lives. In C++, I’ve become used to certain ownership\npatterns over the years. Rust made me think about some of them again, and a\nfew times I realized that the design I had in mind wasn’t as obvious as I\nthought.
\nComparing the two engines is interesting in itself. Gecko has decades of\ndevelopment, compatibility requirements and real-world experience behind it.\nServo tackles many of the same problems with different abstractions and\nconstraints. I think Servo has a lot of potential, and working with both\nengines has made me rethink some of the assumptions I’d developed over the\nyears.
\nAfter so many years of maintaining production code, it’s refreshing to be a\nbeginner again in some areas. The experience is still there, but it’s easier to\nask basic questions. Why is this boundary here? Does this operation really need\nto be async? Do we actually need this lock?
\nI especially enjoyed asking those questions while helping with IndexedDB in\nServo. I’ve worked on IndexedDB in Gecko for many years, so seeing it built in\nanother engine made me look at old decisions differently.
\nThreading is a good example. In Gecko, IndexedDB work can be spread across a\npool of up to 20 threads, and I’d always assumed more parallelism was better.\nThen I ran some cross-browser comparisons under heavy multi-database load and,\nout of curiosity, limited Firefox to a single thread. In that test, the\nsingle-threaded configuration finished fastest. I didn’t expect that at all. It\nopened up questions about responsiveness and scheduling that I’d like to\nexplore in Servo some day. That’s probably worth a separate post.
\nLately, other projects, mostly on Firefox, have kept me busy, so I haven’t had\nmuch time for Servo. But I’m looking forward to getting back to it. Some of the\nwork there was new to me, but what I enjoyed most was seeing familiar things\nagain, from a different angle.
\n", "date_published": "2026-10-16T00:00:00Z" } ] }