Tech Over Tea - Ladybird Browser Lead Developer | Andreas Kling

Episode Date: March 14, 2025

Today we have one and only Andreas Kling on the podcast the lead developer of Ladybird and formally the SerenityOS project. Right now is the most important time it's even been to get behind a new open source browser and bring it to life.==========Support The Channel==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson==========Guest Links==========Website: https://ladybird.org/Youtube: https://www.youtube.com/@LadybirdBrowserGithub: https://github.com/LadybirdBrowser/ladybird==========Support The Show==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson=========Video Platforms==========🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg=========Audio Release=========🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw==🎵 Anchor: https://anchor.fm/tech-over-tea==========Social Media==========🎤 Discord:https://discord.gg/PkMRVn9🐦 Twitter: https://twitter.com/TechOverTeaShow📷 Instagram: https://www.instagram.com/techovertea/🌐 Mastodon:https://mastodon.social/web/accounts/1093345==========Credits==========🎨 Channel Art:All my art has was created by Supercozmanhttps://twitter.com/Supercozmanhttps://www.instagram.com/supercozman_draws/DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. I'm Azure's host, Broody Robertson. And today we have the developer of something that doesn't get made very often, a independent web browser. There's a couple of them, but most things you see out there are just Chrome. Sometimes they're Firefox, but they're usually Chrome. So welcome to the show. How about you introduce yourself, talk about the project you're doing, and we can go from there. Sure. Well, hello friends.

My name is Andreas Kling. I am the founder and lead developer of the Ladybird browser project. And before that, I was the founder and lead developer of the Serenity OS project. And before that, I was a humble engineer at the Apple computer company. But I've been doing browsers for a very long time. And ever since 2005, I think I made my first browser contribution to K HTML, the KDE browser back in the day, because they added ad block to it and you had to reload the page for new filters to take effect and I thought that was terrible. They should take

effect right away. So that's why I got into browser development. I think it was something like that. Anyway, yes, I've been doing browsers my whole career essentially just bouncing around different companies and now I am building a new browser from scratch. And there's a lot of history to that. Brody, I'll let you decide how deep we go into that. I think before we even go into that, I kind of want to touch on the KHD mail thing, because this is something I like to bring up every so often, because it's a fun little bit of knowledge that most people don't have.

KHD mail is kind of the basis for most of what we have on the web today. WebKit and Blink both stemmed out of that project. I don't think most people even consider that. That's true. Yeah. It started quite a long time ago, I think in 1998 or something like that, KHTML. Yeah, sounds about right. They just wanted an HTML viewer widget for KDE.

And this guy Lars put one together and eventually it just kept growing and growing. And Apple secretly picked it up without telling anybody and used it as the basis for what became Safari and what eventually became Chrome as well. And if you go and look in the code for Safari and Chrome, both of them still have a lot of those old KDE copyrights from like 98, 99. I believe that a lot of the WebKit browsers still have K HTML in the user agent string as well, if I recall correctly? Yes, I believe they do. User agent strings are an interesting thing. And it's like this pain that just never goes away. And we are facing it every day now that

we're building a new browser. Because, you know, contrary to what you should be doing, a lot of websites are checking the user agent string and making decisions based on that. So you just kind of have to put a bunch of crap in there. That's not true. So we are stubbornly right now, not saying keyTML, not saying Apple WebKit, not saying Chrome or anything like that in our user agent string. And it means that we are not allowed on websites like x.com and many others. And I've tried to plead with multiple engineers over there, but they all say that they're

going to look into it and then nothing happens. So I don't know. But it's kind of a losing battle, you know, because even if you could get ahold of somebody at the major websites, there's still like thousands and thousands of websites out there that nobody's maintaining. They're just running in a server in a closet somewhere and they check the user agent and you're just screwed. So, yeah, anyway. For anyone who might not know what a user agent is, what are, just, just, can you briefly go over that and what is it supposed to be used for and what are websites actually doing with it? Right, sorry. Yeah. So a user agent string is, it's sort of a branding that a browser has.

And any website can ask, hey, what is your name, Mr. Browser? And the browser will then say who he is. And it's also included in every outgoing HTTP request. You include, like, hey, I would like your index.html, and my name is Mr. Safari, or whatever. And websites then look at this and they make these annoying decisions like, oh, well, if you are Safari, then surely you want this CSS and this JavaScript because I know they

work in Safari. I tested that 15 years ago. And there's just a lot of that. And so, uh, when we come along and we, we say that, Hey, we are Ladybird. Um, there are a bunch of websites out there that just throw up their hands and they're like, uh, unsupported browser, unsupported browser, or, uh, here's something we made for IE users in the nineties. Maybe you can use that.

made for IE users in the 90s. Maybe you can use that. And it's often hard to tell. Unsupported browser is almost like a best case scenario, because then you know, at least, that they checked the user agent and they decided that it's no good. The worst case scenario is where they just send you something slightly different than what everybody else is getting, but you have no idea that that's happening. We get a lot of that.

Do you happen to have an example of some difference you might see there? Well, it's usually a lot about like, they're trying to work around known bugs in certain browser versions. So they might know, for example, that Safari 13 shipped with this bug in JavaScript iteration that if you're iterating over all of these properties, then something goes wrong. And so they have a version of the code that avoids that feature.

And then they ship that to perhaps specific Safari users or perhaps to everybody that they don't recognize. But it's generally not sort of visual things that differ, but you just get like a slightly different version of the program, like a hacked local version, if that makes sense. It's a very strange problem, actually. Yeah, my understanding of JavaScript, like I haven't done a ton of web dev in a while is especially a lot of the older versions where we had a lot of the, the, the giant web stack we have now to do any sort of basic web development.

Implementations tended to differ of JavaScript between browsers. So you would have these, like, this is sort of the reason why things like jQuery came along to sort of just abstract away a lot of that annoyance, let the library do it. And then the developer can just focus on that because without that, then you have to, you know, this is how we got into the situation where you had sites that only supported IE because Microsoft was so big that they, you know, they were in the situation that Google is in now where if they just want to change the spec, who's going to stop them? Like, they can?

Yeah, that was definitely a thing. And I would even credit JavaScript frameworks as one of the big contributors to why it's relatively easy to build a new browser today. Because if they hadn't come and just sort of flattened the landscape and put an abstraction layer on top of these incompatible engines, we would still be dealing with sort of different behaviors today, perhaps. But it was many things that contributed to it. Like, the specifications improved as well. Like, the standards bodies decided, hey,

we should make the standards reflect what browsers do. And yeah, there was a lot of synergy that happened in the browser industry. And we are now benefiting at the tail end of that, because nowadays, their standards are good. They match what browsers do for the most part. There are all these frameworks that abstract away most of the slightly different idiosyncrasies

of different browsers. And what you're left with is just like a handful of boutique problems, such as people checking the user agent string. So it's better than it's ever been, but it's still annoying. And at the end of this whole thing, what's going to happen, whether we like it or not, is that we're going to have to start saying, we are Ladybird, or are we Chromium? Perhaps a little bit of WebKit, maybe K HTML. Don't worry about it. Just send us something.

Right, right. Because that's what everybody ends up having to do. Yeah. You have a lot of these browsers that are, especially the ones that are based on another toolkit. And they just say, well, like, you know, I might, I'm the Zen browser. Well, no, no, I'm actually Firefox.

You don't need to know what Zen is. Just send me whatever Firefox is. Or I think Brave just says it's Chromium I don't think it actually has Brave in the user agent string I might be mistaken there, but a lot of the, I know Vivaldi for example just says I'm just Chromium Just send me Chromium like don't worry about anything else because yeah as you said you start running to these these just oddities that frankly you don't need to deal with and to these, these just oddities that frankly you don't need to deal with.

And it would be nice if we didn't have this user agent string here. And it was just like a thing that could be done away with, but it, yeah. In a way, you know, building a browser is almost like building a bootleg video game console. Um, that, uh, there are all these games out there and they are just made for sort of the big consoles, right? And they may be maybe relying on something that isn't documented in the official PlayStation documentation or whatever. But because the Sony PlayStation does a certain thing, then it's just expected that we do that as well. So, I don't know, I like to draw comparisons between game consoles and browsers,

because it's very similar as it turns out. And it might just be because I've built a lot of emulators and it's just logical to draw the comparison. But yeah, browsers are big emulators and the web is just a big ROM collection. I've never heard anyone describe it like that before. It is kind of my mental model and it's also very, the workflow is very similar because when you're building a game console, you have some game that you want to play and then you're kind of just hacking on your emulator

until you can see something happening in that game. You're not worried about, you know, like Donkey Kong racing or whatever. You're just trying to get Mario 64 to work. And so you're sort of building whatever's necessary for that specific thing. And then you end up with something that's like capable of doing a lot of things that make that one thing work really well. But then somebody comes along and they throw a different game into it and turns out, oh, we have to do all these other things.

Um, and this is almost entirely how we've built Ladybird so far is that people just try their own favorite websites and then decide that, oh, I'm going to make this work better. Or well, at least that's how we used to build it until we became a bit more test driven a year ago or so. I do definitely want to get into that, but I think we should get into more of just like the foundational of what the browser is first. We can come back to that a bit later.

So I guess the best place to start is what is the ladybird browser? Like that. Maybe that's a very broad question to go with. I think, let you know what, let's start with why is it not based on any existing engine? Why, why are you, sorry, I try different words sometimes. Why are you building an engine from scratch? Why are you not, you know, doing what everybody else does and using something that's already out there?

So the reason for that has sort of evolved over time. When we started on it, we just wanted a rich text display widget for Serenity OS. I wanted to be able to have bold and italic fonts in different sizes on the same line. So it was very humble in the beginning. But being an old browser developer, it just sort of predictably spiraled into if I implemented this little piece of HTML, I might as well also add CSS and I might add these other features and why don't I put a JavaScript engine in it? And in the beginning, it was just motivated by that, like just building a rich text widget for Serenity OS.

And I guess it was maybe six months into it or something like that where it started, I started realizing that we should probably just call this a browser at this point because that's what it's evolving into. And then it became more about like, let's see how far we can go, how far we can take it before we hit some kind of, I don't know, like insurmountable friction. And that day just never came and we just kept pushing and improving it.

And eventually what happened was that it was originally part of the Serenity OS project. So Serenity OS is a mono repo with like all kinds of applications and a kernel and a user land and everything developed in one Git repository. And what happened was we started building this browser and eventually it was most of the daily development in the repo was just browser related and it sort of overshadowed the rest of the operating system in terms of activity. I decided that it would be better to fork the project at that point so that people who wanted to work on an operating system, do kernel stuff, they could live in peace in

the Serenity repo and they wouldn't have to worry about people asking them to run all the browser tests whenever they were making changes and vice versa. You know, like people working on CSS, they don't necessarily want to run device driver tests in the kernel if they're making changes. So it grew out of that. And once we forked, then we started changing a little, changing the rules, I guess, that were sort of established for Serenity OS where the rules in Serenity OS were we build everything from scratch ourselves, everything at home, no matter what. And when Ladybird was free to be its own thing, we decided that, you know,

we are just going to incorporate some popular open source libraries and not worry so much about implementing stuff like cryptography, compression, video codecs, stuff like that. Stuff that's like far outside of our expertise that we were doing for fun, but not doing the best job of optimizing. Right. And stuff, yeah, exactly. Stuff that somebody else probably has written much better than you will. So just do their stuff. much better than you will. So just do their stuff. Exactly, exactly. And so it just sort of organically evolved

towards this point where, okay, well now it's a, it's like a fledgling open source browser that leans on some of the best parts of the open source ecosystem. And what do we do now? Well, why don't we try to push this thing all the way and build a browser people could actually use instead of just toying around with it? So that sort of became a new motivation. Like, okay, let's build a real browser. And then because of things happening outside of our little

microcosm, the browser industry, uh, has been sort of consolidating on, on Chromium, as you mentioned, um, in recent years, like people keep abandoning their browser engines and saying, Hey, we can just build on top of Chromium. Well, it's except for all of the game consoles, which are web kit, which Well, it's clearly except for all of the game consoles, which are webkit, which leads to some there's a lot of there's a lot of console hacking exploits because of old versions of webkit they use. True, true. Pros and cons to that.

Well, you've used a very outdated library and you don't update it. People are going to discover what problems you have with it. Indeed, indeed. But with the world around us, sadly giving up on browser engines, this seemed like, hey, we are in a better position than anybody else to introduce a new browser engine and add some life to this sort of depressing field. And that became part of our motivation as well. Like, okay, well, let's just build a new browser engine and put it out there and find a place for it. And then I met Chris Wanstoth in 2023,

I met Chris Wanstoth in 2023, GitHub co-founder. And he was really into the idea of taking this thing all the way and building a new browser independent as well. And we talked about like, what would be sort of the motivation and the narrative of such a thing. And something that we both agreed on was that it should be independent and not reliant on sort of handouts from the advertising industry. Because I think that's where the browser industry has gone wrong.

And yeah. And in 2023, that was still a little bit of a sort of inside baseball, because the big revelations about how much money Google is giving to browsers, they were not public yet, but it was about to come out. But that was sort of what we initially connected about Chris and I, like what if we did something and tried to just find a new way to build and finance a browser? And now we've integrated that into our motivation. And it's more than just like,

we don't want to take money from Google. It's also, how do we build something that can be maintained without that level of funding? Because a lot of people ask us, why don't you just fork an existing browser, and then you would be starting in a great place, and you can just work from there? And the problem is that the existing browsers

are built and maintained by thousands of people, essentially. And we don't have the budget for that. You know, we have a lot of lovely sponsors, but we have nowhere near enough to hire, you know, like 200 people to maintain and continue to develop one of the existing engines. So we are trying to build a new engine that can actually be maintained on a small budget as well. And what that looks like in practical terms is that it just has to be a fraction of the size.

So I think somebody told me the other day that WebKit is around 10 million lines of code. And we are a couple of hundred thousand lines of code. Okay. Now, I don't... If you include libraries, then we are bigger, of course. But I don't think we've broken the one million lines mark yet. And we eventually will if we want to support all the popular web features but there should be no need to to go to 10 million. Right. And this is kind of our

most important specialization from my perspective, from a technical perspective, is how do we build this thing in a way that we can sustain development into the future without becoming dependent on somebody feeding us, you know, hundred million dollars every year. And that's the actually scary part that nobody's really done, I think. I do want to get more into that, but I want to back up just a little bit to when you're talking about building something from scratch. With Serenity, why was it that you guys were doing everything in-house? Is it just because you can?

Or is there some other reason for it? It was just to have fun, really. So I guess most people who listen to your show probably are familiar with Serenity OS and the backstory. Maybe they haven't looked into it super deeply. I'm sure they've at least heard about the project at least a couple times. Yeah, so the backstory quick version

is that in 2018, I had been living with a severe drug problem, and I got into a rehab program. And, um, after completing that, um, I found myself with just a lot of time. Um, because I was used to filling my, my days with drugs and debauchery. And, uh, without that, you have, I don't know, like 16 hours in a day that you're supposed to do something else. And so I just got into, well, I tried a bunch of things. But I got into programming, which I've done my whole life.

And I needed some big project to fill up all that time. And I built a bunch of things and then eventually realized I had built a small kernel What was it like a kernel a file system fire windowing system and something else and I realized that hey if I just smush these together, it's basically a GUI operating system And then I just need to keep working on it and so I did that and that I decided to call it Serenity OS because in rehab we used the Serenity Prayer to sort of align ourselves with the idea that That we have to

Accept some things in life that we can't change and we have to Work on on the things that are under our control And I want it to be forever associated with that idea. So I named it that. And that has worked out beautifully because people refer to me all over the world as the Serenity Guy. So plan worked beautifully. Perfect title.

I like that. So now I can't run away from that. I'm always reminded that it's working out really well. And yeah, the idea was that since I just started working on random stuff and putting it together, I just stayed that way. Whenever somebody wanted to add something, like people came to me because I was on GitHub, they came like, oh, let me add this open source library so we can do this. And I always said, nah, let's just build it ourselves. Like, how hard can

it be? And then more people joined and everybody was encouraged to do everything themselves. And it just went down the rabbit hole of building all kinds of things ourselves. And so that's how we ended up with, you know, like a complete cryptography library that has like all the different algorithms and key exchange and elliptic curves and stuff and graphics libraries, photo editing, stuff like that. It's a lot of fun. This kind of reminds me of the Linus Linux email. I'm doing a free operating system, just a hobby.

Won't be being professional like Gnu. Yeah, yeah, yeah. It was a bit like that, I guess, looking back. It was very humble. Although I think there were some constraints on Serenity OS that Linus didn't have. And so for better or worse, Serenity OS that Linus didn't have. And so, for better or worse, you know, like Serenity hasn't evolved in the same way that Linux did. Because, I guess because of this whole, like, let's build

everything ourselves. Linux ended up, like, leaning heavily on other things, as Richard likes to point out. Right. Richard Buddha. Yeah. Very, yeah. Well, it's kind of funny that you have the idea it was like, oh, a big professional like Gnu, but nowadays Gnu basically doesn't exist without Linux.

The relationship there's kind of flipped. Yeah, very much, very much. But of course, you know, Stalman was more right in the past. Gnu was the big thing. And yeah, we didn't sort of connect with any existing projects. We just did everything ourselves. And so we were a bit of a strange in the open source world because yes, everything is open

source, but we're not actually interacting with the ecosystem at all. Like other than using open source compiler, like GCC or Clang, but we just built everything ourselves. And so yeah, that was a bit unusual. If you decided to build the compiler yourself, I feel like that would have been where you stopped and you wouldn't have ever got to the operating system part. It's possible, yeah.

We did start building a compiler at one point for a new language, not for C++. But I don't work on Serenity OS anymore, so I've sort of left the project in the hands of the remaining maintainers. Because when we forked Ladybird, I realized that I'm just spending all my time working on the browser. And it's not right for me to sit here and say what Serenity OS should do when there's a community of people who love working on it and they have all kinds of ideas that they want to do with it and I don't want to interfere with those ideas too much I guess but that but it's been good I think you know now now everybody gets to

to focus on the things that they want to do. And I check in with the project every now and then. They're still working on stuff, so that's cool. I hope everybody's happy after the split, even though it was a little bit, it's always difficult to divorce, whether in software or in anything else. But I think it worked out. And I completely forgot what your question was. No, no. We'll just...

That's a good question. Something about like... I think we started on building for everything from scratch. That's where we started from. We somehow got here. Right. Oh, yeah, yeah, yeah. Why build from scratch? Right, right, right.

Yeah, so it was just for fun, just to keep myself busy. And then people wanted to join because they saw how much fun I was having. And I said, okay, you can join, but you gotta build everything from scratch. No taking other libraries. And it became like our niche, I guess. And people heard about our project. They're like, wait, there's a project where they're building everything from scratch and I can come there

and build anything from scratch. And so people joined to build like things that they were just curious about how one would build. You know, like sound editing software or like music production stuff. A lot of games, like desktop games, things like that. And yeah, it became like a playground almost for hackers, I think. And so it was just far away from what Linux became. Linux wanted to just be, um, I guess like a cheap, um, alternative to Unix because Linus

felt at the time that, Hey, these Unix workstations at school are great, but I can't afford to get one at home. Right. He said in the Linux 1.0 announcement, it was cheaper to build a Unix kernel than it was to buy a Unix license. Right. Yeah, exactly. So, quite different motivations between the two projects, but initially very scrappy, both of them. And of course also Serenity OS, if you haven't seen it before, it famously has a very year 2000, um, Microsoft look, um, uh, the, the look and feel of the system is extremely inspired by Windows 2000, thereabouts.

Yes, okay, yeah. I'd seen it before, but I couldn't picture it, but no, that's exactly what I would call it. Yeah, and that was also like, I just grew up around using computers around that time. It was a formative experience for me, and I just decided, hey, it's going to look like that. Um, and, um, you know, looking at what windows has become today, I don't know if you use it, but, uh, I haven't used windows in five years. Last time I touched it was windows 10 though. Okay.

Okay. Well, so windows, I'm sure you're aware, famously has a hard time staying consistent with UI. Yeah, that's one way to put it. Yeah. And I'm 99% sure that you can probably find at least one application on a modern Windows install that still looks like it's year 2000.

And one for every year since then. Well, it took some three major leases to replace the control panel. Right? Just that. Yeah. So one of the things with Serenity OS was that I also wanted everything to look consistent.

So for that reason, we didn't port things like GTK or Qt originally at all, and just said, hey, if you want to build a graphical app, just build it in our toolkit so that it will fit in. And it just created this little world that you can go into and disappear for months if you are a programmer who enjoys these kind of things. It turns out a lot of people are and we had a lot of fun with that.

And that was sort of the weird cradle where Ladybird was born in this very, very hacker-ish environment where everybody just builds everything themselves. And it was actually one of the early frictions that we met when forking Ladybird was that people were very suspicious of not doing everything ourselves. Some folks were like, but we made our own cryptography. Why do you want to use this ready-made one?

What's fun with that? And things like that. And we had to sort of overcome and convince people that no, no, it's it's gonna be good, you know, like we're gonna have fast HTTPS connections Like you won't have to wait 20 seconds to load Discord And I think like once once people saw the actual performance difference, then they realized, oh, well, maybe these libraries are really optimized, actually.

Yeah. But yeah, it was initially a bit of a bump to overcome. Well, I want to get into the funding and sustainable development stuff. But just one side tangent, what are you having to use the desktop right now? Oh, right now. So I have one machine with Mac OS and I have one with Ubuntu. Okay.

So those are the two operating systems that we are targeting our first alpha release of Ladybird for. So those are the ones I keep here. And a lot of people are asking us about Windows. Some people send quite angry messages about Windows. Like, oh, if you're not on Windows, you're never going to get any support. How can this project be a browser if it's not on Windows? Yes. Have you been writing these?

It's not on Windows. Yes. Have you been writing these? Don't worry. I've got plenty of similar angry comments on various things I'm involved in. Right. Yeah, yeah, yeah. So you're familiar with the general sentiment.

Oh, quite, yes. Yeah. So the reality of our situation with funding is that we have seven people that we can pay to work on this at the moment. Um, which is incredible for something that isn't even an alpha yet. Um, we're very, very happy to be able to do that, but we just don't have the manpower to target. it one more platform. And we feel that putting out an alpha in 2026, we just have to focus on making the web work.

And we're starting with the platforms that we know best ourselves. And then we're just building everything in such a way that if you can port it to one platform, then it's not terribly complicated to port it to others. And that said, there is a community effort to work on Windows support, which is ongoing. It's just not something that we are devoting full-time engineering to at the moment. But they have been making progress on building. I know the JavaScript engine already works on Windows

and people are working on other parts of the browser. So when we eventually do make a commitment to Windows, we won't be starting from like zero. There's already some work happening. So the idea is sort of, you want to get something done on a platform, you know, rather than trying to tackle everything at once. Yeah, exactly. Exactly.

Because putting out a super disappointing product on three platforms, versus putting out something that kind of works on two platforms, we're going to go with the latter. And really, we would probably scale back to a single platform if we believed that we could do a better job. But it turns out that macOS and Linux are sort of similar enough that it's not terribly

difficult to do both. But Windows is just a bit of a stretch to say that Windows is similar to the Unix systems. Yeah. That's fair. Yeah, I think people kind of forget that sometimes that Mac OS is just Unix. It doesn't look like what you expect from Unix because it's fancy Apple graphical environment.

But at the core, it's just a Unix kernel. Like there's nothing, it's maybe they don't want you to, they don't, they want most of their customers to ever think about that. They just want them to look at the fancy graphics. But yeah, you know, it's not like obviously Windows is a very different platform, right? Like there's, there's just a whole different development philosophy that went into it. Yeah. I get why you've gone this route. And I would much rather prefer you to stick with something that, how would I say it?

First impression is very important, right? I- I- how would I say it? First impression is very important, right? And you want to make sure that What people see when you've not called it ready, but when you've called it, hey, this is our alpha Yes, people are gonna know it's an alpha. But look people judge things How they see it doesn't matter if it's alpha doesn't matter if it's a beta, it's the tagged release, it's out there, so this is how people are going to judge it. I've talked a lot with the guys doing the Cosmic Desktop and it's the same idea where they are very particular about when they want this thing to be ready and they waited a very long time before even starting the alpha. Basically it was mostly complete when the alpha started because

if it was any earlier, you know, if it crashed all the time, anything like that, that idea sort of it stays with a project even after those problems are resolved. Like Pulse Audio obviously has that stuck to it. System D has that stuck to it. Even though a lot of those early issues haven't been. KDE, right? KDE 4 was a horrible release, and people still have that idea in their head, because that's what it was like, so that's what it's always going to be like. Yeah, very true. You only get one chance to make a first impression, is what I'm always telling people, And we have to make an actual effort to make that first impression a decent one.

And this is why we don't provide like easily accessible nightly builds right now, for example, because we don't want. Is that a plan during the alpha? During the alpha, we're gonna make it available. Yes, but right now, basically, a person who wants to try Ladybird but is unable to run the two or three shell commands required to build it themselves

are 100% going to be disappointed by the product in the current state. And so we put up this tiny little roadblock of saying you have to build it yourself. Here are the commands. Very, very straightforward. Just to avoid giving people like a bad experience for no reason, basically. And also what we are looking for at the moment is really not users, but developers and sponsors. And so our messaging is geared towards that at the moment. But that will obviously change as we put out an actual alpha version and start soliciting bug reports

and whatever information we can gather from people without telemetry, obviously, or with some extremely opt in form of telemetry. I know that's an extremely sensitive topic. And I've Yeah, I've made my opinion very clear on that. My opinion, like, in case you know, my opinion is if if you opt into it, if you're informed, I literally don't care. Take a sample of my DNA, if you tell me exactly what you're taking, that's fine. I've agreed, this is the contract that I have agreed to, that's fine.

But when it's opt out, it gets very... I am very opposed to it. I understand the developer perspective and why, why people want it because you have, if you have opted in, you're going to be selecting for people who are more likely to be in certain groups. Like maybe the more technical users are going to be on certain kinds of systems. So you may not get a good representative sample. I understand why, I just don't like it. Yeah, yeah, it's true. But you have to make a compromise there, I think. And given what we can see in the browser industry with, let's say, major players shooting themselves in the foot repeatedly in various ways, we should at the very least try to learn from

their mistakes and not repeat them. Let's at least find new mistakes to make. I think one thing with opt out is if it's opt out from the start, people go into it knowing what to expect. It's when you change the deal along like halfway through, right? Yeah, very true. Yeah. Um, yeah. So we are going to come into this with a everything is opt in from the start, and we

want to keep it that way. And it's just easier for us to be like sort of purist, I guess, about being opt in if we just commit to that from the very beginning, because then it's obvious what we shouldn't do that we shouldn't add any kind of telemetry that would be opt out. And yeah, some people, some people are going to want to opt in and, you know, bless them for doing that. We will probably figure out a way to, to collect primarily crash data, I guess, is what's going to be interesting.

We certainly don't care about who's using the browser or what they're using it for. It's more about how does it crash, or unexpected situations occurring in the field that we had not predicted, that kind of thing. And yeah, it's unclear to me what is the absolute best way of doing this this because I think you can't ever please everybody.

There are some extremely hardcore privacy people who, you know, like you could say, for example, we offer an opt opt in telemetry or you can say, well, we have two binaries, one with opt in telemetry, one you can say, well, we have two binaries, one with opt-in telemetry, one with it compiled out. And that's still not good enough for some people. They demand that it shouldn't even be in the source code and so on, you know. And finding, I think we'll find like a reasonable point there where we can make most people trust what we're doing. And obviously everything is open source and, uh, inspectable and so on.

Yeah. I don't, I don't think there's any, any value in trying to appease the people who don't want it in the code base. Right? Like that's just, you're, you're trying at that point, you're kind of on this infinite purity test. It's like, okay, well, if I'm well I'm gonna remove that well how can you trust the third party libraries then you kind of go back to that okay we expect to write all of that in house and okay well you know you just keep going you just keep finding more and more

things like there has to be a cutoff point and I think that cutoff point you know is if maybe if you really wanted to have it be a compileoff point. And I think that cutoff point, you know, is if maybe if you really wanted to have it be a compile toggle, right? Like I don't think that's that big of a deal. But even if it's just like you can turn it off in the menu, like that's fine. I know some people would want that extra sort of security, not just security, just some people just don't like to compile in things they're not going to use, right? So if it's behind a compile flag, right, that, yeah. I think that's the, as far as I think would be sensible to go. Yeah, completely agree. I think pushing past that point, then it starts to get a little

bit silly. And you're getting into this territory with a bunch of people that you will never really please them anyway. Yeah. You will never reason with the unreasonable. Right. Yeah. And we're already learning, you know, we don't even have a downloadable binary, but we're already meeting some people who are a little bit unreasonable with the feature demands that they, uh, that they send me. Um, but, um, for most people, it's going to be very reasonable software, we hope. Well, let's talk funding because funding a project like a browser is a challenge, right?

Cause you're either a company like Google where the browser is a thing, right? Because you're either a company like Google, where the browser is a thing you do, but it's not your primary business. Google, if they got rid of Chrome, you know, they have everything else they do. They have the search engine, they have YouTube, they have Gmail, everything else. And then you have obviously Mozilla,

where they started off with a donation-based model, and now they're basically a Google sub brand and then you have models like Brave for example where Brave has they have like support contracts and they also have their crypto model as well. And, you know, then you have other companies like Opera does their stuff and. Like, how, how do you make a browser that is actually fundable? Like, how do you fund a browser? And obviously you're still fairly early on. So maybe, look, maybe, maybe in the long run, this doesn't work, but at least the approach that's being taken now.

Right. So what we're doing right now is that we are just taking sponsorships and donations. Um, so sponsorships are some company or an individual decides that they want to donate, um, some amount towards our development because they like what we're doing for one reason or another. Um, and so they give us the money. We put their logo on our website, we say thank you, and then there are no strings attached beyond that point. So we don't have any kind of monetization plans. In fact,

the official line is no monetization of our users ever. I know that perhaps in the last week or so, people have been betrayed on the concept of never, ever will we do this. But I don't think we should become cynical just because a big corporation goes back on a promise. We don't want to monetize our users because we are ourselves users that

don't want to be monetized. And by monetize in this case, what we mean specifically is that we don't want to sort of turn our users into a product for somebody else to buy, right? It doesn't mean that we wouldn't try to sell a coffee cup or a t-shirt someday to a willing buyer, but we're not selling out our users, I suppose. And so we just seek sponsorships and donations from companies and users who want this to exist, who think that this is a good idea. And we know of course that this will never raise

a billion dollars, like selling default search placement would and we have made peace with that. And that is sort of why we also, we have a very small team with a small budget and we're trying to engineer something that a small team with a small budget can maintain in perpetuity. Simply because we know from the get-go

that we're not gonna find some way to sell our users. So, and our users is our only real asset that we have that we could sell, right? Because we are a permissively licensed open source project. Anybody can take it and build a better browser. What license is this, by the way? Oh, it's a two-clause BSD. Okay.

So, and people ask about that too sometimes, and they say, well, what if Google just takes your code and makes a better product? Then I would just say, good on them for making a better product. You know, we'll do our best to compete with their better product. But at the end of the day, that's the setup. It's a permissively licensed project and we are committing 100% to not selling out our users to anybody. And instead funding it with sponsorships and voluntary donations. And so far there has been, uh, it's been really quite nice and easy to raise money. Uh, people are really hyped on the idea and a lot of companies are getting behind the idea. I think, you

know, everybody has their own motivations. But when I speak to our corporate sponsors, there is a common theme of feeling perhaps a little bit concerned that there's very centralized control over the web platform. So you have all these companies building on top of the web platform and they are all at the mercy of Google, essentially, deciding what happens with the web platform. And so if your entire business sits on top of the web platform, it's in your interest that that platform be remain open, let's say, and remain vibrant and remain something that can actually be implemented anew if the existing players stop caring about it or do something objectionable, let's say. So that's kind of where we're at. So we're just talking to companies, new companies all the time and just finding a lot of excitement about

the idea and a lot of the reactions that I get when I meet with people is that like oh well we didn't even realize that would be possible like you you can build a new browser we thought we were kind of stuck with the situation that we had right. Some people are enthusiastic and of you know, there's been a lot of skepticism about the feasibility of it. Um, but I find that over time, as we've been doing this, we've been kind of melting hearts, uh, around the industry, like people seeing our progress and, um, slowly they start to admit that, okay, well, maybe it is possible to build one of these

things. So, that's been lovely to see as well. For anyone just listening, when you mentioned corporate sponsors, platinum tier right now is Futo and Shopify. Platinum is, is that a hundred K or above? That's right. Yes. Okay. 100k or above? That's right. Yes, okay

Gold is proton VPN I don't know who that a HR yet. I've never heard of that company. I don't know what they do. It's RFs. They are SEO and Web tech company. I see I see and there's a bunch of other like silver sponsors and uh, bronze. Actually, what you said? Mitchell Hashimoto, isn't that ghosty guy? The one and only, yes. Yeah, okay.

I thought the name sounded familiar. Yes, yes. Sorry, I just wanted to bring that up just so people are sort of aware of, just there are like companies involved in this, companies who've sponsored this who, you know, you're aware of it's not just, you know, it's not just individual donors, right? Like there are companies that have put their support behind this project and I guess are at least trying to make something happen here.

Right, exactly. And I should also mention that my co-founder for the nonprofit, Chris Wanstrathe, he seeded our corporation with a million dollars as well to get us off the ground. And then we've been raising from other companies on top of that. And it's not raising venture capital in the traditional way that people do it. We're actually just raising sponsorships. So the only thing we're selling here is the logo on our website and we will say thank you on x.com and in our newsletter and video and such. And yeah, this is just perhaps a lot of it is that we're just in the right place

at the right time doing something that a lot of people were not expecting to happen. And when they hear about it, they just instantly get excited about it. So with funding this project, how much leeway do you try to keep to make sure, you know, you don't have to just suddenly get rid of people. Right. So we've committed to maintaining 18 months of runway, which means that if people just stop sponsoring us tomorrow, nobody renews their sponsorships,

all recurring donations stop. Let's say we can go for 18 months with our current burn rate of expenses and salaries and such. And so we're going to try to maintain that, which means that we don't add people to our team unless we can afford to. And I think that's just a reasonable way to do this. Because we could certainly build faster if we decided, let's just go for it. You know, like let's hire the Silicon Valley approach and burn all your money.

And then someone acquires you. Exactly. And we're not doing that. And I think it creates a better environment for everybody. And sure, it slows us down a little bit. But as I keep saying, like, this is about finding a sustainable way of doing this, right? It's not about building a browser as fast as possible. It is about building something that a small team can maintain forever. And I guess it's never really been done before

because all the teams that really build browsers have been traditionally super well-funded. They have some kind of backing in the billions. And yeah, so this is just something that we have to do. We have to stay very, very calm and composed with expenses. But it's not just about the money. It's also about architectural decisions and choices when we work on the software. You know, like not taking on, for example, complexity that would be inordinately difficult to maintain. So we, I guess a practical example of that is if something is unimportant, maybe we don't put a bunch of effort into optimizing it.

is unimportant, maybe we don't put a bunch of effort into optimizing it. And the obvious example is JavaScript execution. So in the major browsers, you have hundreds of man years and PhDs poured into JavaScript performance. Because I think around 2009 or 2008, something like that, they decided to have a performance war between the major browsers. Because they put out these JavaScript benchmarks, and then it was just on for a decade, where they just kept building more and more complicated just-in-time compilers to beat each other on these benchmarks. And it's, you know, like incredible feats of engineering have taken place here. But looking at this from our perspective, where we're just coming into this, the idea of like burning a million lines of code on optimizing JavaScript compiler, when JavaScript right now is around 3%

of our execution time, it doesn't feel like the most important thing to do. And it's certainly possible. It is certainly the case that there are websites that rely on fast JavaScript. But the vast majority of the web, it's not relevant. And so at least of the web, it's kind of not relevant. And so at least at the moment, we

have to choose to optimize for most of the web and to optimize for simplicity, if you will, maintainability in our architecture. And then that sort of idea spread throughout the entire project, where we just don't overcomplicate things in the interest of keeping it maintainable. So to keep the team small, you have to design things to make it so it's actually maintainable

by a small team effectively. Right. Yeah, exactly. And I don't know exactly where the threshold is, but I've learned from experience working on much larger teams that at a certain point you become this kind of project where people silo themselves, where you no longer have a person working on the project, but they're working on a subsystem in the project. And to some extent, like everybody becomes experts on subsystems that they're focusing on. But I would like our project to have a lot of people that are just comfortable going all over the place. And the only way that that's really achievable is if the thing is small or small enough that you can do that.

In a 10 million line codebase like WebKit, nobody's an expert on the whole thing. Probably nobody's even truly proficient in the whole thing. And so that's something that we're trying to design for as well, to have a codebase. When I say that it's maintainable by a small team, I really, I guess I mean exactly that, that it's maintainable by a small team, I really, I guess I mean exactly that, that it is maintainable by a small team

that can operate across the code base productively. I think a really good example of a project that ends up siloing, kind of because it just has to, is going back to the Linux kernel where you can see the list of the silos, because they have a big maintainer list of each thing that people are a maintainer on. And those people, maybe they get involved

in some other little things here and there, but a lot of the time they are, you know, I am the DRM person, I am doing a memory management, I'm doing this driver, I'm doing that driver. And the Linux kernel really isn't a project, it's basically a monorepo of a bunch of smaller projects. And people kind of just do their own thing. The only time they really interact with each other is when there is some sort of crossover, like you have, you know, the Rust discussions, things like that.

Yeah, exactly. And I mean, obviously, if a new person joins our project, they are going to be limited to a small area at first. But we don't put up any of these sort of fences or boundaries between subsystems. Everybody's welcome to work on any part of it. Their rules are the same. Like, there is no like, oh, if you want to touch this, you have to talk to that guy., if you want to touch this,

you have to talk to that guy. And if you want to touch that. And I understand in a project like Linux that they need to have this level of coordination because there are so many people working on it with completely different incentives and reasons for doing what they're doing. Um, so it's just necessary and we want to not be that, um, ever basically. Um, we'll be happy to have their success of distribution, but, uh, not so much the, um, the bureaucracy around it. Yeah, no, that, that makes sense. Cause you get to a point where if things get too big, you end up having bureaucracy around it. Yeah, no, that makes sense because you get to a point where if things get too big, you end up having

people that need to manage the people that are managing the people and you know, that level of bureaucracy is the thing that slows down a lot of big projects. So you see this in like modern game development where you have these, you know, a thousand people working on a game. The credits are 40 minutes long and the game costs $200 million to make. But you look at the credits and half the people on there aren't even like actually working on the game. They're just managing the managers so that they can like coordinate

across all of the different teams. Yeah, indeed. That whole industry is, it's amazing to me how they managed to build these things. It's very impressive. A little bit lifeless, perhaps, but that's an entirely different discussion. Yeah. So what is, I guess we can go into like, what is like the long-term vision for the project, like where say, you know, we got past for release, say we're like five, 10 years from now, like where, where do you want the browser to be? Like in a perfect world where everything, where timelines are met, where things actually

happen when you expect them to, where do you want to be? So ultimately what we want to do is we want to give people another alternative, something that they can choose. And we would be very happy if we can put out a product that some people choose and they love it because it aligns perfectly with their own interests and their own idea of what a web browser should be. Now what does that look like in practice five to 10 years from now? Well, we want to be on all the major platforms that people are actually using. So Mac OS, Linux and Windows are the obvious desktop platforms.

We want to try to be on the main mobile platforms as well. If they are still Android and iOS. We'll see. And we want to be something that anybody could download and start using. And it would be no fuss, just a browser. Doesn't try to do anything fancy, but supports the basic browsing needs of the average person and allows you to use the popular extensions that people like to use.

That's sort of our goal. You know when you go to a hardware store and you pick up a hammer and you don't care what brand it is? If we can manage to build a browser that feels like that, like, oh, this works perfectly for me. I forgot what it was called, but I remember the icon. I just tap on it and I'm online. Um, it's kind of modest as a, in terms of ambition, but, uh, I would really

like to, to build something like that. It just works for people that just is just a competent browser. Um, and something that we also managed to prove is maintainable by a small team with a small budget. In a way, I'm almost like afraid that somebody would decide to throw a large amount of money at us. Because it would put us in an awkward position of having these resources that we're trying to build something to handle without. But that's a very bizarre, luxurious problem statement, I suppose. I sure hope nobody gives us a lot of money. I have too much money to deal.

What do I do with all this money? Yeah. Yeah. No, I think that's a- But if you look- Oh, it's gone. I was just going to say, you can see, if you look at some of the major browsers

today, how things can go terribly wrong if you get comfortable with that big pile of money when suddenly the people that were kept refilling it, they just stopped doing that for one reason or another, or the money stops flowing. And so we don't want to get ourselves into a position where that could become a problem. So if we really like the setup that we have right now where we have many sponsors, each contributing like a portion of the sponsorship,

and we would like to expand that. So we have like a strong patchwork network of sponsors, um, to give us that diversity of sponsors, I guess. Um, I think having that, that vision as a simple browser is kind of something that needs to be out there, right? Because with all of these browsers, which are basically just, you know, all Chromium skins or all Firefox skins, because everybody is building off of the

same engines, the way they're differentiating themselves is adding more and more stuff into the browser, right? Like let's use, even use like Vivaldi as an example, where they have an email client, an RSS feed reader, and a bunch, like every browser now has a PDF reader inside of it, and it's just adding more and more and more things into the browser. I don't think there's anything wrong with doing that, right? If that's what you want from it, you want this mega application where realistically you don't need, like you again, you could use your browser as an RSS leader, you could use it as a PDF reader, you don't need these tools installed on your system, but at the same time a browser doesn't need to do all of that. You can

have a browser that its job is to be a browser and I think there's definitely a place for that. And especially when it comes to actually creating something which can be maintained, I think sort of just has to be how you do it. I imagine so. Yeah. And like, we're very, very like, unlike all of these companies that are building on top of Chromium or WebKit or whatever, we are very, very grounded in the technical reality of what we're doing. We're in the middle of building the engine, and we're very aware of what goes into that. And so our ambitions right now are just to build a competent engine, um, and then wrap that in a simple browser. And who knows, you know, maybe when we get this thing working really well, we

will say, we will have users saying like, you know, it's really frustrating that whenever I download a PDF, it pops open in another window, maybe we've figured out a way to optionally integrate a PDF.js or some viewer like that, whatever. But for the time being, just a very simple browser is sort of where we're aiming for. That said, I think it's important to establish already now that we mean a simple browser with privacy respecting defaults. And sensible privacy-oriented defaults, let's say. And I don't like looking at ads online any more than you do. I don't like being tracked online any more than you do either.

And we absolutely want to have all of the faculties necessary for like blocking ads, blocking tracking, all that stuff. Um, we're not trying to build a browser that, um, like gives the trackers what they want. Uh, it's, it's ultimately we're building this product for users. Um, so yeah, I guess that's, that's the one thing I would add to it. It's a simple generic browser for users, not for anybody else. And we are in a good position to build that because we don't have any loyalties to, you know, advertisers or trackers or whoever would want to find out more about what you're doing

online. Um, and yeah, in some ways, I guess we, we are in the best position of all the browsers to, to build something like that. So earlier you talked about how at one point, what was driving development is some would say, Hey, this site doesn't work. And you would sort of try to get that site working. And you said you switched to more of a test driven development. So how is the project actually driven now? Like how do you decide that this is the thing we need to work on?

So it's a hybrid approach, let's say. We have seven people working on it full time, and then we also have a community of volunteers working on it as well. And everybody has sort of specialized in an approach to development, let's say. So we have some of the test-driven people, some of the performance-driven people, and also some sort of compatibility-driven people. And as a leader and manager, what I try to do is I try to find what type of person somebody is, how do they thrive as a developer,

and then just get them to work in that way. So if somebody thrives pushing test scores go up, then try to find a way for them to work where that can be central to their work. If somebody gets really excited about, you know, seeing websites work, try to find a way for them to work where they can get to see websites work. And we have all different types of person on the team. And what that gives us is like a nice coverage, I suppose, where we're making progress on all these fronts at the same time.

But the test driven part is a little bit newish. So in August of last year, so I guess like half a year ago, six months ago, if my math is mathing, it's difficult to do arithmetic sometimes. I get it. At least when you're in a podcast. But yes, half a year ago, we started running this thing called the Web Platform Tests, which is a comprehensive test suite for browsers.

It's co-maintained by all the browser vendors. So the idea is that whenever somebody implements a feature or fixes a bug in a browser, you would create a bunch of tests to go along with that and then contribute those to the web platform tests repository. And in this repository today, there are, I think, like 2 million subtests, which is just a large amount of tests, let's say. Yeah. And that's putting, I think that's like,

that's a lot more than Vulkan has. And Vulkan already has a stupid amount of tests. Right. Yeah. So the web platform is fairly complicated. I think that's fair to say. And a lot of tests have been written for it. And the test suite is by no means a complete coverage of the platform. It's evolving daily. People keep adding more tests to it. And this is a great thing

because it means that every browser can run these tests and find out do we behave the same as the other browsers? Are we implementing the spec correctly? And once we became able to run this test suite, it just became a part of our workflow is to see how we're doing and try to make improvements on our test score. Because the more of these tests we pass, the more coverage of the web platform we have in our browser, and the more compatible we are with other browsers.

How long does it take to run through this test suite? At the moment, it takes us just under five hours. But we are also working on improving the cycle times. So what the other browsers tend to do is they throw multiple machines at this. So they just like divide a run across many machines. We do it on a single machine. And so the other browsers, they kind of finish a run in an hour or so. And then we're taking five times as much time. Right.

I guess there would be sets of tests that are logical to group together, so you could put those all on one machine. Yeah. I think in theory, you can kind of slice and dice however you like and just divide it across many machines. But that's not something we've done yet, because it's been good enough for us

to get a new score every five hours. It's been OK. But yeah, it takes us about five hours to run. And our current score is something like 1.77 million points out of 2 million. So we've been making good progress. And if you look closely at this, you will find that it's very heavily weighted in some categories.

There is famously 1.1 million tests for Chinese, Japanese, and Korean text encoding. So I like to make graphs that subtract those tests because it's a bit more interesting without them. Right, yeah. Since everybody just, everybody supports those things and then you get 1.1 million points for free. Yeah.

Just for anyone who's unaware of some of the problems here, like these are very complex, firstly if they're very complex characters, then you have the issue of, um, right to left writing or up down writing. Then you have issues with, um, like handling your, like, different, like the different character sets as well. So with Japanese, you don't just have the Kanji, you have hiragana and katakana. So you have to deal with that as well. And then there are different, there, there are, this is something that some people don't just have the kanji you have hiragana and katakana so you have to deal with that as well and then there are different There there are this is something that some people realize there's different width versions of them as well

there's the the full width and the half width which are used for different things and That that's just like scratching the surface of just things. I'm going off the top of my head I'm sure in in Korean they have a bunch of other weird similar things as well I would imagine that There's probably some weird things with like dealing with Arabic as well because you're again right to left and the characters are the way they've rendered depends on the specific way they've written like the way they're rendered depends on the specific way they're written. Like, the characters will change depending on how a word is written as well,

which I'm sure also creates other oddities. Sure. Yeah. So we don't support all of these things correctly, but certainly a lot more than we used to, because we used to make our own font rendering library for Serenity OS. This feels a lot like making your own time zone library. Yes, which we did. And yeah, so we've since adopted Skia for graphics and HarfBuzz for text shaping, which is used all over the open source world.

And that gives us way better support for things like right to left or, as you say, these letters that change shape depending on the context, using complex shaping rules and stuff. And so that stuff is improving. We also use the ICU library from the Unicode Consortium, which gives us a lot of interesting things, like I guess gives you access to the million little pieces

of metadata about different writing systems that you might need, like how to distinguish, like, um, I know you can interleave like left to right and right to left text in the same, uh, paragraph and things like that. And, uh, I don't think we're doing everything correctly with those things, but, um, frankly, no one's doing everything correctly. Like, if you just want a great example, just, there are people But frankly, no one's doing everything correctly. Like probably not. If you just want a great example, just there are people that will set their usernames on YouTube to these just weird, weird sets of Unicode characters.

And you end up seeing the name spread across the entire screen because nothing handles it correctly. Yeah, that's definitely a thing. And we are no better with these things. handles it correctly? Yeah, that's definitely a thing. And we are no better with these things. But yeah, it's a big part of the web platform test is Chinese, Japanese, Korean. So when we say 1.77 million, you can kind of

subtract 1.1 million from everybody's score, and then it's easier to compare them to each other. And if you want to put that into context, the landscape currently, you have three major engines, which is Chromium, Firefox, and Safari WebKit, right? And then some people say Edge, but Edge is just Chromium. So you have those three major engines, and they are at the top on the web platform test scores. And then out of the sort of up-and-coming underdog engines, we are leading that pack.

But we are, I don't know, maybe like 200,000 tests behind the first major engine that we want to catch up to. Okay. Or I should get you a current number. No, we are 153,000 tests behind Safari. Okay. So it's going to take a lot of effort to catch up. The points are not as easy to come by these days as they used to be. Right.

A lot of the low hanging fruit is gone. Yes, they are gone and we have squeezed them for all their juice. And so now it's like the slow grind of fixing little things again and again, over and over until we catch up. But, you know, it's what we've signed up for. And it is a beautifully, let's say, distributable task that maps really well to a community, which is something that we're very fortunate to have

for Ladybird because it's not just us full-timers working on it, it's also like just enthusiasts around the world, people with jobs or people in university who find this interesting and they want to hack on it. And it's very, very easy to motivate somebody with a test score can just say like, Hey, I can spend my evening getting this test score to go up a little bit. It's just really fun. I love doing it as well. And it's I don't know, I have faith that we're going to be able to keep pushing it upwards for the foreseeable future.

But the points are getting harder to come by. And we're going to have to do hard work, like more complicated things for some of the points, but it is what it is. I'm looking at the list of contributors. I'm surprised how many, how many people, like a lot of projects it's obviously, you know, you're at the top and then there's like a massive drop off to the next person. But there's a lot of people with hundreds of contributions here. Right. So if you're looking at our GitHub,

it's important to know that we forked from Serenity OS. So if you're looking at total contributions, that includes the backlog of commits all over Serenity OS as well, not specific to a browser. But if you look just in the last year, you will see specifically Ladybird stuff. But yeah, like people, we have a lot of people making a lot of contributions. Um, a lot of very active people.

And in the beginning, um, I don't remember exactly when it happened, but, uh, I used to have this metric of like how many percent of the code base, um, was I the last person to touch and in the beginning, you know, it was a hundred percent. Like I was still the only person working on it. And then over time, that number kept going down. And at some point it crossed the 50% threshold and it felt like pretty wholesome thing, like, okay, I'm no longer the majority of code touchers here. no longer the majority of code touchers here. And nowadays, I'm just a fraction of the activity like everybody else, which is a beautiful thing, I think.

I think it's a sign of a really healthy project, right? Like every project's going to have some major person. Like even if it's a relatively healthy project, there's going to be people that are the most active. Whether it be, you know, the Linux kernel, whether it be a desktop. Like, you're gonna have those clear major contributors, but what you wanna have is people who are that active basis. Well, they aren't spending every waking hour of their day working the project, but people who frequently come back, and they're not just the one-off contributors,

you know, there's nothing wrong with that either, but having a strong base there and a strong base that's growing as well, like that's a really good thing for a project to have. Yeah, indeed, indeed. And our base, it does, like it grows over time for sure. Our Discord community is a good way to see this. Like it keeps growing over time, but people sort of drift in and out

as real life gets in the way. But I think we're like 12,000 people on Discord or something like that now, which is just a lot of people. And obviously, a small fraction of those people contribute to the project in the form of code. But I always think that everything you say on Discord or social media is sort of an opportunity to entice a new developer to join the project

and to get excited about some aspect of it. And it has been working for us, at least so far. We're always introducing new people to development. Somebody's making their first ladybird contribution today somewhere in the world. And that's awesome. We're happy with that. Well, speaking of bringing developers in, obviously I'm going to, I have to ask you about Swift.

Because that's always, there's been like a weird thing I've heard about the project wanting to shift towards. And I have a little bit of Swift experience. I've done a little bit of iOS development in the past, but why? I think this is the easiest question, why? Right. So we want to, in the long term, we want to find a solution for the typical safety and security problems that plague browsers. We have a code base in C++ today because that's what Serenity OS was, because that's what I knew when I started it.

And so we've evolved into a large C++ project. And unfortunately, it seems that C++, the language, is not willing to evolve safety features, at least not of the scale and scope that would be considered appropriate, let's say, in this day and age. And so we have to look for a solution for the future, where we can keep our current codebase, but incrementally add safety features so that we

can be sure that we are building a secure piece of software, I suppose. That's the motivation for it. We're trying to think long term. building a secure piece of software, I suppose. That's sort of the motivation for it. We're trying to think long term. We need a solution for the safety and security issue in the long term. And then we looked at the different alternatives for that. And what we did was I asked people to try prototyping different pieces of the code base in different

languages. And I know a lot of people don't like to hear this, but we tried Rust. And initially people were quite excited about it because, you know, a lot of hype around the language. But inevitably, every single person that I asked to, to prototype in it, um, became frustrated in one way or another that it just kind of didn't, um, either like didn't map to the kind of, um, problems that we wanted to solve. And it was cumbersome to work with and. It just didn't, it didn't feel like a good fit in our code base. It just didn't feel like a good fit in our code base. And Swift was another language that people were initially very suspicious of. I even had a slightly hard time getting people to try it because they were like,

oh, what's this Apple thing? But then when they tried it, they came back saying like, oh, well, this is so incredibly pleasant. It fits into our code base kind of perfectly. It maps to our coding style and it has language level support for the features that we use. It's like very object oriented. Rust is not object oriented. And, you know, Swift has a lot of flaws, but it is object-oriented.

We are object-oriented. And most importantly of all, they have an actively developing C++ interoperability story. So the Swift team is, like, very actively, very consciously trying to become sort of the C++ successor language. So they are adding features to their language and they tell people, we want to be the language that you add to your C++ code base when you want to evolve into a modern language. So they allow you to interact directly with C++. Like you can call C++ functions back and forth.

Now in practice, this is not all roses. It's not completely mature. And we have run in, certainly run into issues with trying to C++ interop ourselves. We've reported a bunch of bugs and we still have yet to begin sort of expansive use of Swift in our code base because of sort of remaining interoperability riddles that we haven't solved yet.

But yeah, what it really came down to was that everybody just kind of liked it, and they didn't enjoy Rust. And the Rust people are not always great at hearing this. Yeah. I guess I don't need to say more than that. Anyway, yes, we tried those languages. We also tried some other languages.

We are not interested in language war. So when people ask like, well, did you try my favorite language? Here's why you should use my favorite language. We just say like, yeah, don't worry about it. The zig people of the new Rust people. I remember when I was in university, um, that was when Rust was like first getting attention. There was one guy I knew who was the Rust evangelist.

This was before there was any Rust jobs. No one, no one was doing professional Rust work yet, but he was the guy. He was the guy who would constantly tell me about it. I have people doing the same thing right now with Zig. And I'm sure there's going to be a future for it somewhere. But like, there are some people that get very, very hung up on the language rather than what is the best tool for the job.

Yeah, exactly. That's kind of, that's kind of our thinking is that what is the best tool for the job? What are we really trying to achieve? And you know, if I'm perfectly honest, what I would love to happen is I could just have C++ with a garbage collector for memory safety. Because then everything would just work the way that it already does. And the garbage collector would prevent us from committing memory sins.

But C++ doesn't come with a garbage collector. So neither does Swift or Rust, by the way. And the web platform requires a garbage collector because of JavaScript. So it's just something that you have to provide somehow. And if I were to start over today, for the record, I would build this whole thing in a garbage collected language. But that's not really an option at this time. If you had that option, what language would you go with?

I don't know. Fair enough. I don't know. I would have to mess around and see what the landscape looks like. But I'm sure there is one. I'm afraid that I would end up with Java, but I would like to look around first. Yeah. No, I think in general. In my experience as a programmer professionally, um, for the last 20 years, there's always been a language that, uh, people are extremely hyped about and they think the whole world should be rewritten in this language and every year it's, um, like an election to choose the new language for that year. Yeah.

Yeah. When I was first starting out in the nineties, Java was like that language that everybody should rewrite in and at some point like C sharp and you know, like it's, it's been trading back and forth. Rust was like really the hype thing. Everyone was talking about Go. Yeah. Go for a time. Yeah. trading for rust was like really the hype thing. Everyone was talking about go. Yeah, go for a time. Yeah. And, uh, there's always like an energy like that. And I think it's a good thing that people get hyped on new technologies and new inventions,

but it's important to understand that these are fads, um, to an extent, right? That doesn't take away from the sort of technical achievement of new languages with new ideas, but there is a fad component and there's also sort of football hooligan component to these things and it's a little off- to be honest, uh, especially as somebody who's getting a little older, a little tired of, of the football hooligan aspect of language, evangelism, let's say. Um, but that ultimately that doesn't really factor into our, um, choice to use Swift. It's, it was just like comfortable to use it. Now, one thing you brought up that I, I can't let you go by thing you brought up that I can't let you go by, I can't let you go by without

bringing it back up. Object oriented. People are very, very opinionated about programming paradigms and object oriented is usually the one that's very maligned. Why, why isn't OO code base? So the web platform was born in the 1990s when OO was like the rage, right? And a lot of the central APIs and object models in a browser are object oriented. And because of compatibility, they just don't change.

And so fundamentally, the engine that we have to build for the web is built around objects that talk to each other in very typical object-oriented ways. And so it's just the most straightforward programming paradigm to implement a browser engine in. It just maps beautifully to the specs. One of the things that we do, I haven't talked about that in Ladybird, is that to sort of, one of the many things

that we do to alleviate the maintenance burden is that we try to implement our code so that it looks exactly like the spec, or as close to the spec as possible. I did see you complaining about the spec on Twitter the other day about the spec not exactly being what is actually the actual way it's supposed to be. Right, Right. So the web specifications are supposed to match what browsers are really doing.

And when that's not the case, sometimes the spec has to change, sometimes the browser has to change. Everybody gets together and they have to decide, like, which way is it? And at the same time, like all the other browsers, when they implement a spec, they sort of tend to freestyle a lot. Like they read the spec and they see like, OK, so this is what's supposed to happen. I will implement this in my favorite way, in a way that I think makes sense. Maybe it's for like personal taste reasons, or maybe it fits into the programming model that they have in their browser or whatever,

we have tried to evolve our programming model so that it can look literally like the spec as much as possible. So if you're reading our code out loud, it matches almost word for word what's in the spec. That's not always possible or practical, obviously. But a ton of our code does look like that. And that's just so much more maintainable, is our thesis, at least, that years from now, when we have to go back and work on this stuff, hey, it looks exactly like the spec.

And now the spec changed in this way, so I know exactly where to change it and how. And I don't have to figure out like, oh, here's an interpretation of that spec. How does this spec change map to this interpretation? And that's also sort of a strong motivation to use the OO paradigm. It's because it allows us to do that, where we just transliterate the spec from English into OO programming. And yes, OO has lots of issues. I know that the data-oriented design people are very gung-ho about their cash lines and data locality and whatnot.

And, you know, they have a lot of good points about that. Things go faster if you put all the data in a very good way for the CPU to access. They're not wrong, but it's always a compromise, I think. Sometimes there are sacrifices that you can make and compromises you can make where, yes, we could make this thing faster, but does it even matter? And for the things that don't matter,

I would rather our code look like the spec than our code be data data oriented and really fast. Right. It sort of goes back to the thing about maintainability, where you could write code that is considerably faster, but if nobody understands it, right, like, then you create a whole new problem for yourself. Yeah, or if it takes considerable effort to understand it. Because one thing that's quite awesome, actually, that I would have dreamed, would only

have dreamed of years ago, is we now have people coming from other browser projects or from the standards bodies. And they come to our code base. And they can contribute code changes to it immediately Because it looks just like the spec that they were editing and We've had that happen many times where they just come in and hack on something and like for example somebody somebody was in there the other day who was like working on some spec changes to the HTML specification and he wanted to figure out

what would happen if I make this change in the spec. And he discovered that he can just prototype the change in Ladybird. And then he'll find out instantly what actually happens in practice if you make that change, which is like compare that to having to extrapolate mentally what happens if I make

the spec change in English versus testing it in in practice. It was quite awesome thing and we also have people from the W3C contributing actively to Ladybird as well which is very cool and all of that is I think possible because of the way that we've approached programming. I think if they had to the way that we've approached programming. I think if they had to learn our way of doing things, they would be much less likely to put up with it. Because we have no market share. We have no users.

We have no... None of that going for us. But we have a code base that they can instantly understand. Yeah, I guess that does make it much easier. You know, honestly, that's really cool, right? Like it's maybe it's not the intention, but it kind of acts as sort of like a reference implementation of the spec in a certain way. Yes, exactly. So one of our friends in the W3C has called it. He doesn't say that it's currently a reference implementation but that it could be sort of one of our sort of north stars, I suppose.

Something that we can aim for in the long run to be a reference implementation. And I think that's certainly something that everybody can get behind and say, well, that's a good idea. There should probably be a reference implementation of the web. I think that's sort of a, if it could get to that, like a kind of like really healthy spot for things to be in. Cause I think like that's something that you could see a lot of like the major web companies really wanting to be involved in supporting right?

Whether you're, you know, even like at Google right? Having something there that is a reference implementation, that is useful to them as well so they can sort of base where they're going. And maybe it's not the intention from the start, but I Don't know. I do think there's definitely a lot of value in that Yeah, I think so too And I'm I particularly love the idea that the spec people who have been working in the dark this whole time That they would have a platform to test out their ideas

That's really attractive and I will say time that they would have a platform to test out their ideas. That's really attractive. And I will say, it would be interesting to be sponsored by somebody like Google. We're certainly open to the idea of them sponsoring us. We'll put their logo on our website and say, thank you. But that's, that's everything that they would get. It's not currently something that is happening, but they wouldn't be treated any differently than anybody else.

But a fun fact is that although Google the corporation may not care about what we're doing at the moment, many of the people working on their browsers are current sponsors of our project. And we actually have sponsors on all the major browser teams. So I think people who build browsers, they appreciate what we do quite strongly. And for many reasons, including this sort of reference implementation aspect. Right. Like the engineers are very different than corporate.

The engineers, they want something that they know they're doing the right thing for the specification. Like, it's good for them. Maybe corporate might not agree, right? I think people, when they talk about a company, they kind of forget there is often a really big distinction between the people who are actually doing the work and the people who are running the company. Oh yeah. Yeah, for sure. For sure. And yeah, it's just one of the many different things that motivate us going forward. And as I was saying earlier, you earlier, our motivation for doing this has evolved over time, and I expect it will continue to evolve.

I really love the idea of a reference and implementation of the web. I think that would be a beautiful thing. And nobody else is really trying this. There are people trying to build new browser engines, but they're not taking this particular approach. Um, yeah, who knows? We'll see what, what, what happens with that.

So one thing I did kind of want to get into is sort of the state of the browser right now. So obviously it's not alpha yet. right now. So obviously, it's not alpha yet. You're not calling it alpha. But how usable is Ladybird as it stands? It's surprisingly usable if you stay on the happy path of stuff that we are actively testing, which

would be things like going to the Ladybird GitHub repository and reviewing pull requests and filing bugs or browsing our developers' respective local pizza places, things like that. But you open it up and you go to a website that we've never heard of, big chance you're going to get a crash or something like that. And crashes, just to be clear, we don't tend to have memory safety problems. Because we already do have a garbage collector that protects us from the typical use after free type of problems

that C++ projects tend to have. So our crashes that we do get are typically like invariant violations. So like, hey, this thing is much bigger than it was supposed to ever be. Or like, why is this number here negative? It's not supposed to be negative, assertion failure. And a lot of our work on web compatibility is just like taking these kind of violation reports and just tracking down why is this happening and then fixing our engine to handle it. But we do treat all of those things as crashes today and for that reason the browser is quite unstable because it will just throw up its hands. The moment anything happens that we're not expecting,

we'll throw up our hands and say, crash, crash, please deal with me. So there's no like defensive programming here where we try to, you know, like paper things over and handle it anyway. A product that we want to release to people is obviously going to be perhaps a bit more fault tolerant that it would allow

some visual strangeness to happen instead of crashing. Right, yeah. If some element can't load correctly, it just doesn't load the element. It doesn't die. Right, exactly. So that's just kind of a, I guess, almost like a paradigm shift in the way

we think about failure states in the browser when we shift from being pre-alpha to alpha. When things shift into the alpha, what should the state of the browser look like at that point? at that point. So we have sort of an internal list of websites that we want to work decently well. And it's like pretty unexciting list. It's like Facebook, Instagram, Twitter, the usual suspect, LinkedIn. We want you to be able to search insights.

Yeah. Like these, you know, major internet properties. Um, we haven't put YouTube on there because, um, dealing with all the video stuff feels like, um, uh, a little bit of a scary commitment. It's possible that we will get it done in time for alpha, but I don't know. We don't want to commit to it because it's also like a little too much effort on a specific use case that doesn't necessarily benefit every other website. So we'll see about that one.

But the idea is that you would be able to use the major internet sites, you know, like login, interact with the sites in the ways that you typically do, like post your daily cringe motivation on LinkedIn or whatever, and go like some photos on Instagram, that kind of stuff. And outside of those sort of like real world use cases, we also have a list of different technical things that we want to achieve. So we want to achieve certain levels of feature support for different features.

We want to achieve certain optimizations so that we can be reasonably responsive. But it's hard to choose exactly what we target. I have talked to all of the people working full time on it, and everybody has some targets for themselves that they want to achieve. But then we also have a community that works on it at the same time. We have no control over what they decide

that they want to make work. Ultimately, though, what's really going to happen in practice is that when the time feels right, we're just going to say, all right, this is good. Let's release it. Because we say we're going to put out an alpha in 2026. So at some point in 2026, we're just going to put it out and hopefully we'll be able to get it into a good state before then. Um, but we don't want to be one of those projects that just keeps postponing and postponing. The last episode I just recorded was, um, with Jahan from the GIMP project. So you want

to talk about postponing and postponing. That's a great example. But like what they were doing with GIMP 3, like it evolved. It was going to be a small release and like, hey, let's redo the entire color system. Let's do this. Let's do that. And things that were going to be in, you know, 3.1, 3.2, like, hey, let's just do it in 3.0. And it snowed on from there. Yeah. So browsers are in an interesting place with releases, though,

because everybody else puts out a new version of their browser every couple of weeks. Or maybe Safari is still a bit slower than that. But certainly Chrome and Firefox, they put out new versions very regularly. And that's just the nature of the business. And so I think that's what we were gonna have to do as well. We just have to get into the cadence

of the typical browser release. So whatever we put out, it's not gonna be fresh for that long. Like we'll have sort of continuous new alpha versions Obviously, it's just it's not that there's going to be like a here's the alpha version Please test it for the next year and let us know how it goes It'll probably be the alpha version for a couple hours. Maybe until the next one comes out So alpha is more like a mindset. I would say. You can take that clip out of context.

So obviously it's hard to really estimate software timelines, especially for a project as big as doing a browser. But how long do you hope to have the alpha last for? So we hope to be have the alpha last for? So we hope to be in the alpha mindset for a year, uh, and then switch to a beta mindset. Um, and another great clip. Another great clip. Yes. And then of course, after another year, finally settling in the sigma mindset,

um, and so on. No, well, we're hoping to do Alpha for a year and Beta for a year. The difference between the two things is not entirely clear. Just broadening the target audience, I think. The Alpha version will be like very rough, developers, early adopters and brave souls. Beta version probably like a little bit of padding around the edges, you know, like

not necessarily so pointy everywhere that you hurt yourself, but still decidedly broken occasionally and clumsy software. Um, and our hope is that after two years of, um, increasingly intense user testing and feedback, we'll be able to put out a general release that would work for the average person and have a high chance of providing them with a reasonable browser experience, let's say. Um, yes, we'll see. Yeah, we'll see. As I said, you've been in this industry for a very long time. Software timelines, you know, no matter how many times someone has done a

timeline, something's going to happen. Projects, scope's going to expand. Are jobs bigger than you thought it was going to happen. Projects, scope's going to expand. Are jobs bigger than you thought it was going to be? Yeah. Yeah, true, true. Uh, but one beautiful thing about this is that we know exactly what it is that we're trying to build. We're just trying to build a browser.

It just has to support the web. Now the web is gigantic and it changes all the time, which is frustrating. But it's also like an understandable problem. Like it is the web. And so we're not going to be surprised, I don't think, by sudden unexpected requirements. I say that, of course, and then, you know, tomorrow Google comes out with virtual reality browsing. Forget about HTML. It's all about whatever now. But barring some kind of major seismic event like that, we're expecting that the web is going to continue being the web. And we just need to get better at rendering and interacting with it.

So the major problem that I see happening is we're not necessarily good enough by the time we want to do a release. And I think within reason, we kind of have to accept what we're able to do in the time that we allocate for it. And as long as it's within reason, a usable thing, we want to put it out. But that's something we have to evaluate over time as dates get closer. Yeah, we'll see.

It's very encouraging to look at where we are today. It really does feel like the major pieces are in place, but it needs a lot of performance and stability work. But the question of, can you build a browser, it's no longer really a question. It's more like, can you build a browser? It's no longer really a question. It's more like, can you build a browser that's fit for an average person to use? Can you polish this enough that it's like an actual software product and not just a

proof of concept? Because today, you know, as complicated as it is, and as much we've invested into it is still very much a proof of concept. So as things have sort of improved as a browser has actually been like become a browser, how have you noticed like, I guess, vibes where people talk about the project sort of change where? Early on you know you said there were a lot of people who thought this was just impossible You can't build a browser. How could anyone ever do that? Now there is something there and you will show off things just kind of working obviously it's very

You know vertical slice. Hey, here's the the thing I know that works working. But just the fact that there are things that are working. Yeah, so attitudes have changed dramatically since we started. When we when I first started hacking on HTML stuff in Serenity OS, people would tell me, yeah, sure, but you'll never be able to implement JavaScript. That was the sort of mental block that people had in the beginning, that JavaScript is impossible. You can doodle with your little CSS and HTML, right?

And then we started building the JavaScript engine, and it relatively quickly just got stood up and started working. And then they would shift to something else. And there's been this continuous shifting of the goalposts. Whenever we succeeded something, people, the haters inevitably come and say like, oh yeah, well, that's not really a browser though,

because the real browser can browse YouTube or can do like video calls or whatever they decided a real browser can do. And there's just like been a type of person that always finds some reason that it's not a real browser. But I have noticed that in the beginning, there were a lot of those people and they had relatively low thresholds for what was possible. Right. And over time, now it's like only the most hardcore haters remain.

Eventually it's going to be, well, you can't have a reasonable security update cycle. you can't have a reasonable security update cycle. So you've got a browser that works and it browsers the entire web, no issues, but oh, well, if there's some vulnerability discovered, you can't get that out in a reasonable amount of time. Right. Yeah, exactly. Like this tiny little things, or essentially like it's only real browser if it's from the Bay Area region of California, right? Like otherwise it's just a sparkling JavaScript. Right.

Right. Um, and, uh, I, I'm sure there's going to be those people in the end. Sure. Yeah. But, uh, uh, you can't, you can't please them. As I said earlier, you can't reason with the unreasonable. Yeah, exactly. Like there, there are just people who they just want, they want to see things fail.

They don't really know why or what they want to see fail, but they just want to see something fail. Yes, there are certainly those people. And a lot of what we get late. Oh, did we DC? We went two hours. Oh, we good? Yes. Hello.

I'll be back. Almost two hours without a DC. Almost there. Okay. Sorry. You're on. Yes, we good now. Okay.

Right. So where was that going? Okay, sorry you're on yes, we good now, okay, right so Where was I going I was thinking about these people who are skeptics and And one of the things that we've been hearing is that it's just too expensive like even if you have the technical chops to do something like this, you just can't pay for it and I've been telling those people that just because Google throws a billion dollars at projects like this doesn't mean that you have to do that. Like there might be other ways to do it, right? And that's what we're trying to prove that you can do it with a smaller budget, smaller

team. And now that we're showing pretty good progress with that approach, those people have also chilled out a little bit. They're not complaining about the money anymore. And the most recent stuff I get is more like, I don't like some of the technical decisions that you've made. You know, like, why this language? Why object-oriented programming?

Like, why do you this? Why that? Why not Zig? Or whatever. Yeah, so now it's like people have almost accepted the idea that you can build one of these things and they just want to argue about technical details, which I guess is a pretty big achievement of sorts. We've managed to go from like this cannot cannot possibly be done to, I don't like

your coding style. Um, I'll take it. Yeah, no, I, I agree. Like that's, that's a great place to be in. And it, you know, you, you said you've been involved in, uh, emulators in the past as well and that's sort of the same, the same idea, right? Like I'm sure, I'm sure the guys who work on RPCS3, the PS3 emulator, like early on people like, there's no way you can emulate a PS3.

How could you ever deal with that cell processor? Well, yep. I've heard that for sure. I don't, I don't think I ever said it, but I certainly, when I first heard about the PS3, I remember thinking like, I don't think this would ever get emulated. So I can see where people are coming from being skeptical. But you know, life finds a way, as they say in the Jurassic Park.

And that might be a bit of an old movie, actually, these days. I don't know if people get that reference. But life does find a way to emulate all these things because it's just the unstoppable force of the highly focused nerd who wants to do something with his computer. You don't want to get in the way of that because they'll find a way. Yeah, if you have a sharing complete language and the problem is possible, someone's going to do it. Someone is going to do it. Yeah.

It may be like years of painstaking effort, but it's going to happen. And, you know, you look at the current gen consoles, like PS5, and we can say the same thing, like, oh, this will never be emulated on consumer PC or whatever but like of course it will. Well actually with that one it's actually really easy with the current ones because they're just x86 PCs. Like it's the easiest it's ever been to do it. Yeah well okay I'm a little out of touch with that business now actually I don't even know what's in a PS5 so there there you go. It's even easy now.

Well, now you have the DRM problems. That's a whole separate issue. Yeah, okay. So DRM and like, let's also say something like, that sounds a little more out there. So like an electric vehicle, right? Like there are these proprietary electric vehicles. Like surely nobody will ever be able to like,

just build one of those in their garage. That's just too much, but who knows? Yeah. Like whenever we talk about things like this and then you fast forward 20 years and there's like a high schooler doing it. So I think we should just cool it on the XYZ is impossible thing because you always end up with egg on your face.

Yeah, yeah, yeah. Well, I will go back to what I said about Linus. I think people forget he was he was a first year university student when he started the Linux kernel. Okay. In the early, um, in, there's some early stories of him working on it and he didn't know how to use a, um, he didn't know how to write a function that took a variable length, uh, a variable number of options. Like that's how early he was in programming when he started that project. So yeah, like, yeah, obviously the hardware was a lot simpler back then. It was very different time, but someone did it. And again, if something, if you're dealing with a problem that is possible and you have a Turing complete language and somebody has the motivation, like, yeah, it, it can be done. So it probably will be done at some point.

Yeah, yeah, I think so. And something I would love to see is that now that we show people that you can do this, I would love it if more people do. And, you know, these people who want to argue about coding style or perhaps more important technical decisions, if they have better ideas for how to do this, go and try to do it. Um, it's not as hard as it might seem.

Um, and certainly if people want to fork what we're doing in the future, like who knows what happens with that. Um, we would like to have built something that people could continue in a different way if many people feel that that would be good. But yeah, like lowering or raising the baseline, I guess, is what we're trying to do for what's possible. I think it's not an important thing at all,

but there's one thing, one last thing I probably should ask about an important thing at all, but there's one last thing I probably should ask about. The name Ladybird, or as people in my comments seem to say, Ladybug? Or one guy said Ladyboy, which is definitely, that one's definitely wrong. But Ladybug I'm sure you get quite often. Yes. Americans are very confused by the concept of a ladybird insect.

And not just average internet commenters, I've actually had a lawyer ask us if we can't get the name Lady Bird, would we consider changing it to Woman Bird? Which is a very bizarre question. But yeah, why is that the name? Not the woman bird, but lady bird. Right. So the history of the name is that a lady bird insect, some Americans call them lady bugs. It was the mascot of the Serenity OS project since its early conception. And the name comes from the, um, nickname of my wife in Hungarian, which is the ladybird in Hungarian. And so I just, um, put a bunch of ladybirds everywhere in Serenity OS, just as a reference to my wife.

And then the name sort of just came along from there. Um, so that's the So that's the great mystery. There, you know, fair enough, fair enough. Like some projects, you know, there's projects like OBS where it's just named the thing it does, the open broadcaster software. Then your project was like, hey, like Linux where it's just, it's named after Linus even though he didn't exactly want that. It was gonna be called Freaks. I'm very happy that didn't happen.

And then names just come up. That would have been lame. I'm sure we'd get so many repeated jokes because of it. So many very overdone jokes if it was called Freaks. True, true. I will say that there's a subtle reference to something in the name, which is the bird suffix. The reason that I went with Lady Bird and not Lady Bug

is twofold. It's because Lady Bug, calling a software something bug feels a bit like, yeah, this is not great. Yeah. And also, it's a little bit of a reference to the original name for Firefox, which was Firebird. But they had to change that because there was a conflict with a database engine or something, I think. And, and they got into this heated argument about like search engine optimization or whatever, back in the, back in the day. Uh, and I, I was a user of firebird way back when, and I thought that's a cool name and so, um, that was something that I thought about when we, when we ended

up calling it ladybird is like continuing that something bird vibe from so long ago. Thunderbird, I suppose, has existed this whole time because they used to be complementary names like Firebird and Thunderbird. Yeah, in the very early versions, they actually had a bird logo. Right. Indeed. I think even before that it was called Phoenix.

Yes. Which I guess was like... Point one was Phoenix, yes. And then it became Firebird at some point after that. Not exactly sure what version, but yes. That... I'm seeing the logo. That is such a...

Logo designers would cry seeing this thing. It was clearly... It's a product from the time, like the user interface icons and everything, it's a very, like, just after Windows XP kind of vibe. I realized there's one more thing I hadn't actually asked you about, and that was, you did bring it up before, but extensions. And I know you've probably been asked hundreds of times, like, hey, when are you going to support extensions? When can you use uBlock Origin, Bitwarden, whatever it is people want?

What is the plan for extensions? So they're not in our alpha schedule. It's not something we're actively working on because we are having a hard enough time getting the web to render correctly at all. But we all use extensions ourselves and we all have extensions that we love, and we want them to work. And so our long-term ambition is to support the popular extensions that people care about. You know, like uBlock Origin or whatever is the most popular ad block extension. And there are other things that people like, you know, sponsor block, things like that.

And as browser developers, we're also very keen on there are these extensions that like take the whole page and save it as a single HTML file. Yeah, that's very, very handy. So probably going to support those as well. But yeah, we just want to support the browser extensions that people care about the most. And we have absolutely no incentive to restrict your ability to build a super complicated

ad blocker if you want to. So I don't know what that will look like, because we're not actively working on it today. And it depends a bit on what the extension landscape looks like. Perhaps, let's say, a year or two from now. But whatever is popular, we want to support it. Today, nothing is supported. What we do have is very rudimentary ad blocking built in, which is you can just make a filter list where we refuse to load.

If a URL matches this regular expression, then we don't load it basically. That's what we have. None of the fancy stuff. But yeah. I think I just want to make it clear that Ladybird as it exists today, it's not really suitable for end users. Sure. And I feel like I've been implying this the whole time that we've been talking, I just want to say it very clearly,

that like, if you are an end user, not a developer with no ambitions of getting into browser development, you will be disappointed by Ladybird if you try it out today. You might have a bad time getting it to build and then you will certainly have a bad time getting it to work. So please just give us a chance to build it up and give you a good first impression. Okay. I think I've hit on pretty much everything

I wanted to touch on here. If there's anything else you wanted to mention, otherwise, yeah, we can start signing off from there. Yeah, so I guess what I'll mention is that we're always looking for more developers to work on our projects. If people want to get involved, where is the best place they can go?

You can go to ladybird.org, and you will find links to our GitHub repository, to our Discord server, where we coordinate development and hang out all day. And the best way to join, or the best way to start development, it varies depending on what your interests are. But generally, if you like test-driven development, you can find a test to work on.

If you like compatibility with the web, you can find a web page that doesn't work and then try to figure out why. We have guided many, many people through the process of getting started with this. So just join the Discord and come chat. And if anybody's listening who's interested in sponsoring this effort, we are always seeking new sponsors,

both corporate and individual. And you will find information about that on ladybird.org as well. Awesome. Anything else you would like to mention? Maybe anything else? You mentioned sponsors. you mentioned getting involved, nothing else.

You do, you also do the stuff on YouTube, don't you? You have like updates. Sure, yeah, we have a Ladybird YouTube channel where we post at the end of every month, we post like a little update about what we've been doing in the last month and give a little bit of a presentation and a visual demo of new features and stuff. Just to give you an idea of where we are, they usually run between 15, 20 minutes, something

like that. We like graphs. There's a number of graphs in them. Yes. We like to put graphs in them and try to mix it up a little bit. And yeah, people generally enjoy those to just give you an idea of how things are going.

And they are unedited. So if something doesn't work, you get to see it not working, because we try to be transparent with that. But for the most part, things do work in the demos. So yeah, come check that out on, I think it's at Ladybird browser on YouTube. Awesome.

Yeah, I'll leave all of those links down below. You guys are also over on X or Twitter, whatever you want to call it as well. So that'll be in the description as well. Yeah, is that all of the things that people should know about? I think so. Yeah. I mean, if you're interested in learning anything else or want to talk about these topics, come hang out on Discord. there's always somebody ready to answer your questions awesome um okay as for my stuff my main channel is brody Robertson i do linux videos there six days a week um i at some point when the alpha is out i'll probably do a stream and it's probably gonna crash a hundred times because that's what tends to happen when i mess

around with alpha software i'm having a lot of fun doing the... I've done probably 20 or 30 hours dedicated bug testing of Cosmic. It's very fun. I do not recommend... I do not recommend testing your desktop environment that's alpha on the hardware you're recording on. It tends to go very badly. I should do it in a virtual machine. I don't. So, yeah. The gaming channel is Brody on Games. I stream there twice a week. Right now I'm playing through Enderbag Nolia and Stranger Paradise.

There's the React channel, Brody on some React, so I put clips over there if you want to see clips of stuff. The audio version of this can be found on Spotify and every podcast platform there is an RSS feed. If you search Tech over Tea you will find it. If you like to see the video version it is on YouTube. The video is also on Spotify if you like Spotify video in case anyone uses that. I don't know why but they have a thing that sorts it. Yeah

I'll give you the final word. What do you want to say? How do you want to sign us off? I guess I'll just say thank you for having me on Brody. It's a very lovely conversation. And I think you made me think about a lot of a lot of interesting stuff about how we position ourselves going forward into the future. It's something that it's easy to forget about when we're just focusing on the day-to-day technical details. And it's going to be really exciting, I think, to see once you start testing our alpha. I'm definitely going to be watching and cringing every time it crashes.

So I will probably have a couple of drinks by my side as well. So yeah, we'll see how that goes. Yeah. But I'm looking forward to it. Awesome. No, yeah. Thank you for having me on. No, it was an absolute pleasure. I really enjoyed this. Um, and yeah, I learned a lot about the project.

I had like a, you know, a cursory understanding of it, but it's, it's really good to see sort of how this is progressing. And, um, yeah, whenever you want to come back on it, we can do this again. Uh, maybe when you're closer to the alpha or the alpha is out. Um, yeah, I'd be happy to do this anytime in the future. Love to. Awesome. And, uh.