Just Keep At It: A Decade at Mozilla · Ryan Hunt's BlogRyan Hunt's Blog<br>Well, that went by quick!<br>I joined Mozilla as an intern in 2016. I wouldn’t believe you if you told me I’d still be here in 2026, working on their WebAssembly engine and contributing to the WebAssembly standards process.<br>Ten years at one company is a long time in this industry. I’m feeling a bit sentimental, so I thought I’d share how that happened, and why I’m still here.<br>Beginnings<br>I came to Mozilla through Rust. I was a CS student at Bethel University at the time, interested in this new systems language, and Mozilla was the company building it.<br>There was no Rust internship on offer, so I applied for the two roles that came closest to what I cared about: one on their Graphics team, and one on SpiderMonkey (Mozilla’s JavaScript engine).<br>I got the Graphics one. Not my first choice, but I knew I was a long shot for the compiler role.<br>I spent that summer in Mozilla’s Mountain View office, thrown into the largest and most complex codebase I’d ever seen. Parts of it about as old as I was! There was no hand-holding. You either needed to ping the right person on IRC (RIP), or figure it out yourself.<br>My desk at Mozilla's Mountain View office from when I was an internWhiteboard design firehose from within an hour after startingIt was hard, and I enjoyed it. I learned more that summer than all my years in college combined.<br>I spent most of that summer wrestling with impostor syndrome (TBH, I probably still have it). Getting a full-time offer should’ve challenged that notion, but somehow it didn’t.<br>Mozilla originally asked that I move to Toronto as a condition of joining full-time, but I was able to negotiate to try out remote first. I wanted to be near my family back in Minnesota, including my now-wife. Mozilla has been accepting of remote work, and it’s a big strength.<br>Over the next few years I worked across the graphics engine in Firefox: the GPU process, off-main-thread painting, async pan-zoom, CSS scroll anchoring, and eventually a bit of Fission too.<br>The switch<br>By 2019, after three years on the Graphics team, I was ready for a new challenge.<br>A position opened on the WebAssembly team, part of SpiderMonkey, the same area I’d originally applied to as an intern. I applied again. I didn’t have any formal compiler background, just some reading and hacking on things in my spare time. I don’t know exactly why they took a chance on me, but I’m thankful they did.<br>Getting started on the WebAssembly team was, if anything, harder than my first days on Graphics. I was pretty good at navigating a complicated codebase at that point. But for SpiderMonkey that was just table stakes. To really contribute, I needed to learn the theory and practice of compilers. It was (and is) a lot to learn, but I was excited to be paid to do it.<br>When our previous team lead moved on in 2022, I stepped into a larger role, taking on Mozilla’s representation in the WebAssembly Community Group and the standards process.<br>WasMan, from a WebAssembly CG meeting in PittsburghIt’s strange to think the compiler role I was a long shot for as an intern is where I ended up all along, and it’s turned into the most rewarding work of my career.<br>What I’ve learned<br>The web is actually great<br>When I started, I wasn’t interested in the web as a platform, only in low-level systems like computer graphics or compilers. My vague opinion was that the web should’ve just been POSIX with a GPU API.<br>Ten years in, I’ve come to appreciate the web. It solves genuinely hard problems, and has survived multiple technology shifts while other platforms failed. It’s easy to take for granted.<br>A web browser handles several difficult things at once:<br>Strict backwards compatibility : “don’t break the web”.<br>Open standards : the web is defined by standards, not just a single company or implementation.<br>Portability : the web runs on TVs, mobile devices, laptops, desktops, and servers.<br>User control over content : ad blocking, client-side translations, reader mode, and others.<br>No central gatekeeper : anyone can buy a domain and launch a website. There is no approval process or app store.<br>Untrusted content : it’s expected to be reasonably safe to open up an arbitrary link. Browsers must protect users.<br>Performance : users expect all this to run as close to native speeds as possible.<br>If you want a simpler and better replacement for the web platform, you need to grapple with all of those things. I’ve come to realize there is an essential complexity to this problem that I had overlooked.<br>Sure, there are parts you’d redesign given a clean slate. But no alternative has taken hold, and I don’t think that’s an accident. Designing something better is hard.<br>Focus on what you can control<br>Mozilla has not always been a calm organization. There have been...