The Weekly Dev's Brew

Writing a Web Browser in 2025 (with Andreas Kling)

• Jan-Niklas Wortmann | Web Development Enthusiast & Podcast Host • Episode 14

Share episode

What does it take to build a web browser when everyone says it's impossible? In this episode, we sit down with Andreas Kling, the engineer behind Ladybird—the only major browser project that doesn't take money from Google.
Andreas breaks down a uncomfortable truth: Google funds every major browser through search deals. Chrome, Firefox, Safari—they're all dependent on Google's advertising revenue. Ladybird is building the first truly independent alternative since the early Firefox days.
We dive deep into the technical challenges of implementing web standards from scratch, why their 700,000 lines of code can compete with Chrome's 100+ million, and how they're making browser code that actually mirrors the specifications. Andreas reveals why they switched from UTF-8 to UTF-16, why they didn't choose Rust, and how they handle the constant evolution of living web standards.
From the "draw the owl" problem of CSS specifications to building a sustainable nonprofit model with sponsors like Shopify, Andreas shares the engineering and business decisions behind their ambitious timeline: alpha in 2026, beta in 2027, and v1.0 by 2028.

Our Fantastic Guest
Andreas Kling
President of the Ladybird Browser Initiative.

X

Links and Resources
Ladybird Browser Website
Web Platform Tests
Fil-C (memory-safe C++ compiler)

Thank you very much for listening!

We are also pretty much on all social media platforms, so make sure to like and subscribe!

Homepage - https://www.weeklybrew.dev/

BlueSky - https://bsky.app/profile/weeklybrew.dev
Instagram - https://www.instagram.com/weeklydevsbrew/
TikTok - https://www.tiktok.com/@weeklybrew.dev
YouTube - https://www.youtube.com/@theweeklydevsbrew
LinkedIn - https://linkedin.com/company/the-weekly-dev-s-brew

Hello everyone, welcome to another episode of the Weekly Dev's Brew. Today I'm here with Andreas Kling. It's a very German name, so I tend to pronounce it very German. It sounds great in German. Okay, I don't think I could really do justice introducing you, so do you mind introducing yourself? Sure, so I'm Andreas Kling. I am a lifelong browser nerd. I've worked on browsers my entire adult life, it feels like. Worked on the less famous Conqueror browser back in KDE like 20 years ago. After that, worked at Nokia on some of their phone browsers and the cute WebKit port that they had there. From then, went to Apple, worked on Safari for many years. And then in 2017, I thought, I'm going to do something else with my life instead of being just a browser developer. So I left and I was able to go like a little under two years, I think, before I was working on browsers again. So what happened was I left and then I started working on an operating system just for fun. As you do. As one does, to entertain myself and stay healthy, you know, focused on something useful. And eventually, a new operating system is going to need a new browser. And, you know, I know how to make those. So I just started doodling and one thing led to another. And now, you know, this is like seven years ago now. So now we have stood up a new browser called Ladybird. And it's currently in pre-alpha state. We started a nonprofit to run development and to get sponsors on board and hire engineers and stuff. So we are now seven people working full time on it. And we have a community of volunteer contributors as well. And the project has really taken off. And it's really exciting, really fun. And it seems no matter what I do, I just can't escape browser development. But that's okay. I'm pretty happy with it, I think. But the important thing to know about Ladybird is that nowadays when people say a new browser, everybody just assumes it's a new Chromium with some, like, little tweak. You know, it has, like, a Chromium with ad blocker or Chromium with crypto, Chromium with an AI sidebar. No, no, no, none of that. It's not that. It's actually a new browser. It's a new engine built on web standards alone. So we just try to implement the standards or specifications as they exist. And it's a lot of work. But people have been screaming in my face for years that this is not possible. And I've just been saying, sure, I'm going to do it anyway. And amazingly, we're doing it anyway. So it's pretty cool. This actually goes over into my question. So what is it that apparently keeps you hooked with browsers? Because it's not a very common field for developers to spend their effort in. And you seem very much to now have this attitude of, like, watch me. I just want to prove the world wrong. Right. I don't know what it is about browsers. I have loved the web since I first got online in, like, 96 or something like that, whenever it was. I thought, this is sick. This is the best thing ever. I love it. I wanted to be online all the time, which my parents hated because, you know, you used to pay by the minute back in those days. But I just loved it. And I think I never stopped loving it. And, you know, at some point in, like, 2003, 2004, I realized that browsers are this thing that you can work on. Like, they're just a big pile of code. And you can edit it and recompile and see what happens. And the first time I did that, I got super hooked. So one of the first things I worked on was ad blocking in Conqueror. So somebody added ad blocking to it. But you had to reload the page before new filters would take effect. So, like, you would go to a page, see that it loaded some crap. And then you would, like, add a filter saying, like, oh, I don't want to load, you know, ad.newspaper.com or whatever. And then you had to reload for that to take effect. So I made some changes to make it take effect instantly. And from that point, I was, like, hooked. It's amazing. And I think I've just never stopped thinking about browser development since that day, even though I tried hard at some points. What is it that you're trying to accomplish with Lady Bird? And I mean this in the most honest way because I appreciate the work you're doing. And I think it's great for innovation in this space, in a sense. But, like, usually, like, it's a very, it's a massive idea. It's a massive amount of effort. And usually those kind of ideas need the potential to yield a high return of investment. Right. And competing with Google, Microsoft, and you name it, is not necessarily the easiest thing. So tell me. Indeed. Competing in a product where nobody charges for it is even better. Right. So we're not really joining this game to compete in the traditional sense. Yeah. We're not here to beat anybody. And we're an open source project with lots and lots of people working on it. So there's a lot of different motivations that people have. Of course, I can talk about my own motivations and sort of the motivations behind our nonprofit that has sponsors. So what I and what we want to do is we want to build a truly independent browser. We recognize that all the major browsers have basically all their funding from one source. For anybody who's not familiar with the space, Google is that source. Google Ads pays for everything. They pay for their own browser. They pay for their browser engine, which is then picked up by other browser vendors like Microsoft Edge or Brave or Opera or whoever. All of these are Chromium with some modifications. Paid for by Google. Google pays Firefox every year. And Google pays Apple for Safari as well. And I think there isn't really an alternative browser outside of this paradigm where Google is funding the whole thing. And this is not healthy. And it's not really an open web in the sense that I understand the word open because there is a single dependency like deeply entrenched in the whole system. And so we're coming at this with a fresh take on the web, which is, hey, what if we don't take money from Google? And what if we just make a new browser based on the specs? We don't we don't try to compete with the others, but we try to just build a browser and see if it can be done. Conventional wisdom in the tech industry has been for years that it can't be done. There's like blog posts and, you know, pundits and talking heads saying that the web specifications are out of control. They're too complex. You can't implement them. It's not without a kernel of truth. You know, like they are very large. There's a large number of specs. We were just talking yesterday on our in our chat about how there seems to always be like one more CSS specification that you haven't seen before. And everybody agreed like, yeah, I found a new one like just yesterday. And sometimes I wonder, like, will we ever find all the specs? But but even so, I think it's still it's still very implementable. And we're finding that that is true. Like we are able to to render complex web applications now like we can run discord. We can run VS code in the browser, GitHub, apps like that. Cool. And, you know, these are, you know, things that were supposed to be completely impossible, according to too many people. And we're able to do them and not as well as Chrome or Safari or whatever. You know, they're a lot faster than us. They have what do you call it? Like, I guess, like cumulative centuries of engineering time put into them and put into performance and everything. So probably slightly more resources. Just a little bit more resources. Yeah. So our competitors operate with like billions of dollars in budget. We do not have that. We never will. But yeah, so that is one aspect of it. So we recognize that Google has kind of been funding the whole web space. And we're living in this paradigm of like open web, but it's kind of fake because there's a single source of funding behind all of it. And we want to get away from that. Or not even that we want to push people away from it, but we want to give people an alternative to this. Just so we can say like, here's something else. If you don't want to be in this world, here's an alternative. I mean, as a developer, obviously, I love everything you're saying. Like, it's an open source at its core, right? Yeah. But open source, other than like from a novelty perspective, usually doesn't attract that much funding. And there are obviously exceptions. I don't want to. But what is it that companies are convinced, okay, I should put some money down for that? Because I watched a keynote or like a talk you did beginning of the year where you mentioned Shopify and GitHub, I think. So Shopify was one of our earliest sponsors. Yeah. They have like sponsored more since then. And the co-founder of GitHub was a co-founder of our nonprofit as well. So Chris Wonstrath provided some early funding for us as well. So what is the interest that... Because at the end of the day, those people, even though they share similar values to like the open source system, there's still a financial incentive to some extent. So what's... Right. So everybody has different reasons for sponsoring us. Probably, yeah. And I can't really speak to like why ultimately somebody chooses to do that. But I can tell you some reasonings I've heard from our sponsors without specifying who said it. Yeah, absolutely. So a common theme is that many businesses feel that Google has like a disproportionate amount of control over what the web is. And companies that operate on the web, they don't like it, that they're sort of at the mercy of a single entity that can unilaterally sort of change the direction of the platform that they're all building all their business on. So I think that's the thing that people are unhappy about. And some look at us as a sort of moonshot that, hey, this might go nowhere. But what if there's a 5% chance that this becomes a big thing? Is it worth it for us to like throw a little bit of money at that? Evidently it is. Yeah. And so that's the thing for sure. There are other companies or sponsors who just like what we're doing for technical reasons or they're just like fans of the idea that for one reason or another. But the closest thing to a business-minded reason is like, hey, we're essentially like building on top of somebody's monopoly. Yeah. Yeah, that makes sense. Yeah. Let's invest in any moonshot that tries to steer away from that. And there aren't a lot of projects like ours. Like everybody kind of just accepts the status quo as like, ah, this is just how it is. This is the web. Google is a great steward. You know, they're putting – I mean, and I'm not shitting on Google here. Like I think Google does a great job moving the web forward. They make great products. Chromium is a fantastic piece of engineering. I have nothing bad to say about Chromium as like a piece of software. But the greater ecosystem, I think, is flawed in some important ways. Yeah. That totally makes sense. You brought up this thing before that you said you very much develop Ladybird based on the specification. How does that look? Because I've seen some of them. I looked at the nesting specification and details once I was working on that a little bit more. And it's like 100 pages long for like something that is fairly intuitive for like a developer. So talk me through this a little bit, how this looks for you from like basically like on the very other side. Sure. Yeah. Yeah. So a reference point I like to talk about is video game emulation. Have you ever worked on emulators? I've used emulators. You've used emulators. Okay. So at least you're intimately familiar with the concept. Yes. And so I like to imagine the web as like the Super Nintendo or something like that. Okay. And every web page is like a ROM. And a browser is the emulator that's supposed to run all these ROMs. And so as it turns out, you don't need like the full functionality in every edge case of the Super Nintendo to be able to play a game to your satisfaction. Yeah. Like you can play Super Mario Kart even if there's like a glitch in the sprites or like the whatever, you know, like something doesn't animate correctly or the sound isn't quite right. And we're finding the same thing with the web because the web is built on this principle of graceful degradation, which means that even if you can't handle all the features being requested in the CSS or in the JavaScript, there is sort of a graceful fallback in most cases. So like let's say that you haven't implemented CSS borders. You're just going to get the page without borders. You know, like that's just like a goofy example, but you understand what I mean? Like if you don't support images, you still get the page, but you don't see images. And so we're finding that with all these specifications, something like nesting, for example, even though it's 100 pages long, maybe there's really 20 pages of meat in there. That's what matters for 99% of the content online. And then there's that remaining little bit of stuff that's hidden in all the rest of the stuff, which is, you know, we're going to have to deal with it eventually if we want to completely support the web. But it's not essential for pretty broad compatibility, if that makes sense. Yeah, totally. And so that's what I mean, you're basically approaching it from like an 80-20 perspective where you're like, just imagine like there's a new spec coming out somewhere and one of the team members says, oh, I'm going to work on CSS nesting for the next week, month, whatever it takes to get like the 80% done that realistically, probably like more like 95% of all websites already handle more than reasonable. Yeah, that's roughly what happens. So to ground it even more, in reality, what we really do is like we have some website, some big website that starts using nesting suddenly, like Vercel.com or something like that. They just start using nesting and then it looks totally wrong in our browser. Somebody notices and says, hey, they started using nesting. I guess we'll implement the stuff that they use and then we'll see if we find some other pages that use nesting. We'll implement what they use and we do like a couple of those and we end up with pretty good coverage of the main parts of the feature. So that's sort of, we try to ground our work that way so that we're always working towards better compatibility with real content because the totally wrong approach would be to take a new spec and like start at chapter one. Here's what you're supposed to do like, well, blah, blah, blah, blah, blah, blah. Because in practice, most of the features and most of the specs are not being used that much. No. And so if we took the, let's just do all the specs in alphabetical order, we wouldn't have anything useful right now. Yeah, yeah. So that's kind of how we've been doing it. At the same time, so this is like one force pushing us forward, like the desire to be compatible with websites. We do have another thing coming from the other direction, which is, so there's a joint project between all browser vendors called the web platform tests. And it's essentially a test suite that has millions of tests for different web platform features. And the idea is if you fix a bug in a browser, you can contribute a test for that bug fix to the web platform tests. If you write a new specification or edit a specification, you can add tests for your edits to the web platform tests. And the idea is that it's supposed to keep growing over time and just become like a comprehensive test suite that if you pass this test suite, there's a real chance that you can render the web. Now, this thing is, hasn't always been there. So it's like organically grown over the last, I don't know when it started, maybe 10 years ago or something like that. I don't know the history. It used to be that every browser had independent test suites, and they still do, but now they also collaborate on this thing called WPT. And so that's sort of our other weapon to drive progress as well is that we try to make websites work, but we also use the web platform tests to make sure that we can pass all kinds of tests and edge cases and things that stuff from specifications that we might not see so much on the web, but it's still important for somebody somewhere. We recognize that we have to take both approaches because it's obviously not sufficient to just say like, oh, well, facebook.com uses these parts of the spec, so that's all that matters. Until, like today, we don't even have users. Like we are our own users. So whatever websites we visit, the developers, those are the ones where we notice things. So we kind of rely on the test suite to provide us more information about what we need to be doing as well. How do code reviews look like then? Because I mean, if the spec at the end of the day is still like the ultimate source of truth, how a feature has to work, those, I mean, we talked about this. The specs are very elaborate. So if now, I imagine, okay, you file a pull request for CSS nesting support. Like how does someone else look at that and make sense out of this? You see what I'm saying? Sure. Yeah. So this project has grown organically from literally nothing. Like it was an empty text file at some point in 2019 on my computer. So we've built this thing. So we can usually find somebody else who understands the code well enough at least to review what you've been doing. And I think probably you might also have an idea about the complexity of browsers that's based on the existing browsers. We are dramatically smaller. So I think I forget the numbers, but I think that Safari is like in the tens of millions of lines and Chromium might be in hundreds of millions of lines. And we are like six, seven hundred thousand lines maybe. Okay. So, and obviously we don't support nearly the same amount of stuff that they do. And we don't have all these cool tricks to go fast and stuff. But it's also dramatically more hackable. So that helps a lot. Like we're a lot less complicated. But the big trick that we're doing to make things reviewable and make things understandable is that we are modeling our code on the specs. So if something is called a foobar in the spec, we make sure to call it a foobar in our code. Like we don't invent our own names and ways of doing things. Like we just take what's in the spec and we try to do it literally what it says. Okay. And then we even go a step further and we take the text in the spec, we put it as a comment in the code so that you can like cross reference. And, you know, there was a lot of pushback against this when we first started doing it because people felt like, well, this is a lot of work, a lot of extra work. And it made the code look real bloated, people felt in the beginning. But it's proven to be super valuable because now it's really easy to orient yourself. Like if you have the spec and the code side by side, you can find exactly what's going on very easily because they look the same. And somebody who's never worked on our code base, but they can read a spec, they can pretty quickly figure out what needs to change to fix something. How does this behave for specs in different versions? Because usually you don't make changes to an existing spec, you release an update. So like you don't, I don't have a concrete version, but you might not have CSS nesting version two. Now you have version 2.1. Yeah. So this is something that's a little bit annoying or perhaps one of the most annoying meta things about the web is that it's all like living specifications. Oh, okay. Okay. This is really counterintuitive, but if you want to build a browser, what you should be doing is looking at just the latest editor's draft of any spec. That's what I thought. Yeah. Because those are actually the closest to what browsers do. Okay. You might think that, hey, I should look at the latest published version of the spec, but no, that's not what you want to do. It's strange. I thought this differentiation was always so arbitrary. Okay. Now I see what you're saying. Yes. Yes. Yeah. So you have to go by the drafts. And because of the drafts, they're drafts, right? Then they're living documents. They might change from day to day. And they do. And we try to keep up with the changes. Sometimes they make sweeping large changes to like refactor giant parts of the code base. We've had a couple of those since we started where some, you know, ultimately benevolent spec editor thought, hey, wouldn't it be great if this worked in this other way in the spec? And sort of on the bottom of their list of concerns was how are the ladybird people going to feel about this? Which is fair, you know. But it has meant on occasion that we had to do like excruciating work to reorganize our code base to fit new concepts. But I think we're better off for it. And we've actually received a lot of kind words from spec people who say that it's really nice. Sometimes they can just go look at our code base if they're wondering like, hey, how would this thing look in practice? They can go and look at our code base like, ah, this is how it looks in practice. Because we've implemented stuff that they're doing. And oftentimes recently we end up being the first to implement new stuff in the spec. Sometimes that has been a bit of a bad thing because we end up being guinea pigs. Because the specs are written in English. And, you know, if you have a typed programming language, it tends to be a little stricter than just English. Like, hey, you said that this thing can never be null. But when I write it out in code, I'm putting null in it. Yep. What do I do? So we end up finding a lot of issues like that because there's no type checker in English. And sometimes we feel like we are the type checker of the spec. But it's been healthy so far. And we're also learning like we don't have to be so eager to try to catch up on like every spec change. We can like let them bake for a little while. Let other people discover some of the basic issues. In particular, that kind of bit us with... So JavaScript added this thing called Temporal. Uh-huh. All this like time and date manipulation stuff. Temporal, which, you know, was long overdue. Yes. Because JavaScript never had a good way to work with timestamps. I'm sure you're aware as a user of the language. I've run it once or twice. Max. Right. Max. Sure. And Temporal like has been around for a while. And we eagerly implemented an earlier version of it, which was like a ton of code. Like I think at one point Temporal was the same amount of code as the entire rest of our JavaScript engine. And then we were like the first people to implement that version of the early version of the spec. And then we were like super happy with it because we had Temporal support. And then right after somebody else tried implementing it, I think maybe it was Mozilla, they were like, we don't really like this spec for ABC reasons, right? Like let's make changes to the spec. And then we just had to rewrite our whole thing. So we probably shouldn't have been so eager to just implement this early stage specification. Lessons to learn. Yeah, I bet. But the thing that is maybe not entirely transparent to some people, and I just also just know this because I talked to Daniel Ehrenberg from the TC39, which Temporal, as far as I know, is a TC39 proposal. Right. Not all those specs are coming from the same folks. Sure. Like the TC39 has influence on JavaScript. The WICG, whatever this stands for, has influence on the JavaScript. CSS is a completely different specification. How do you keep up with all that? It's a good question. Yeah. We just kind of, I don't know, I'm so used to it because I've lived in this world for so long that I just take it for granted. Like, oh, the specs, they just come. They just come out. Okay. No, more seriously, like, we monitor the different specs. So we have, we try to have our engineers be sort of floating and become experts at multiple parts of the browser because we don't have the money to hire an expert at every line of code. Yeah. Like some, like some of our competitors, but we have, we have people whose like main interest is JavaScript. So they follow the JavaScript specification. We have people whose main interest is CSS and so on. And I, but, but it's very true what you say. It's totally different people with totally different ways of working. And of course the specs end up looking and feeling very different as a result of just being from totally different people. The JavaScript or ECMAScript specification is wonderful and extremely implementable with one major exception, which is date parsing. But I don't have to complain about that in every podcast I go on. But, but, but you should know that the specification only says you have to support ISO 8601 dates and then the rest is up to your implementation. And then of course, every implementation supports a truckload of other date formats. Yes. And then the web relies on those, which is fun for us because nobody says what you're supposed to do with these. Anyway, outside of date parsing, JavaScript is a beautiful specification and like with just the right level of detail that you can implement very easily, very straightforward to implement. And then HTML and the DOM and these specifications, slightly fuzzier, but still, you know, like they're written in sort of an imperative style, like an imperative programming language where like first you do this, then you do that. Very implementable. So, but CSS is not like this. Maybe you've seen, there's this picture where it's like how to draw an owl. And then. Yes. In the first, first slide, there's like three circles. And then in the second slide, there's like an owl and it's like you're just supposed to go from first to the second there. Yes. I'm not doing it justice by trying to explain it, but you know what I mean. Yes. Just draw the freaking owl. CSS feels very much like that. That is, that is so, again, I read the nesting specification and it's such an accurate description. I never thought about it in this way. But, but if you read one specification, you're like, yes, 100%. That's hilarious. Yeah. So you end up feeling like that a lot of the time that you're just like staring at, you're looking at another browser with a perfectly rendered owl and you're just looking at your own browser with the circles in the wrong place. And you're like, what the hell? How am I supposed to go from this to that? Yeah. Yeah. So I guess the nice way of saying it is the CSS is very declarative in its style. Yes. So the specs describe what should happen, and they leave it to you to figure out how it happens. And I think I've spoken to a bunch of spec people, and my understanding is that it's just like sort of a function or a consequence of the people who work on those types of spec. They're more like designer people, people with more visual ways of thinking, and so they're not these programmer types that just do everything in algorithmic steps, and it makes sense. But, yeah, it's always interesting. So I mentioned that we try to follow the specifications and making our code look like the specifications, and CSS is where we break that rule the most, I think, just because there isn't always like a step-by-step instruction for how to do something. Okay. Genuine question, and I can speak from my experience. I never really invested time learning CSS. It's something that you pick up to a somewhat okayish level that you can build applications somewhat on the go, and those are the same kind of people that are bitching about CSS. It doesn't make sense, and you do hacks like debugging with like a red border or something like that. Do you think your work on a browser made you better with CSS, or is it more like that you now see all the nifty details and you're like kind of getting into analysis paralysis? Probably the latter. Yeah. Like it's always interesting to me that when people think that just because I work on browsers, I know how to make web content. I think this is a reasonable assumption. Yeah. And, you know, I like to say that I have written, you know, millions of lines of JavaScript and HTML and CSS over the years, but it was all spread out over like these little 10-line files. So, yeah, that's kind of very common, I think, among browser people. Not many of us actually have much experience building like real big web things. I don't think this is just unique to browser people because I've heard the same feedback from framework developers that they're not actually using their frameworks because they're building the framework. So they're relying on feedback from the community. We at JetBrains to some extent have the same, like in WebStorm. WebStorm is written in Kotlin, not in JavaScript. So we're kind of relying on feedback from our users. Makes sense. But, like, it's not the most intuitive thing. No. But I guess, you know, to defend CSS a little bit, I think I see why it confuses people because it is very complex. Yes. And it has a large number of systems that interact and people keep adding new systems to it and they keep adding new low-level primitives that bypass some of the systems that have been layered on top of each other, which challenges you to update your mental model every year. But once you've implemented it or implemented, like, parts of it, you start to sort of see the matrix where, like, oh, well, this is what a block formatting context is and that's why the float works the way that it does because it always, like, plops over to the edge of the containing block and blah, blah, blah. Like, you start to see all these things. If you're just a web developer and you're just, like, trying to make the thing go where you want it to go and you're just, like, hammering different hacks into your CSS and putting red borders on things, it's frustrating. I get it. CSS is probably, like, on my top ten list of things I should spend more time on because it's, like, the most frustrating thing and probably one of the things that I spent the most time with just because I'm not good with it. So, like, if I'm, to be honest with myself, I should really just sit down and open my textbook, basically. Sure. But I also think, like, CSS has evolved dramatically and somebody who gets started with CSS today should learn, you know, like, how to use the grid layout system because it's incredibly powerful and it just gives you all these tools that you didn't have in the earlier ones, but we still have to support the earlier ones because there's a billion web pages that use them. But, yeah, it's tricky with stuff like this. It's a lot like going back to emulators again. Like, it's like you have to support all these things that the machine is supposed to be able to do because somebody is going to come along and want to play Donkey Kong even though, you know, we have Breath of the Wild or whatever. Donkey Kong has to keep working. So, yeah, that's the glory of building a browser is that no matter what you do, you're stuck with these, like, 40-year-old APIs that you have to keep supporting and you try to do it in the least painful way possible. But I think there is, just to say something that's kind of nice for us compared to other browsers, is that other browsers were there when, you know, 40, 30 years ago, let's say, when all of these, like, early display techniques were added to the web and, like, HTML is in its infancy. CSS was invented. And they have, like, a lot of ways of thinking from back then sort of encoded in their code bases. That's not necessarily the best way to model a lot of this stuff, but they're kind of, they still have it. And in particular, at least, so I worked on Safari for many years and I know intimately that there's a lot of optimizations in Safari for old-style stuff that nobody does anymore. But Safari wanted to be fast at it 20 years ago, so we did tricks. And it's really easy to just accumulate so many of those tricks over the years and get really thick and bloated because of it. So it is nice for us that we're, like, starting fresh. And then, you know, it's not like we're perfect. We're also adding tricks. So hopefully we'll be able to realize when some trick becomes outdated. We'll see. I still have a million of questions, but one thing that I'm probably the most curious about is how often did you have to justify not writing it in Rust? Rust? Oh. It comes up every now and then. I know Rust has a lot of really excited fans, but I will say, like, in the last year, I feel like that community has calmed down a lot. I don't know what happened. Maybe a new language came out or something. Well, I still get this question. Probably, like, still a good amount. You're probably right. I did calm down a little bit, but once a month, I probably still get that question somewhere. Yeah, yeah. Once a month for sure. But it used to be, like, every two days. Yeah, fair. I feel like at least two, three years ago. Maybe they just grew older because I think a lot of them were pretty young. The thing that bothers me with that is that the people that ask for it don't even use the language. So it's like, they just watch the arbitrary benefit that, yes, you use Rust, so automatically everything is faster, that there's, like, a whole cascade of implications with that seems to be, like, completely out of the conversation. Yes, Rust is fast. Give you that. Cool, good for you. But the five developers out there that really write production-grade Rust applications, they're kind of hard to get. Yeah. I mean, there's a lot of benefits to that. We do want to have more safety in our code, but it's sort of a, there's a big practical problem to it, which is we have a large code base that grew organically, and unfortunately, none of the safe compiled languages offer a particularly attractive sort of on-ramp for incremental adoption in existing large projects. It's been my impression, to be honest, that the Rust community kind of just, like, blows their nose at other languages a little bit. Yeah, I can see that. And they just say, like, well, you should have done it in Rust from the beginning. Like, okay, very constructive. But, you know, I expect that to change, because if you want real projects to adopt new technologies, you have to give them an incremental path to adoption. If we were starting today, we would use a different language. Because we're using C++ at the moment. This would not be the first choice today. But we started seven years ago, so it is what it is. The production language that offers the most reasonable sounding, at least, on-ramp, or incremental on-ramp for adoption is Swift. So we're trying to make ourselves compatible with Swift. Okay. But we have yet not been super successful. We've been working with the Swift team, getting them to fix stuff to make it smoother for us. But Swift is not perfect for us either. Like, there is no perfect language for us, really, because we would, in my opinion, what we would really like to have is a garbage collector. Yeah. And then maybe, since you were affiliated with JetBrains, you will say, hey, have you heard of Kotlin? It was on the tip of my tongue, but I was like, ah. Yeah. I think it looks attractive, for sure. But I don't know that it's incrementally adoptable for a C++ project. I couldn't tell you. I know we have a lot of, like, Java next to Kotlin in the IntelliJ code base. Yeah. So from, like, that starting point, it is very incrementally adoptable. For sure. I don't know about the details coming from C++. Yeah. Yeah. But, like, you know, if we were starting today, for sure, I would probably have liked to use something more like Kotlin. Yeah. just because doing garbage collection yourself is just no fun. Yeah, it doesn't sound fun. It's real nice when somebody else does it for you. You don't have to think about it. Yeah. But I guess your question was, like, how often do you have to justify not using Rust? It used to be several times a week. Now, we rarely hear from them. Well, that's good. Yeah. I think they grew up a little bit, and they realized that not everybody wants to hear that question all the time. Lady Bird is a truly open source project. Do you feel that you have to justify some of those decisions, like, particular architecture decisions often, or is it so low level that a lot of people don't care about that level of details? I think we frequently feel that we have to justify it to ourselves. Interesting. Okay. Because ultimately, we're the ones who have to work with this thing all day, every day. And so... That sounds rather healthy, though, to me. Yeah. And we're not entirely happy with some of the architectural decisions that we have. But even though we're more than... You know, we're less than 10 times the size of something like Safari, we're still a big, heavy code base. So it takes time to affect change. One major change that we're doing right now is that... This is going to sound so unsexy, but we're transitioning to UTF-16 as our main string format, which... Which is like... I'm so hooked right now. I'm so hooked. Yeah. Which is, you know, not usually what people do in 2025. People are pretty hyped on this UTF-8 thing, but the sad fact is that the web is spec'd in UTF-16. JavaScript is a UTF-16 native language. The web platform is UTF-16. And we've been using UTF-8 as our string format the whole time. And we always thought, like, hey, this is awesome. We're a UTF-8 native. Like, UTF-8 is so cool. It's the future. But in practice, what it really means is that we're just, like, converting back and forth between UTF-8 and UTF-16 in a million places and, like, regularly forgetting to account for, like, hey, this is an offset to a byte number in a UTF-8 sequence, but the API expects a UTF-16 offset. And it screws everything up. And just, like, a lot of that shit. And it's, like, it's so uninteresting, but it's an architectural change that we're feeling pretty good about. Yeah. And, I don't know. There are a lot of these things that we're trying to get right. And I feel like choice of language or, yeah, like, really, programming language is another thing that we would like to change over time. But it's just such a big change to make, you know. We're looking for that incremental path. I don't know if it's going to pan out, you know. Yeah. I think if you look at the industry, if you look at the world, there's, like, how many billions of lines of production C++ is it out there at all these companies that have so much money and so much incentive to make it better? Like, it feels like some kind of efficient market would figure out a solution to this. I don't know why it's taking so long. So, I guess, yeah, we're just, I'm hoping also that some kind of great solution will come along. there is an interesting solution happening. So, an old coworker of mine from Apple is developing a thing called Fill C, which is sort of a new compiler for C and C++ that compiles to memory-safe executables. And it's not a dialect of the language. It's like, it's just a new compiler that's built or based on LLVM. So, based on like the production compiler that everybody uses, but it adds all these mechanisms to make it entirely memory-safe. And it is, in fact, safer than Rust because there is no unsafe. But it has a performance penalty that my friend Phil is trying to make as small as possible. But maybe that becomes the solution to all this stuff. I don't know. Languages are a huge topic and hard to know where to go with it. What is a thing that you as browser developer would like people to understand better about browsers? Because I look at it from a very much 10,000 feet view, like, oh, I want to use WebRTC, which I don't even recognize the tail of implications that might have from video encoding and those things. So I'm very curious on your perspective on those things. The number one thing I would want people to understand about browsers is that browsers are just code that you can open up on your machine and hack on and change. You can figure out how it works. You can put print statements in it and see what comes out. You can debug it, trace your way through CSS layout or JavaScript execution. They're just programs that your computer runs. I think browsers have become a little bit mythologized as these insanely complicated things and then people don't even look under the hood anymore. Yeah, I can see that. And I think more people should and I think our project in particular is a very easy space to do that. If anybody's curious about how browsers work internally, we have a very small one that is very hackable. Just close to a million lines of code. Yes. Which is a lot less than it could be. A nice good night story just before bedtime. Yes. No, but I really think that if you work with the web, then poking into a browser is interesting. And seeing that if all of this stuff that you interact with in your code in JavaScript is just other code that does kind of obvious looking things once you look at it for a bit. Yeah. And I guess I would also say that browsers are just made by people who you can talk to. It's very easy to talk to us because we're very casual. people. We're not very corporate. We don't have a huge corporate structure. But you can also go and talk to Google people. You can go talk to Mozilla people, Apple people working on their browsers. If something seems weird in a browser or you have an idea for how something could be better in the platform, you can go and talk to the people who make the spec. I think a lot of people just accept the browser and the web platform as something that just exists and you just have to deal with it as it sits there. But you can totally go and affect it. You can influence how it changes and how it develops because at the core of it is just a bunch of humans trying to make a cool platform. Yeah, I guess that's what I would love people to know. I love that. I do have to ask because there's now more and more this trend. I mean, you mentioned before with AI sidebar in the Chrome. Perplexity added their AI browser. And there are also theories going around that browsers will eventually fade for the sake of LLMs. What is your stance on those things? I don't know. I think no one does. Yeah, that's fair. Nobody knows. But I guess I want to lead with that, though, because I don't want to sit here and sound like, oh, I know exactly what's going to happen. I think, to me personally, it's the idea that AI will go and browse the web for me is completely unexciting because I love the web. I love browsing and clicking around and seeing all the different things that people do with the technology. I think it's fun. AI is awesome. I love using these deep research functionality of ChatGPT or Grok and these different ones where they go and they fetch stuff and summarize for you. I think that's awesome. But I still want to browse the web. I imagine that there are people who are still like that as well. Other people still want to browse the web. If you want to buy a new car, you want to look at cars. You don't want to have a summary of all the features and price points and stuff. You want to look at the beautiful brochure material. To put that in a different context, if we're talking about a 10-15 years time horizon, do you think it's kind of like people still buy vinyl for the experience more? Or do you think it's really like... Do you see what I'm saying? Yeah, okay. I get it. So I think the interaction model will change because the keyboard mouse interface today is possibly the most efficient in my opinion. Other people would say that well, touchscreen is more efficient. Something more efficient will probably come along. within the next 15 years. And we will also see increasingly powerful functionality with AI allowing you to search the web more efficiently, interact with pages in new ways, and blah, blah, blah. I don't know what's coming. I know stuff is coming for sure, but we, at least as Ladybird, we're just here to implement the standards and build sort of the bare bones functionality that people need to browse the web with it. I think it seems very likely to me that some kind of AI related stuff is going to start creeping into web standards eventually. I think isn't, what is it, Edge already having like an AI API? Yeah, I think they have like window.ai or something like that is like a thing. But I don't think it's standardized yet. Not that I know of. And you would probably know better anyway. Yeah, but as I said, there are all these specifications I have never even seen yet. Some kind of conspiracy where people just keep making them without telling anyone. He has like a 300-page document. Go have fun with it. Yeah, it was there the whole time. You're crazy. Give slight gaslight vibes. Right. Slight. But yeah, I do feel like that sometimes a little bit. I bet. I bet. No, but I think it's hard to predict. What do you think? I was just saying, I think the interaction model is 100% going to change. I think it's going to be, again, purely theoretical, but I think a lot of mouse-keyboard interaction is going away for probably more voice and also less directed, where it's more like conversational instead of like, I want X. It's more like, well, what do you think? Like, right? Yeah. How this completely impacts the web, I have no idea. I can see, I can't see a future where websites go away for MCP, LLM interactions, something like that. if I think about PayPal, for instance, I don't see the need to open an app or something if I have an MCP that could be like, hey, transfer X amount of money to Andreas. Whereas, on the other hand, though, sometimes you want this experience, so I think it's also going to be like a business to business decision. I completely agree with you. It's very hard to predict. I see a couple things where it's like, I could see it swing this way. I mean, if we look at HoloLens, for instance, like, mixed reality never really become a big thing. So it might also just be like, MCP is a big hype right now, and it turns out to be great for 5% of the use cases, and that's what they're going to be used for. So I think things are about to change. I think we can all agree on that. How it actually changed, and what the concrete impact is, I think. I do call massive bullshit on when people say, particularly Big Corp, where they're like, oh, 60% of the code in our company is written by AI. I call massive bullshit on that. Yeah, or what was it, Klarna, or some company like that, said they've frozen all hiring? It's going to be all AI from now on? I think one company had their complete support replaced by AI, and then within a month or two hired them back. I'm like, no one saw that coming. No one. Right. I like it as a tool to make my workflow more efficient. That's, I think, huge, huge. And for that sake, I do think if you had a project that you maybe needed to staff two developers on, there might be a way to do this with one developer in the future. I don't see a future, at least with the way things are right now, where it's like a complete one-to-one replacement. I just, it's too off, it's too arbitrary sometimes. I literally had an interaction with Claude where I shared a blog post and was like, hey, can you give me more information on that? It was like a note package in like a certain version. And Claude was like, there are no information about this package on the web. And I'm like, I literally sent you the blog post. It's attached here. What are you saying? So it's like interactions like that where I'm getting very humble and be like, okay, we still have a job for a foreseeable future. Yeah. I remember Steve Jobs used to say that the PC was like a bicycle for the mind. And I feel like it's a bit like that again. Yeah. It just allows you to extend yourself in new directions. And with programming, at least I found that it makes tasks approachable that previously I would have said like, oh, that's too much like busy work. Too much like, repetitive typing that's not really automatable. And AI can make that trivial, which I love. Yeah. But it's a tricky space. You know, like you see what happened with cryptocurrency. You know, like now that the dust has settled and we can sort of see what the lasting use cases are. Now, that's not to say that, oh, I think that those are comparable technologies. But like, I think we're in similar levels of hype right now that we once saw the currency. I had an episode on AI on this podcast and I draw the same conclusion. I think AI has much more application scenarios than crypto and Web3 has. But the hype is very comparable right now. Like the evaluations that are coming in right now for AI startups are just insane. Oh, yeah. And for sure, like 10% of them might survive for a couple of years. I think 10% is already very generous. Yeah, probably. Particularly if I look at the cost associated with AI, I'm like, cool. Yep. We have a complete new ban of salary popping up out of nowhere. That is unheard of before. So I, yeah. Interesting times. What is that thing they say? May you live in interesting times? I feel like we are doing that. For sure. I, yeah. Before we wrap things up slowly, I want to circle back a little bit towards Lady Bird. And I think the, you shared, I mean, it's an open source project, so you're, I don't think you could be any more transparent, but you also shared your roadmap, what your timeline is. Because the last thing, well, the moment I heard about Lady Bird, I was like, oh, I should install this thing. And then it was like, I saw the GitHub page and was like, well, here's how you compile it from scratch. And I was like, yeah, I'm not going to do this. Yeah. I think if I saw that correctly, your goal for 2026 is to have an installable version for Mac and Linux. Yeah. So in 26, we want to do an alpha version for Mac and Linux. That's what our full-time engineering staff is currently working towards. And that will be an alpha version. So it's like going to have stability issues, but it will be something that you can install and then complain that your local pizza place is not rendering correctly, which is exactly what we want to happen. We want to find out all the sites that don't work. And then in 2027, we're going to do a beta version, which essentially is like more of the same, but aiming for a higher degree of stability and a broader user base, perhaps with slightly lower tolerance for bullshit on our part. And then in 28, we want to do a first 1.0 release. And, you know, depending on who you ask, this is either an insanely slow or an insanely fast timeline. People who have worked on browsers, they tend to say, what are you doing? Like you need at least five more years. But I think we have to set some kind of timeline. And I think this is doable. And we are finding that at least so far, we've been able to make great progress, good velocity. And we'll just see what kind of shape we are in next year when we put out the alpha and we start getting like way more sort of reports of problems and see what that stream of incoming bugs looks like and adapt from there. but I don't know. This hasn't really been done before. So we're just going to have to see how it works. I think this is one of the things where if you don't set a timeline, you very easily tend to die in beauty where it's like there will always be something to do. There will always be something not working or always something that could work better. Yeah. So I think setting a timeline that might be realistic, maybe a little bit on the edge of optimistic, I think is healthy for a project like this. Yeah. That was my feeling about this whole thing that we have to set a timeline that's aggressive but possible or in the realm of possible. But so you mentioned that like if you go to our GitHub, it says right now, here's how to compile it. It's like a little bit abrasive on purpose. so that because right now we're not equipped to handle the like barrage of bug reports that would come if we had an installable binary because, you know, most of the web will break in some way. But we're hoping that, you know, by this time next year or at some point next year, 2026 is a very wide window for alpha. But at some point next year, we'll put out something installable that will work reasonably well with the major popular websites. And then the long tail of smaller websites is going to be a big challenge that we then take on. Do you have like a checklist more or less? Like those are the things that are left to do before we can do an alpha release or how does that road to alpha look like? So we have a big document that we're working on with all the full-time people. Like here's like the giant list of tasks that I'm responsible for for the alpha. But we want to formalize that a little bit and make it more of a public document that we're working towards. It just needs to be cleaned up and edited. And I guess it's like it's a little bit scary to overcommit to features because we don't always anticipate correctly how much work something will take. I bet. As every developer. Yeah, as every developer. It's not a unique problem. No, we've just been a little bit apprehensive about making this process more public. But really we should just make it more public. There's no reason not to. It's more like just a little bit spooky. Yeah. It's a nice comfy safety blanket. Yeah, exactly. No, but so what we really have is like a list of features that we want to work in the browser and a list of websites that we want to work. Okay. And like assignees for all of these. But ultimately what we really want to do is target like the major websites that people use, the boring ones you know like Facebook, Twitter, Instagram, whatever. YouTube is a big scary one. Oh, I bet. Because we would love to do YouTube but at the same time I don't know if it's realistic that we can have it performing well. That depends on a lot of factors. And then there are also some really popular but things with other complications like Netflix because they would require some kind of DRM in order to play. which is like a whole Pandora's box in itself that we haven't confronted yet. But all in due time. Just have to go one step every day. I have one more question actually. Is there like do you have like a target group defined for Ladybird? Because like it does influence the sites that you might pick as like a startup or for a start and for an alpha I personally would assume that the most likely people that are attracted to something like Ladybird are other developers. Yeah. For sure. Yeah. So like the you know the gold star sites in the beginning or whatever you call them would be like GitHub, GitLab. Okay. Like those kind of things because those are the people who are going to be testing it. Yeah. Okay. And then you know the target audience gets progressively less nerdy as 1.0 approaches. But I don't know if you remember when Firefox came out back in the day. Way before my time. Way before your time. I'm not that old. Got it. Yeah. Okay. Well I'm that old and I remember when it came out and it was like this spontaneous movement that formed that like you were a nerd and you were excited about Firefox so you try to get the less nerdy people in your life to try it out because it was just something you got excited about. Yeah. Yeah. Okay. And I imagine that that kind of thing can happen again if you just give nerds something to be excited about. Yeah. You need to find the right hit the right spot. Yeah. I don't know. It was a nice little cultural moment. Maybe the cultural moment is totally gone. Nobody's going to care about a browser in that same way again. Or maybe they will. I don't know. But yeah. I would love to see that kind of thing happen again. I think you know like right now it does feel that there's a spontaneous surge of excitement around Linux happening recently. Fair. which almost feels like it came out of nowhere. But like people are just hyped on Linux and you see what's his name DHH and PewDiePie and these people with a large audience making like being really excited about Linux. And it's fun to see that and makes you wonder what else people might get excited about. Well I truly wish you nothing but success with this whatever success means to you because I think that with like a non-profit involved success looks very different than a startup with defined success. I think what you're doing is wonderful as a developer this is everybody's dream in a way like it's truly open source. It's an embodiment of that idea. So thank you. Thank you very much for doing this. Sure. Yeah and I will say success for us really comes down to we make a browser and some people love it and they use it and we get to keep making it and everybody's happy. That sounds awesome to be so far. fun. Thank you so much for coming on this. I really appreciate you. Thank you. Yeah sure. Thank you for having me. Anytime. When you have the alpha out or something we got to talk again about this. I could talk about all the details for hours. Absolutely and we'll see which ones of your favorite websites don't work. What we can do about it. Awesome. Thank you. See you next time. Bye. Later.