Eric Meyer: Hello, I'm Eric Meyer, and I'm a developer advocate at Igalia.
Brian Kardell: I am Brian Kardell, and I am, also.
Eric Meyer: And today, we have a special guest, Andreas Kling, who is the lead on a brand new browser. So, Andreas, hi. Thanks for being here.
Andreas Kling: Hi. Yeah, happy to be here.
Eric Meyer: So, you're working on a browser called Ladybird.
Andreas Kling: Uh-huh.
Eric Meyer: We want to talk about all of that, but what's the background of where did Ladybird come from to start with?
Andreas Kling: Right, so it all started in 2018 when I went to a drug rehab program, because I've been struggling with substance abuse for a very long time. And when I came out of that rehab program, I found myself with just so much free time and I had no idea what to do with all of it. And I started programming because that's something I knew how to do lots of, and that's how I ended up working on random things that I'd always wanted to do, but never felt I had the time for. And the big project I started was an operating system, because I always thought that seemed cool, but never really sunk my teeth into it properly, or never really gave it a fair shake. And I had a lot of fun with that, and it just grew and grew and grew. And I put it online and other people found it, and a little community formed around it. And that community just grew and grew and so did the operating system and the scope of it. And at some point, we had built a GUI and we had all the widgets, buttons, check boxes, all that stuff. And I thought, 'Hey, wouldn't it be nice if we could display rich text, and wouldn't it be sweet if we could use HTML as the internal representation of a rich text widget?' And I started just putting together a simple HTML widget that you could view, simple text that had bold, italic, stuff like that. That was what I was trying to achieve. And it just escalated from there because it was really fun to hack on and just add more tags, start to add CSS and so on. And it just incrementally grew to the point where I had to admit that, I guess, this is a browser, not just a rich text widget anymore.
Eric Meyer: Okay.
Andreas Kling: And, yeah.
Brian Kardell: You had a background in browsers, right?
Andreas Kling: Right, right. Yeah, so it wasn't entirely by accident. I did work on browsers for a long time. This was just how Ladybird started. But yeah, I had a career in browsers for a long time, starting all the way back in 2006, when I first worked on KHTML, in KDE.
Eric Meyer: Yeah.
Andreas Kling: And then I got a job at Nokia a couple years down the line, working on Qt, Qt WebKit, moved to Apple from there. Spent six and a half years I think at Apple, working at Safari. And then I left, got into some troubles, and ended up in the aforementioned rehab clinic. And then, now I'm doing Ladybird, which was just supposed to be an HTML widget, I guess, is the essence of the story. But Ladybird today has come quite far from that original humble beginnings, of course. We've managed to build a fairly capable engine, and it's all from scratch, just like everything else on SerenityOS, we pride ourselves on stubbornly just doing everything from scratch, even though it would be much more convenient not to.
Brian Kardell: So, one thing that, it keeps jumping out at me is you have Serenity as the OS. I have some questions about that because I think that's really interesting. But to stay on topic, Ladybird is the name of the browser, but you're inventing... The exciting thing isn't the browser, it's the engine, right?
Andreas Kling: Sure.
Brian Kardell: And you're building a new engine. A whole new, that's a whole new web engine. It's a whole new rendering engine, whole new JavaScript engine, everything all the way down. Does the web engine have a name or is it just LibWeb, or something?
Andreas Kling: It is literally LibWeb, yeah. All the libraries in Serenity are just called the obvious name. So, we got LibJS for JavaScript, LibWeb for web engine, and various other lib this and that. So, I gave it the name Ladybird so that we would have some public facing name that people could refer to, because when you're in SerenityOS, it's easy to talk about lib this and that, but LibWeb didn't feel like a PR friendly name, I guess.
Brian Kardell: Right, right.
Andreas Kling: So yeah, I just talk about Ladybird as the whole project, basically. But it is also the name of the UI program that is the shell for the browser engine.
Eric Meyer: Where did the name Ladybird come from?
Andreas Kling: So the SerenityOS project has been using ladybugs as mascots forever, since the early days. It was just our first icon that we had for the system was a little ladybug, and then we gained various ladybug themed emojis and things like that. But I didn't want to call it Ladybug because then it sounds like it would be buggy. And I thought, 'Remember when Firefox was called Firebird? That was a pretty cool name. What if we call it Ladybird?' Because I hear that in the UK that means ladybug anyway, so yeah.
Brian Kardell: Yeah, that's actually... People who study insects and stuff don't like ladybug because I guess they're not true bugs. So, the Ladybird is actually the preferred. Yeah, I like it. I like the Ladybird name.
Eric Meyer: Yeah. And I'm curious, you mentioned that the Serenity project, in general, stubbornly tries to do everything from first principles, even though that's much harder. Is there... What is the driving foundational principle there? Why did you pick that as a foundational principle?
Andreas Kling: So there are many things that factor into it, but the two main ones are, I used to work at Apple for a long time, and I got so used to this culture that they have there of all the experts on the whole system are all in the same building or in the adjacent building, and you can just go talk to them. And I always thought that is so sweet because you have some super gnarly esoteric problem in some system library, and the guy who wrote it is just next door. And I always felt like in the open source world, they don't have that. And I wanted to, after I left Apple, I still craved that kind of environment. So I thought, 'If it doesn't exist, what if I try to create it?' So I wanted to just build a system where we can cultivate all the expertise in one place and we can be super accountable, so that whatever the problem is, you can never blame anybody outside the project. Blame always stays within the repository. And I think it's, as you say, it is very difficult to work that way, but it has also created a very strong community because people enjoy working in that kind of space where they get to become experts and they get to take extreme ownership of system components in a way that I think is much, much harder in the Linux wider open source ecosystem. And the other aspect of why we do this is because it's fun. It's fun to build things from scratch. Everybody knows that. And it was supposed to be a hobby project that I was just doing to fill up my time. So it is rooted in just fun time spending programming activity, and I hope it never shakes that origin.
Brian Kardell: I listened to another podcast that you're on, and I think we won't get as much into some of the details of the history and the whys and everything, but you went into a lot of that, and I'm sure people could find it.
Andreas Kling: Maybe it was CoRecursive, probably.
Brian Kardell: It was CoRecursive, right. Yeah, that was it. But it was a good podcast and I really can relate in a way to the time that suddenly is free. I've had other moments in my life that were not specifically that, but where you have some really major life change and the minutes just go forever, and finding yourself a thing that you can throw yourself into is really helpful. For me, it was usually art, painting. But, so we have a series on here called Web Ecosystem Health, when engine disappears, that's the whole story. There's so many pieces that go into is this a healthy ecosystem or not, that maybe focusing on the exact number isn't the important part. What is the ideal number? Is it 3, 5, 7? We don't know. I think Jeremy Keith said, 'It's like political parties. One is definitely too few, and a hundred is probably too many, and somewhere in between there is a series of debatably good numbers.' But in that podcast, we have said a bunch of times that you're more likely to lose engines than to gain them unless it's by evolution, like KHTML becomes WebKit becomes Chromium. And recently, at the Web Engine HackFest, we had two presentations of novel browser engines. It seems to really fly in the face of what I've argued, but I don't think that it does. And I want to ask what you think, Andreas. So you know, you've said on your podcast, 'People say you can't build a browser engine from scratch,' and you say, 'Sure you can.' I don't say that you can't, I just say that it's really, really hard to create a fully featured and competitive mainstream competitor to WebKit and Gecko and Chrome. I would think that for both these engines, that's a ways off, right?
Andreas Kling: Sure, yeah, it is. It's a very big task. It's a lot of work. It's going to take a long time. But I think at the same time, there's never been a better time in history to build a new browser engine.
Eric Meyer: Why is that?
Andreas Kling: If you look at the quality of specifications today compared to 10 years ago, for example, the specifications are vastly better today. The effort that the CSS working group, for example, has put into just clarifying so many things makes it actually possible for someone like me who never worked on CSS's layout to go and write a layout engine without a team of experts around me or even having to ask for help much. And I think that's fantastic. And I was pleasantly surprised because I was going into this assuming that it was like the olden days still, that you would end up sitting with CSS 2.1 and trying to guess your way through the various descriptions of blocking and line layout, because that's what I had seen my coworkers do at Apple, just struggling with the old CSS world. But nowadays, the specs have gotten so good, and it's not that they're perfect, but that they're really a lot better than they've ever been. So I think just from that alone, it is a lot easier today than people might think. And I think what you describe, it's absolutely true that it's a ton of work. It's absolutely true that it's hard to build something that will be mainstream competitive, of course. Google throws hundreds of engineers at this and they have full-time people working on it around the clock. It would be silly to say that we're going to out-compete them at their own game, but I think it's still possible to build a browser that can render a significant majority of the web at a satisfying fidelity, let's say. And I also like to think that if you can gain enough momentum that you get to the point where you have a decent rendering of most websites that people care about, you can then gain an enough momentum that you attract people to go and fill in the niche gaps that they might care about, and you might attract funding and so on. So that part is up in the air, but I think if we can go hard and fast enough that we end up there, who knows what can happen. So I'm just very optimistic, I guess.
Brian Kardell: I think it's astounding what you all have accomplished so far. Not just a browser that you can view many websites on, but also the operating system that it's built on. It's incredible for this very short amount of time and small number of people, comparatively.
Andreas Kling: To be honest, the operating system was the easy part.
Eric Meyer: So the operating system was easy, but browsers are hard?
Andreas Kling: Harder.
Eric Meyer: Wow. Talk about that a little. How so?
Andreas Kling: Because operating systems are fairly simple when you boil it down to what you really want to do. Kernel is a well understood, well-defined problem, and in our case, we're just working on the POS-x specifications. We're building a Unix compatible operating system, and that means we have a set of APIs that we need to support, and that work is really straightforward. And then, we have a UI paradigm that we borrow from late 90s Windows, Microsoft Office, that kind of stuff. So we already know what we need to do there, too. We need to build this UI and these interactions, and so on. And I don't know, I just found that work really straightforward, whereas with the web stuff, I know I was just saying that the specs are better than ever, but it is still hard to get all the specs gluing together, I think. And really when it comes to CSS, I would say CSS is so much harder than any of the other parts of the web platform because it's hard to work on any CSS module in isolation. It really requires the person working on CSS stuff to understand multiple specs at the same time, and then keep them in their head and implement multiple things at the same time, if that makes sense. It is so much easier to work on JavaScript or HTML or Fetch or any of those specs, because they are more self-contained.
Brian Kardell: To the point of what you were saying about specs have gotten so much better, one of the things that definitely started those riggers was when Hixie sat down and specified the actual HTML parser, which never had really been written down the way that it needed to work. So, there was a way that it needed to work. There was an interoperable subset, and that was never written down, and there were some rough edges that you couldn't get people to agree on until you had something written down. So, I know that that has been cited as a great accomplishment, and other people have said that they've used that to build a parser. We just did a podcast with Martin Robinson on Servo, and in that, we had this observation, this thought that every browser that comes along fresh and implements something ends up making the specs a little better for the next ones to do it. I noticed that you had several issues open in HTML parser, and I think it's probably because you're the last one to look at it with really fresh eyes, right?
Andreas Kling: Sure, yeah, that's absolutely a thing. And it's also one of the big things that I hope that we can do for the community of web engines is to just give our input as a recent implementer. And we haven't been super great about it yet. Yeah, you can find some bugs that we filed, but for the most part, until recently, whenever we had a problem, it was pretty safe to assume it was because of something we had done wrong. And it's only in the recent couple of months that we've matured to the point where now we start to find spec bugs more often and spec issues. And that has been a really exciting transition, actually, and we're just looking forward to helping out more in that area, at least with regards to HTML and CSS. In JavaScript, we were a bit ahead of that curve, because our engine has been implementing some proposals pretty early. So we implemented the temporal proposal when it was still quite new. And we were able to give a lot of feedback on that, which then helped evolve the spec. Now we're a little bit behind because I think people got a bit burned out on updating it whenever the spec changed. But yeah, that's absolutely something that I agree with Martin on that, that every new engine will make the specs better, and next year and the year after that, you'll be able to say that there has never been a better time to build a new browser engine, I hope.
Brian Kardell: Yeah, good.
Eric Meyer: That feels like a sign of maturity for the platform, really.
Andreas Kling: Yeah, I think so. I think so. And when you get deep into the weeds of this stuff, it's easy to point out glaring omissions and things that are really missing. But on the whole, absolutely, the platform has never been more mature, I think. And for something that is so alive as the web platform specs, it is quite impressive how mature they are.
Brian Kardell: People should go watch both the Servo and the Ladybird presentations at the Web Engines HackFest. You can find them on YouTube, on Igalia's YouTube channel. I think they're both great. They're also, I think, a little different, and I'm curious if we can get you to clarify or talk about that a little bit, because it's hard to tease apart because you have done so much that I'm not sure what is and isn't in there. You are not currently connected for web platform tests, right?
Andreas Kling: No. We have recently gotten part of the runner working, so we can run the ref tests, but not the non ref tests. We're working on that, as well, but we're not connected to WPT yet.
Brian Kardell: Okay. If you were connected, how do you think you would stack up? There's about 1.8 million sub tests.
Andreas Kling: I have no idea.
Brian Kardell: If you had to just take a stab.
Andreas Kling: If we get a day to just clean out all the embarrassing crashes, then I would guess maybe 20% or something.
Brian Kardell: So, can you give us some ideas about the sorts of things that aren't currently in Ladybug? Ladybird. Wow.
Andreas Kling: The sorts of things that aren't in there?
Brian Kardell: Yeah.
Andreas Kling: Well, there's a lot of random little CSS things that aren't in there. So, we haven't implemented every type of vertical alignment, for example. So, we only have, I think baseline and the middle and the top are... A bunch of them are missing. And then that is true for many CSS properties and I expect that to have fallout in a lot of tests, because we might be able to pass the test if we were just doing some random CSS thing more correctly. And we've taken a very vertical slice approach to adding functionality to the browser. And by that, I mean we don't tend to implement a whole spec and then move on to the next spec. What we tend to do is we tend to find a webpage that we want to improve for whatever reason. Maybe it's cool to get the New York Times to render, and then we just spend a bunch of time fixing as many issues as we can for that site and then move on to a new page or some new thing that we want to be able to do. And that might not be the most structured approach to it, but it has been very, very good at keeping people motivated and excited and engaged in the work, which from my perspective is almost more important than having an optimal structure to the work, because it's mostly volunteers working on it. I'm the only person who is full-time employed to do this, so I need to keep it fun for people to work on.
Brian Kardell: Yeah, absolutely. Do you support CSS Grid?
Andreas Kling: Yes, we do.
Brian Kardell: And Flexbox?
Andreas Kling: It's not... Yes, our Flexbox is much more mature than our CSS grid, but our grid has been improving a lot recently.
Brian Kardell: Probably you don't have support, I'm guessing, for Web Speech, WebXR, WebGL, WebNN, that kind of stuff?
Andreas Kling: We have the beginnings of WebGL, but the other ones are all absent, yeah.
Brian Kardell: So, there's so much of that stuff. Yeah, I hope my questions don't feel negative. They're definitely not intended. I'm actually real excited by both Servo and Ladybird.
Andreas Kling: Oh, no, no, no. I think it's important to be realistic about what it is that we're doing, and I do meet a fair amount of people who get way too excited, and they talk about, 'Oh, Ladybird is going to replace Mozilla, or finally some competition for Google,' and so on. And people get so excited about that that you have to talk them down a little bit, and that can be a little bit frustrating to deal with because obviously we're nowhere near competitive and it's going to take a long time before we will be. So, none of the things that you brought up were negative. I think they're just fact. We don't have all of these technologies yet and it's going to take time to build them, but I think we are making good progress and the future is open.
Brian Kardell: What's really interesting to me is I feel like there's an evolutionary question here about what is acceptable enough for people to the vast majority of people to use it and even make it a daily driver. Do you know what I mean? I think that's a really interesting question. And you can see that even a little bit in the Chromium browsers. A lot of, they're actually missing a bunch of those things when they're new.
Andreas Kling: Yeah, I think that sort of thing has always been part of the web, at least for as long as I've been a web citizen. When I was a kid, it was, 'This site works best in this or that browser. You need NN4 to browse here, or you got to get IE5,' and these days you've got to use a Chromium based browser. And I think they're just different sides of the same coin. There's always going to be somebody who's pushing for new APIs and new 'standards' to become part of the platform. And I think it's perfectly fine to lag behind on stuff like that. With Ladybird, I'm primarily interested in implementing stuff that is used by the overwhelming majority of the web and make the engine hackable enough and plugable enough that in the future, if there is a demand for more niche features, then it will be reasonably easy to add them to the engine. But it seems at the moment, if I have to choose where to spend my time, I would rather implement more core CSS, JavaScript functionality than any of these new, fancy things that are only used by a fraction of a percent of websites. That's not to say that they're bad ideas, it's just that they're just trying to go where the big ball is instead of chasing the small ball.
Brian Kardell: Yeah, that was actually my point with the other chromium, the not Chrome, the other Chromium based browsers. They also frequently lack many of these. They're not, I don't know, like Tim would say, 'The waft and weft of the web,' that that's HTML, CSS, and JavaScript. One of the things that struck me, I guess the thing that's most surprising to me, is if you go to Google or Apple or Firefox, the people who work on the JavaScript engine, they're not generally the people who work on layout. And even within layout, you have people who specialize in internationalization, or there's lots of specialization, but you have to solve everything. And that is really interesting to me. Is that intimidating to you at all, or are you just built differently?
Andreas Kling: It was intimidating. When I started building the operating system, I was intimidated, and I just kept pushing through that for so long that I forgot. I woke up one day and I forgot to be intimidated, I think, and it just stayed off since then. So I stopped caring. And I think, I also have my YouTube channel where I broadcast myself programming, and that has been very helpful in just taking down my ego, because whenever I make a mistake, I hear about it from people making fun of me. And at first, that was really hard because I wasn't used to that harsh feedback and people making silly jokes about stupid things that I would do. But over time, that accumulated into this hardening of my soul, I guess, where I just became able to push through that intimidation stuff. And it was a lot of work, but I'm happy that I went through that process because now I'm happy to take on anything and suck at it for a while, and do it anyway until I get somewhat better. And then by the time I get somewhat better at something, hopefully I've managed to put something together that other people can help me improve. And that's how most of SerenityOS, most of Ladybird started, was just me pushing through, sucking at something I didn't know how to do, and figuring some of it out, and then other people coming in and helping. And I still do a lot of that, but nowadays, I have gotten a bit more specialized recently because there's just so much specialized work to do on a browser, like you mentioned Grid and Flexbox, for example. I've spent weeks working on our Flexbox implementation, just getting various details right, and it requires some amount of specialization. But I think in a project like ours, we can't afford to all be specialists. It's okay to specialize for short periods, but at the core, if we want to make progress with such a small team and such a shoestring budget, we have to be willing to be generalists.
Brian Kardell: Do you support SVG? I think you do, right?
Andreas Kling: Yeah.
Brian Kardell: MathML?
Andreas Kling: No MathML, and our SVG support is still evolving, but it has been getting better and better recently. I just worked on it today, actually.
Brian Kardell: Nice. I saw a photo of you at the HackFest with Nico.
Andreas Kling: Oh, yeah.
Brian Kardell: And I think I even tweeted, and it was tongue in cheek, but I'm serious, were you working on your SVG, because that's Nico's bag.
Andreas Kling: Yeah, I've known Nico for over a decade, but it was the first time we ever met in person. And I don't know that we were working on SVG at this exact moment, but we did end up talking a lot about SVG because we are recently struggling a bit with SVG text and trying to fit it into our rendering model, because we hadn't worked on SVG before, none of us. So it was helpful to talk to Nico about what the requirements are for SVG text.
Eric Meyer: What did you learn?
Andreas Kling: The most interesting thing I learned was that every character has to be individually positionable, I guess. And in order to support rendering a text along the outline of a path, you need to be able to place them independently of each other, but they should still behave as if they're on the continuous line so that you can select them and so on. And that's going to require a bit of changes to our architecture to support that.
Brian Kardell: There's a question that I asked of Martin that I would like to also ask you, which is how much do you benefit? So you don't actually just go and take a library and port it or something? You don't ever do that, right?
Andreas Kling: Right.
Brian Kardell: But you do... You're not inventing everything from whole cloth. You have the benefit of being able to study and see standards, and also be familiar with people who have done this before and ask questions. How much do you think that you benefit from that? Because I think when you say, 'I spent a few weeks working on Flexbox,' like yeah, people spent way more than a few weeks working on Flexbox and other engines. So do you benefit from coming in late and other people having made a lot of mistakes and having the problem sorted out, and maybe people you can talk to or some code you can look at or...
Andreas Kling: Yeah, we absolutely benefit from being... Standing on the shoulders of giants. That's a absolutely a thing. There is not just the specs that have improved so much over the years, but there's countless discussions on WHATWG, GitHub, for example, you can go and read discussions on spec bugs where people explain and argue in depth about, 'Oh, why should it be this way? Why should it be that way?' So there's a tremendous amount of information you can absorb if you know where to look. And as we talked about, I also have a background in browsers, so I do know how to go and find information because it was my job for many years, as well. So I know where the information is. I have friends who work on other browsers still. So, I think, me personally, I benefit so much from having done it for a long time, just like anybody with experience doing something is going to be drawing on that experience, of course. But as a project, we also benefit from other engines having pushed the standards forward, having improved the platform. And also just from the web being an open platform that's developed in the open. It would be much harder to do this kind of stuff with a closed platform, obviously, like if we were trying to implement a .net VM or something.
Brian Kardell: Yeah. So you also recently, I think, made a little Qt browser for regular Linux based on LibWeb, that is, I guess the straight Linux port of Ladybird. Is that a fair statement?
Andreas Kling: Yeah, yeah.
Brian Kardell: Yeah. I would like to try that, actually. But I'm curious, how does that work exactly? You have to... I guess you're both using... I guess you're using C, so you just compile it for Linux, right?
Andreas Kling: Right, so...
Brian Kardell: And it's just not taking advantage of anything in the operating system necessarily.
Andreas Kling: Right. So, we use Qt to create a simple GUI that has a toolbar and a location text editor where you can type in a URL, and then we make a little scrollable view port, and then LibWeb does the rest, basically. So we don't use Qt for anything that you see in the web view itself. None of the text rendering or 2D graphics or 3D graphics. All of that is our own code. So the Qt application is really just a thin GUI shell for the engine.
Brian Kardell: What about inputs, dialogue?
Andreas Kling: Oh, inputs like keyboard?
Brian Kardell: No, input elements, select elements.
Andreas Kling: Oh, so...
Brian Kardell: Things that often are use a windowing toolkit.
Andreas Kling: Right. So, we haven't implemented all of them. So we only have text input, password input, buttons, checkbox, and radio buttons, I think. Maybe I'm forgetting some, but we haven't done select elements yet and we're missing a bunch of the other ones, and we haven't done validation yet. So, it's an open question, how we're going to deal with looking more native on Linux platforms. It would be easy to make it look like a SerenityOS input elements, but that might look a little bit out of place.
Brian Kardell: That's an interesting question, actually. There's debate on this, and Dominic Denicola, one of the editors of HTML, a few years ago, where they were thinking about a couple of new features and they said, 'There's this constant debate and we don't have to do the thing that we always did. So, which would you prefer the same browser to present the same controls in every operating system? If you open Chrome, it always looks like Chrome. If you look at Safari, well, it is only available in one place, so that's not much. But Firefox, for example, you open it anywhere, they all look the same, or do we match the operating system. And I thought, I was convinced in my head, this is the most ridiculous question. This is going to be such a one-sided, there's clearly one answer to this. And no, it was literally 50/50. So, I don't think there is a right answer to that, and you should do whatever is interesting to you.
Andreas Kling: Yeah, maybe the ideal answer is that we would just let you choose.
Brian Kardell: Sure.
Andreas Kling: If possible.
Eric Meyer: Yeah, I could see that. I'm on the side of stick with the operating system, but that's me.
Andreas Kling: I did forget to mention that we do use Qt for networking currently on Linux.
Brian Kardell: Really?
Andreas Kling: Because our multi-process networking service, we haven't gotten it to run nicely on Linux yet. We do have our own implementation of http, TLS, all of that jazz, but we have yet to bring it up on Linux. So, we are just piggybacking on the networking stuff in Qt at the moment, and we have an open bug about getting rid of that so that we can eat our own dog food instead.
Eric Meyer: Oh, okay. So you have a pragmatic build it yourself approach, which is, build it yourself unless you really need to bring in something else and then plan to replace it.
Andreas Kling: Yeah, yeah, exactly.
Brian Kardell: But that's only on Linux, right?
Andreas Kling: Yeah, that's only on Linux. On Serenity itself, we use our own TLS stack.
Brian Kardell: Such a compromise, I guess, wouldn't be made on Serenity, right? To just...
Andreas Kling: No, it's... Right.
Brian Kardell: ... Support something for now?
Andreas Kling: It's something that early on, for example, when I was just working on this by myself, I used a handful of C library routines from OpenBSD, I think, and then I went and replaced them down the line as the project matured, and I just wanted to get rid of all the borrowed code. And I'm sure that there are still some little things here and there with an OpenBSD origin that we need to replace. It just needs to be tracked down. So, I think, for me, the important thing nowadays is that we definitely don't want anybody bringing any proprietary IP into the project, and we don't want people to take something that's GPL because we are a BSD license project, so that wouldn't be entirely cool. And of course, the spirit of the project is that we're supposed to make things ourselves even though it's hard. So even if you could legally take something, we ask people that they don't, that they go through the suffering of doing it themselves, just so that we get the kind of system that is built that way.
Eric Meyer: So, we've mentioned the contributors and hoping that people haven't snuck past you. How many contributors are there in the main?
Andreas Kling: Oh my goodness. Well, I think we have over 900 total, but active core contributors on a monthly basis tends to swing up to around 50 maybe, recently. But it goes up and down depending on what people are doing. And there are bursts where people get excited about something, and then a bunch of people join in and they work on that for a while, and then interest fades and some new thing attracts everybody. Ebbs and flows. But one of the unique things about our project is that it's such a huge ecosystem, that even if you come in because you're excited about one thing, it's really easy to stick around and get distracted by a million other things. Maybe you come in because you want to work on a file management thing, and then you end up implementing WebP or something instead, which we recently got, by the way.
Brian Kardell: Nice.
Eric Meyer: Like lady birds flitting from plant to plant.
Andreas Kling: Right.
Eric Meyer: There you go. And you talked to some about the contributor community in your talk for Web Engines HackFest. Can you share some of your observations there with the audience here?
Andreas Kling: Well, most of the people who work on Ladybird have no prior experience working on browsers, and that in particular is very exciting to me because I've been in browsers most of my professional life, and it always seemed to me like a fairly small, almost tight-knit community, even though it was spread across multiple organizations. People still float between these organizations. And if you look at Google today, there's a bunch of ex-Mozilla people, and people have just been moving around that. There are only so many people in the world who want to be browser developers, or at least so I thought until I started doing it on YouTube and broadcasting what it's like to an audience of random onlookers, and it turned out that it could be made interesting to more people by letting them in on this angle of it. And I'm really, really happy to have been able to introduce so many people to it, and gotten hundreds of newcomers just to do a patch or two for a browser engine. Even if most people end up not loving it enough to stick around, we still have a bunch of people who have stuck around and worked on it, and that to me is a really wholesome aspect of what I get to call my job. So I'm happy about that.
Eric Meyer: Yeah, no, that's really interesting. So you feel it was YouTube that was the driver there?
Andreas Kling: I think, yeah, that really has been the main driver of new people, at least until this point. If I compare my numbers, my audience numbers on every platform that I use to attract people to what we're doing, YouTube is by far doing the best. And the format is surprisingly interesting to people. Just, 'Here's a browser. Here is the website that doesn't look right. I'm going to make it look right. Stick with me for an hour and we'll figure it out.'
Brian Kardell: I have to say I didn't watch any of the ones where you worked on browser features, but I did watch the one where you worked on doing the Qt browser for Linux. And so, just for background, I did some computer science in college and I had to learn C back then, but professionally, I only did C maybe once or twice. So the C world is intimidating to me, but I can open WebKit source code and find things, and if I read slowly, I can figure it out. So it's intimidating to me, and every once in a while I get WebKit and get it built and then just lose steam. It's so much yak shaving to get it built in the first place that I lose the steam to do it. But the reason I mentioned that is because I turned it on and immediately you were going pretty fast and I was like, 'Oh man, this is really intimidating. Look how much this guy just really knows what he's doing. I am not sure I'm going to be able to follow this at all.' But it didn't take long before you rammed your face into the door a few times with the same kind of stuff that trips me up. And somehow that just made it very engaging and more plausible, somehow, that I could do it. Do you know what I mean? I don't know if that makes sense. So I think that's motivating. You struggled a lot in that, right? I watched it. I don't know if that's common, but there were things that you knew that you didn't have to look up. You were doing it like riding a bike. You were so fluent in it. That stuff was cool, but honestly, the parts where you struggled were just so relatable and watching you work through them, I was like, 'Yeah, that's exactly what I would've done, too.' And one by one, you just have to step through the things.
Andreas Kling: Yeah, totally. And I think that's one thing that many people who make programming content, video content in particular, they make the wrong choice by editing out mistakes and trying to look perfect and fast and right all the time. Because as you say, then it just ends up looking intimidating or too polished, and you don't get that human side of it. You've got to show the frustration and the stupid mistakes. At least, I really feel like that's how I've been able to build an audience is by just showing the whole thing, with warts and all. And yes, that is representative by the way. I do screw up in every single video.
Brian Kardell: Well, in life, too. It's pretty easy to screw up. I think it's important to keep in mind. I am really, really excited about seeing where this goes in the rest of my lifetime, basically. Not in the next six months, although that's also exciting. But to see where all this develops because KHTML runs the world now, and it sure didn't start that way, right?
Andreas Kling: Yeah, indeed.
Brian Kardell: It took a very long time.
Andreas Kling: These are very exciting times right now, I think. I'm super excited that Servo is back on the menu. It's so cool that Igalia has picked that up, and I don't know, it's just exciting and it's going to be fun to see who makes progress on what and who hits which milestones first. And we can have a little browser war, even though...
Brian Kardell: Yeah, it could be that. I think that currently, they're hard to compare.
Andreas Kling: Yeah, definitely.
Brian Kardell: Because they had such different focus.
Andreas Kling: I always understood Servo to be an experiment, above all.
Brian Kardell: It was.
Andreas Kling: And I think a lot of great things have come out of that. And I hope that they carry that forward and continue to be experimental, or experiment friendly at least, because there's so many things that you could do in a browser engine that is very inconvenient to do in the big engines because there's so much code you would have to rewrite just to try out new architectures and new ways of doing things. One thing that I thought of in this area is that one of the things that we try to do with our browser and with our engine is that we try to write it as close to the spec as possible. This is a bit different from the way other browsers are made, at least the ones I've been familiar with, like WebKit, Chromium, and Gecko, where they are happy to invent their own abstractions and solve things in their own ways. We are very, very hardcore about sticking to spec architecture and spec language and using the spec names for everything wherever we can, in part because it makes it just easier to implement the spec, if you write it exactly as the spec says to the fullest extent possible. But also for maintainability, because we have to recognize that the platform is alive and it keeps changing and keeps mutating. And if we want to have a chance to react and adapt to future changes, I really believe that we'll be in the best position to do that if we keep ourselves as close to the current spec as possible. So, we are... In HTML. For example, we have our class names in C++ are just the same exact words that they use for the same concepts in the HTML spec. Our CSS layout engine is organized around formatting contexts, unlike the way it works in the other engines where they invent their own ways to do layout. And it's just a theme throughout. And we also take it a step even further by copying spec text word for word and just copy pasting it as comment into our code, so that you can always cross reference the spec with the code because we have the spec right there. So it's interleaved. So you would have a spec comment that says like, 'Step three, do X, Y, Z.' And then the code, X, Y, Z. 'Step four,' and so on. And it took a while to convince ourselves that this was a good way to work, because it makes the code a lot bigger and it can look bloated. But after we got used to it, I don't think we would ever go back, because it's such a much easier way to stay on top of the spec and what the spec intends, and to be able to react to changes.
Brian Kardell: Martin made a similar comment actually, because I guess this is a thing in Rust... I'm sorry, in Servo, at least in the newer. So, Servo has two layout engines, and I guess this is something that it seems all of the engines have learned and started changing to do that.
Andreas Kling: Yeah.
Brian Kardell: Martin, he seemed to suggest that this is basically a lesson that all of the browser engines have learned. And it's hard to... We can't just rewrite them, but we can migrate them in that direction.
Andreas Kling: Right, and for us, it's a lot easier to do this because we are in a green field environment. We don't have a huge stack of code that needs to be rewritten. So we've been able to make really good and fast progress towards this, and that's really nice. But of course, the others will catch up, and I think it would be great if more engines look more like the spec because it will be easier to cross reference and catch bugs and so on. And it'll also be easier for people to move between different engines, and people with special interests who want to implement a feature in all engines, the more the code looks like the spec everywhere, the easier it'll be for them, as well.
Brian Kardell: So, Serenity is currently, has been, anyway, a passion project, basically, for everybody. We want to do it because we believe we can do it, and we want the outcome. This thing where it's not disconnected libraries, but do you see that there are potentials for it to be something more than that? Can you imagine use cases for Serenity that it could be a practical choice, or Ladybird, where people could use it for no other purposes? WebKit is used for lots more than Safari.
Andreas Kling: Well, for me personally, with Serenity, I just want to build an operating system that I can use. That was always my goal since day one. And I'm happy to welcome other people into the project with their own goals, who want to adapt it to something they want to do. But for me personally, I just want to make something that I can use as my daily driver. And I have pretty simple needs. I just need a terminal and a browser and an IDE. So, they're reasonably easy to satisfy.
Brian Kardell: Your videos, you're not using Serenity to do your code and... Are you?
Andreas Kling: Right. I do not, because it is not practical. We don't have the ability to record video and we don't have USB webcam support. And also compile performance is not as good on Serenity as it is on Linux. So I just record on Linux because it's more practical. I tend to be a very pragmatic person in all these things. Honestly, recently I'm focusing way more on just building the browser in a cross-platform environment. And it's still... Everything I work on is still part of the operating system. I've just been swept away with the fun of building a browser that might potentially be useful to more people than just myself.
Brian Kardell: Yeah, right. Yeah. Well that's what I was thinking with... The more useful you can make it to more people, it seems that you get more contributions, which then makes it more useful to more people and so on, right?
Andreas Kling: Yeah. And I think it's important to be realistic, and realistically, SerenityOS will never be something that's used by millions of people, at least not with the goals that we currently have for it. And with Ladybird, that's much more of an open question, I think, because it's much harder to tell the future. We have great momentum. We're making great progress, and who knows how long we can keep that rate of progress. What will be the first major roadblock? What kind of problems will we face? Who knows? But it's exciting to run towards it so we can see what's there.
Eric Meyer: I think that's actually a good place to wrap it up.
Brian Kardell: Yeah. Okay.
Andreas Kling: Sure.
Eric Meyer: Andreas, thank you so much for spending your time with us and sharing all of these insights. Really appreciate it.
Andreas Kling: Yeah, of course. Happy to meet you guys.
Eric Meyer: Yeah. And then what we usually ask is where can people find you on the inter tubes?
Andreas Kling: Oh, well, I'm on Twitter as AwesomeKling, and also on YouTube as AwesomeKling.
Eric Meyer
Brian Kardell
Andreas Kling