Ujjwal Sharma: Hello, and welcome, everyone, to another fresh new episode of Igalia Chats here with us today. I am Ujiwal, developer advocate at Igalia, and an old-time JavaScript parent.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia, and someone who's been using the web for an unconscionably long period of time. We have special guests today. So, let's start with you, Rakhi. Can you introduce yourself?
Rakhi Sharma: Yeah, sure. Hi, I'm Rakhi. I'm one of the Servo maintainers. I'm also in Technical Steering Committee of Servo Projects. These days, my focus has been adding support for DevTools in Servo.
Eri: Yes. Hi, I'm Eri. I'm also a Servo maintainer, and I work with Rakhi in adding that tool support.
Eric Meyer: So, as you might've guessed, listener, we have two people from the Servo team who work on DevTools, and that's what we're going to talk about today, is Servo DevTools. But just in case someone is listening and they're not super familiar with Servo, can you explain what is Servo and why do we work on it? Why does Igalia work on it?
Eri: Yeah. Servo is a really cool browser engine. It is written in Rust. It is parallel modular design for embeddable systems. It has support for many things like WebGPU and other APIs. And it started to be developed in 2013 by Mozilla, but now it's part of the Linux foundation, and Igalia plays an important role in developing it.
Rakhi Sharma: So, I would add a bit on why Igalia works on it. Like Eri said, Servo Project started at Mozilla Research, where the Rust Foundation project was also getting just started. They were almost like siblings at that point, where a team was working on the Rust project itself, and then another team was working on Servo Project. While the Rust programming language was getting implemented, Servo team was using the Rust language in Servo itself, and giving feedback to the Rust language team on what kind of things they can improve, or what kind of things Servo needs. So it was a research project at some point. And while we all know where Rust language is itself, Servo went through quite a bit over the years. And fast-forward how Igalia is working on it, back around in 2022, Igalia was approached by some people who were interested in restarting the project. Well, Servo is a cool project and Igalia is a place for browsers. We work on Chromium, we work on WebKit. So, Igalia has many people who are experienced browser engineers. So, Igalia is the best fit. I don't doubt why Igalia was approached at first place. So, that's how Igalia ended up restarting the Servo Project in early 2023.
Eric Meyer: Yeah, very cool. And I know there's a lot of interest in Servo, partly because it's an independent browser engine. And also that because it's in Rust, it's memory safe, which there's been a lot more interest in the past few years, like literally national governments talking about how memory safe applications should be sort of the standard going forward, things like that. So, you're working on DevTools. Browsers typically have DevTools. Did Servo have DevTools?
Eri: The first thing is that Servo is not a browser, at least not right now. Servo is a browser engine. So, it's similar to Gecko or Blink, that you can build a browser with it, but it's not the main goal. So, why would you have DevTools in a browser engine? They typically are part of the browser. The thing is, as we said before, Servo is designed to be embeddable, and many developers want to have Servo and build an application around it. And it is very helpful to have tools to see what's going on in the application. So, see what the DOM tree looks like, what JavaScript is doing, and everything, like the console. The thing is these tools have to interact with a lot of different parts of Servo. Servo is divided in very different modules and such. So, it makes sense to have the digital support built into Servo, right? Into the core of Servo. But yeah, it makes sense for us to provide that.
Rakhi Sharma: Yeah. So, just to add on what Eri was already saying, there's a bit of history. Of course here, like I said, Servo is not a browser, right? It's a rendering engine. But then at some point developers were like, 'People are going to use this rendering engine.' And when you think about application layer, people who are going to use this rendering engine to build something, recently we have been working a lot towards adding support for different environments like Android and OpenHarmony. Those developers don't really need to know about what is going on in the rendering engine itself. Our aim is to be at a place where developer can just use the rendering engine to build something on top of it. So, all they need to care about is their own application. So, to fill the gap between this application and rendering engine itself to make life of developers, who are building the application, easier, we need to provide them a way to debug things if something goes wrong. We can't expect them to go to terminal, run some commands like we do. That's our job. We are Servo team, and people who are working on Servo team, they can run some commands, they can debug the RAS C++ code, right? But it's wrong to expect that from the people who are building the application. So, we were like, okay... When I'm saying we, I'm mostly referring to the Servo developers. So, like several developers back in 2014, the first commit of DevTools landed in 2014 by JDM. Quite a bit of work went on until 2017, 2018, I think, and here and there until 2020, until things happened at Mozilla, and there was no progress on the Servo Project, of course. But then, in 2023, Igalia restarted the project. And after taking it out of the maintenance mode that it was in for three years after taking it out of that maintenance mode, we started thinking that where this project wants to be in the next years. So, that's when we arrived in 2024. And Eri comes into the picture then, because I'm so happy that Eri is here, because Eri is the one who restarted the DevTools work during their internship at Outreachy. So, maybe Eri can talk more about it, how they restarted the project.
Eri: I'm also happy to be here, and happy to have done that internship. It was very interesting because it was like, at that point, most of the things were broken, because Firefox kept evolving, and since up until then they were the only ones using their DevTools implementation. They kept changing it just to fit Firefox, because if they needed to do something different or change the code, they could deprecate things or change the messages you have to send. So, we are in 2024 and you try to connect to DevTools and nothing happens. It doesn't work at all. But there's so much things that were already part of Servo DevTools, we just needed to update them a bit like the same way that Firefox updated theirs. I guess this is a good point to mention that, why we're mentioning Firefox when Servo and Firefox are independent. So, building an entire DevTools thing, it would be a lot of work for a project like Servo, and we have to decide what the priorities are and everything. And we already share some parts with Firefox, right? Stylo is the CSS engine that is written in Rust and Firefox also uses. We use the SpiderMonkey JavaScript engine from Firefox. And there's like this back and forth from the project. So, working Servo is also beneficial to Firefox and vice versa. So, when they were thinking, 'How do we implement DevTools here?' They decided to reuse the same client that Firefox uses. So when you go to a page and click right click inspect this and something shows up, that's the decline that Firefox has. Reuse the client and write a server for it in Servo, this works because there's an open protocol, they remote the banking protocol that we can use to send JSON messages between both of them. And yeah, they can communicate like that, and you get the functionality. So it's a good thing, because we don't have all of the work of creating everything from scratch, but it's also tricky because we have to follow something we don't fully control all of the time. So, that's what was happening in 2024. And mainly the first internship we did, that I was a part of, was figuring out what broke these years and starting to getting it all together. We got the inspector working again with the DOM tree, the console, the different connections and everything, JavaScript evaluation. So, after that, it was in a good point again. You could do certain things, but the features were still a bit basic. So, work continued after that.
Rakhi Sharma: I think after Eri's work on DevTools during their Outreachy internship, we saw that there could be more, there is more that we can do there. So, we ended up continuing the work Eri did during their internship. And we mostly had to decide what is the priority right now, because during Eri's internship we saw that, okay, Inspector tab is a good place, Console is also kind of working, and DevTools is not panicking a lot. So, that meant that we could implement more features. We had less of broken things, and more of missing features. So, another Servo team member, Dylan, she and I were working on it together when we decided that we're going to focus on Debugger Tab. And it was a bit of challenging work at the start, because we needed to decide, how do we communicate with SpiderMonkey? Do we communicate via Moss? Do we communicate directly somehow? One thing we decided on was that we need to stay closer to Firefox servers implementation, and it was mostly because we use Firefox client and connect to it via RDP. So, when we were working on Servo, Servo has its own server for the DevTools. We decided it would be better to stay closer to Firefox implementation. So, even still right now Eri and I are working on it together, we try to stay as close as possible to what Firefox is already doing. This helps us in not breaking too many things, because Firefox can update, implementation can change, client's expectation can change, right? When we are staying close to Firefox DevTools server, we are making sure that things are not breaking when the expectation of the client changes.
Eric Meyer: You said you're using RDP. RDP, what does that stand for?
Rakhi Sharma: Remote Debugging Protocol.
Eric Meyer: Okay. I have to inject and say this is all a little bit fascinating to me, because as a web developer, and like I said at the top of the show, someone who's been doing this for a very long time, I don't think it ever really occurred to me to wonder where DevTools sit in the stack. I always thought that they were... I don't think that I thought, but if you had asked me, I would have said, 'Oh, those are part of the engine,' and not really consider that they're not part of the rendering engine, they're actually part of the browser Chrome. They talk to the rendering engine. Maybe not just rendering, but they talk to the browser engine. So Servo, as a browser engine, like if you understood more about browsers, you would expect that it doesn't have DevTools, but now we're giving it DevTools because, like you say, it's necessary if someone's going to wrap their own thing around this browser engine, this web standards engine, if you prefer, then either they have to write their own DevTools if Servo doesn't provide them, or Servo has to provide them. And it sounds like there are some standards like the Remote Debugging Protocol to help with that if someone were to write their own DevTools for something. I'm thinking a little bit of Kilian Valkhof, who works on Polypane, he's the sole developer of Polypane, which is a wrapper around the Chrome engine, and it's sort of a fork of Chromium, but he's done some of his own DevTools stuff, on top of the DevTools that Chromium usually... I'm sounding more and more lost obviously, because again, this is not a thing that I necessarily ever would have thought of. I would have said, 'Oh yeah, DevTools, they're just part of the thing,' and all the browser Chrome has to do is like skin whatever the DevTools are reporting, but that's not at all the case. So we're having to do that here. That's interesting, does that strike you as a huge shift to take that DevTools stuff and put it in the engine? Is that a thing that browser engine should start doing more?
Rakhi Sharma: So, I share your confusion. I want to start from here.
Eric Meyer: Okay. I feel better.
Rakhi Sharma: At some point in my career, I was a frontend engineer, right? I used DevTools a lot to debug pages, to debug JavaScript code, to debug my frontend application. And it was a huge switch for me, because I have a bit of interesting background here, I would say, but calling it interesting myself is a bit weird here. Back in 2017, I interned on Servo Project via a program called Rails Girls Summer of Code. My team was interning on Servo Project. And I was working on rendering engine. I remember my work was about adding image API support in Servo rendering engine itself. And just inserting a very interesting thing here, my mentor from 2017 internship, I just met my mentor last week at Igalia Week after nine years.
Eric Meyer: Oh, wow.
Rakhi Sharma: And yes, my mentor is still maintainer and co-developers of Servo Project. But why I'm telling you this story is because I was still a student when I interned on Servo Project, and then I went on in the industry, and I worked as frontend engineer, backend engineer, full stack stuff. I did all of it before coming back, again, to open source and starting on Servo Project again back in 2023, when Servo Project really started. So this is why I share your confusion here, because for me, I was also like, 'Oh yeah, DevTools is part of browsers, it's not the part of the rendering engine.' And then here we come, and we are having DevTools for Servo. But I think maybe Eri can talk more about this in a bit, but what I want to say here is, like we were saying, that browser a rendering engine can have a DevTool, but DevTools is something that is very independent in a way. There are many projects around, like there is a Gecko RDP project that is emulating DevTools, and they are also connecting to Firefox client via RDP. So, I personally don't like to see DevTools as something that is very much core of a rendering engine. I personally think DevTools itself is a way for developers to provide other developers a way to debug their applications, right? So yeah, maybe Eri can talk more about DevTools and Servo stuff.
Eri: I think I understand where all of this is coming from, and I share it too. I think the key thing is separating the client part of DevTools, and the server part of DevTools. So, what most like frontend developers or regular users see is the client. So you see the different tabs and such. And yeah, they work like magic in a way, you don't have to know how the rendering engine works underneath because you're familiar with the concepts of an inspector, or a debugger and such. But that part probably shouldn't live in a rendering engine. There has been talks about like, 'Oh, what if we show the client in Servo?' That's much more difficult for other reasons because it's very specific to some Firefox APIs, but it probably wouldn't make much sense for Servo itself. It's good if for a browser using Servo, but for Servo itself, we don't really want to add anything like that. It's not needed, or it's more maintainer burden. But you need some way in the rendering engine to be able to make the actions, and get the information, and connect with the client, right? So, how does the client know about your page structure and the DOM tree? You have to send that. How do you post when it's a breakpoint? You have to go to the JavaScript engine and say, 'Hey, you need to post here.' So DevTools is, yes, the client that you see and that you can interact with, but also the glue code that exists in the rendering engine. And that's the interesting part for Servo that we need to have that. And how they talk, yes, Firefox uses this remote debugging protocol. Chromium has a similar thing, but it's a bit different, and that's the thing. It's not like a web standard spec, it's more like each browser builds its tools and such. It would be great to have it more specified than if different browsers could agree, because that way, yeah, maybe we can also use Chrome DevTools on Servo or different projects entirely. There's nothing that is preventing us from using Chrome DevTools, but since the messages and everything is different, we will have to do the work twice. So, it is a bit more complicated. So, it's like Firefox for historical reasons, but...
Eric Meyer: Rather than have to write a whole translation layer, you'd rather just talk to the...
Eri: Yeah.
Eric Meyer: That makes sense. What have we needed to add? What wasn't there that we've added?
Rakhi Sharma: So like we were talking about, Eri's Outreachy internship, right? So, during their internship, I think they added support for... I think in a way it was already there Inspector Console. Some bits were already there, but you cannot trust those bits. That was the problem. Things were broken after many years of no work there. So, Eri's work helped us to get things going, to get things restarted. Their work on Inspector Console was great. So, this gave us way to do other tabs like Debugger Tab, network tabs. And there are many more tabs that we still need to do. But right now we have a pretty good working version of Inspector Tab, Console Tab, Debugger Tab, where you can set breakpoints, view the scopes, view the call stack, walk through your JavaScript code, print something in the console. You can also preview us functions, the values, eras, map, objects. You can do the same in the console as well. If you write some object or map in the console, you can play around with some code in the console. And I am personally very proud to see that when you are setting breakpoints and you're walking through the code, it's not panicking. That I feel like is an achievement for Dylan, for Eri, and for me even. The whole Servo team. And of course, we also had some outside contributors sending PRs here and there for the DevTools. So, I'm of course thankful for them as well for helping us take it to a place where it is right now. Oh, I'm forgetting one thing. Not to forget, we also have network tab that works really great. After Eri's Outreachy, we had another intern in 2025. And there I did support for Network tab. And this is also a good space. And then recently, another contributor added support for a style editor tab, where it is still a basic support, but I would say basic support is still better than having nothing. So, I absolutely love it.
Eric Meyer: Style editor... Yeah. No, that's very cool. You said that the Network tab is like really good. What leads to that characterization of like really good? What is it that's sort of outstanding in your eyes?
Eri: It was really nice to have the second Outreachy intern work on that, because I think like before either it didn't work at all, or I think it was actually displaying wrong information, like just placeholder things.
Eric Meyer: Oh, okay.
Eri: Being able to see the actual Network events, and see the calls that your page is making, see the resources is loading is very important, and especially when you're trying to optimize times and everything. And I think the Network tab is one of the most fleshed out things we have. It displays a lot of the information, the headers, the cookies, the timings. There's still a few open issues like with everything, but it's in a pretty good shape. We almost didn't have to change anything there. So, it's pretty nice.
Eric Meyer: Yeah. And I would imagine that the Network tab would actually be pretty crucial in embedded solutions, where Servo has some strengths to be able to see how many times are we hitting the Network, what are we hitting the Network for? Oh, we forgot to have these user interface elements be local instead of trying to go over the Network for them, we need to move those in here. Yeah.
Ujjwal Sharma: I feel it's so interesting that within this space, and in general, we talked about Servo in the context of engine diversity, and it's pretty useful from that perspective. Also love to hear how the DevTools initiative itself is so diverse. We have all the different folks, contributors, volunteers, interns. But because it's not an end user product, because it's just a rendering engine, how does it gain adoption? And you mentioned that DevTools is a great and compelling way to get people to adopt, especially the people who are going to use Servo, which is embedders, researchers and such. Do we have more adoption since then? And do you think DevTools is in general crucial for adoption?
Rakhi Sharma: Yes. Actually, the answer is yes. We do have people using DevTools, and we are also happy to see lots of folks coming in and reporting even bugs. They are trying out DevTools like Debugger Tab, Inspector. I think Eri can talk about the kind of bugs we have seen on the Inspector Tab, because I think they have fixed a few there. I have fixed a few on the Debugger Tab, but we did have quite a bit of bugs being reported after we landed initial support. And I also feel like there were times when people tried to run bigger websites and use DevTools there. It was such a nice feeling for me personally, because this is where DevTools is right now. We need more people to use DevTools on different kind of websites. We have lots of tests that we have written for DevTools. We have many features now. So, one of the things that we really want is people to use DevTools and run different kind of websites, big, small, I don't know, full of like PSEOs, and images, so that we know, slow website, fast website, so that we know what is broken. At this point, DevTools is literally at the point where we would love to see people trying it out on different website and reporting bugs. But yes, we were quite happy to see there were some reports where they were like, 'Oh, we used this particular website and it was broken.' And then it turned out that that website was huge. And when we tried to reproduce those bugs, we were like, 'Wow, this website is huge.' And if they wouldn't have run the website and then opened DevTools, we probably wouldn't have discovered this bug. So, it was really nice to have that bug reported.
Eri: And also on adoption, I think it's great to see that it helps Servo developers themselves, because on chats with different people, not only from Igalia, but other developers working on Servo, they are like, 'Oh, it's so good that the Inspector is working out.' Or, 'Oh, great. We have FAT debugger,' 'I was trying to reproduce this issue and it helped me with this because I can see what's actually going on.' And yeah, I think it is helping us making Servo better. It's like a nice feedback loop.
Eric Meyer: So, we do want people using it, but it's not a browser. That is a little bit of a tension, I have to say. What would be your recommended or preferred way that people use Servo if they're not literally developing a project on Servo? What would you like to see them do?
Eri: That's a very nice question. And I think the answer will be different for everyone. For me, Servo is a very nice project. And I think I can see a lot of use cases that I would love Servo in, but I guess it depends a bit on what people want to make with it. There's the embedded use cases, small devices, et cetera. But on area that I really like about it is, you called it before web platform browser, web standards browser or something like that. I think it has a lot of value that Servo being newish, at least newer than other alternatives, and being very modular, it is a really good test run for web platform specs and for implementing new things. Servo's architectures leads itself very well to doing things like isolated and in a vacuum. So for example, I have been working on MathML on different browsers, and the issue is not implementing the spec, is working with existing browsers architecture and legacy code of 20 plus years, and maybe they have been implementing different things of the specs and so on, and you have to change things in many places. I feel like Servo is much better if you want to test a spec, implement and see how it would look in the web, because it allows you to do it very minimally and cleanly, I would say. So, even if there's not a browser using Servo yet, there may be applications using it in the future. And it's a great place, I would say, for people... I don't know, if you have a very interesting spec and you need to test it somewhere, why not test it in Servo? For that, you might want to inspect it as an end user and see what's in page. Going back to MathML, you might want to check which characters have been rendered, the phones used. I'm not sure we support phones yet, but if there's a use case for that, we can add that to the tools. And yeah, you need some kind of tooling when you are checking these things, and I think that's what DevTools is for.
Eric Meyer: What isn't there that we are planning to add? What are some things that web developer might miss if they were to open up this inspector in Servo? And then, which of those are we hoping to add soon?
Eri: So, on big thing, and a very important one, is accessibility. Modern browsers have very good accessibility inspectors. And the Servo team at Igalia is working in adding accessibility to Servo in general, and it is very, very exciting to see how that's coming along. And I think we're making great progress, not to say it myself, but once that is landed, we will need to support it in DevTools, because we want to have users be able to debug what's going on with accessibility to see how the trees... Maybe it's even different than Firefox, but we need to have support for it.
Rakhi Sharma: Yeah. So, like Eri was saying, we have a few people in Servo team who are already working on adding accessibility tree and in general support in Servo. So, it would be really nice to have that support in DevTools as well, but it's quite early right now so we cannot start already on the DevTools support for it. So, we are really hoping that once it lands, we hope that we get to add it intervals as well. And then we also, for almost more than a year or something, I would say, we are working on performance part of the Servo, where we are constantly trying to improve performance. So, it would be really nice to have the memory and performance tab where people who are building applications can check out the memory, or record the performance of their own application. I remember a certain situation from a few years ago when we were working on Tauri, Servo had a collaboration with Tauri to try out the rendering engine as whole and what we can build. And it was such a nice collaboration. I remember I was trying to build a demo of that collaboration, and it was such a beautiful thing, because I, who was trying to build something, I just had to write the HTML, CSS and JavaScript code, and behind the scene it had the server rendering engine, right? So, this comes to my mind. Eri, earlier you were talking about the use cases, right? I was thinking about this. That time I didn't think how a DevTool can help me, but now that we are talking about it and now we have the DevTools support, I'm like, 'Oh wow, that was the perfect time, where I would have loved to see how I can inspect my JavaScript code that I built on the application layer in the DevTool.' And I'm like, 'Wow, that would have been amazing.' But it was like two and a half years ago or something if I'm not getting the timeline wrong. And that is one of the perfect use case where you can use DevTools.
Ujjwal Sharma: With all of this, I was wondering how strategic or interesting could it be for all of our goals to have a end user product built on top of Servo. We have all of these competitor engines, if you will. And one thing that's unique and special, well, not so unique, I guess, but special about all of them, is that they all have dedicated products that are built around them. So, do you think that could happen? How soon could it happen?
Eri: Yeah. I think it would be really nice. Right now there's a few community projects that are already using Servo, and there's more than one browser prototypes that are using it and that are doing really cool things like, there was a few months ago, I think, this browser prototype that had everything in the UI built with HTML, and CSS, and JavaScript, and then it had the Windows inside were like web views, but it was all running in Servo. So very, very interesting.
Eric Meyer: Do you remember what was that project?
Eri: Yes. Beaver Browser, I think.
Eric Meyer: Okay.
Eri: But yeah, there's all of these cool things. Now that Rakhi mentioned it, I really like the idea of having Servo integrated with Tauri, and using it for web apps. I think that's a place where Servo can really shine, because in theory it could be smaller, it could be faster, or more memory safe. And even things like mini apps in phones or things like that. I think we are at the point that we should be exploring the different things we can make with Servo. The community is already starting, but we should follow. And with things like the embedding API that we are working on and everything DevTools support, I think it's the perfect time.
Rakhi Sharma: I have also noticed quite a bit of interest from community to build something on top of Servo rendering engine, like I was talking about Tauri. I really wish for that project to go somewhere, but we all know the problem. Web has a funding issue. We all know that, right?
Eric Meyer: Yeah. We've mentioned it a couple times on here.
Rakhi Sharma: Yes, yes. That is what is stopping us. I don't think it's the interest, I don't think it's the people, I don't think it's the Servo team or any other team, that is like, 'We don't want to use Servo.' I have seen people from different background wanting to try Server rendering engine, wanting to build something on top of it. I don't remember the project itself, but I remember someone tried to build a terminal on top of Servo rendering engine. We are already talking about Tauri, so it's like Electron-like app. Eri was talking about someone trying to build browser. Even recently at Web Engines Hackfest, we had two different projects who were trying to build something on top of Servo rendering engine itself. But then, if you start noticing the pattern, at the end, all of it comes back to funding, because those project also need funding to survive to take it at a level where they can release it for public usage. And yes, I personally feel like that your interest, your ambition for a project can only take you so far, you will need help from outside. So yes, the answer is interest is not the problem here, and not even the developers, it's the web is underfunded. That's the problem here.
Ujjwal Sharma: That's a fair point, and so interesting, right? A lot of us do share the sentiment about how exciting Servo is, yet it's so underfunded. What are the newer or more interesting funding paths for Servo that you have been considering or you could share with us? Is it dependent on grants or other kind of paid work? And for instance, are there other organizations that hire people to work on Servo?
Rakhi Sharma: So, in the last years, we have gotten some interest from people wanting to use Servo. And of course, we are very thankful for the grants like SDF and NLnet. They have been very supportive, and we have been able to do quite a bit of stuff because of the fundings we got from them. I think I personally, the way I see it is, if a company or an organization comes to us and they're like, 'Hey, we want to build an application using Servo.' So the way we see how Igalia, as well as Servo team, can help them, or even Servo Project can help them in a way, is that they come and tell us their requirement, and we sit together to see how we can help them. And I am pretty sure if the companies who are interested in building something on top of Servo, they come to us and then we sit together, we will find a way where we both benefit from it, where Servo team gets to add new features, take the rendering engine to the level where we want it to be, and in return, the other people can use it to build the application.
Eric Meyer: And it could be a company, it could be a non-corporate organization come in and say, 'We think it is very important for the following reasons,' whatever those reasons are, that there be a memory safe browser that does these things, it is performance, it's usable in embedded situations, and therefore, hopefully, that means it's usable in situations where the user's hardware is older and they don't have as much network. And so we want to fund building a browser for people who do not have the latest chip sets and the highest bandwidth, et cetera. That would also, I would think, be a possibility.
Eri: Now that you mention non-company entities, I was thinking like Servo, apart from being a cool project, is also a very strategic, in my opinion, project, because like the other three brochure engines are based on the US, and for governments outside of the US, or even like entities like the European Union, it could be nice to invest in something that is not controlled by a company there, especially something as essential as a web browser. Because if you are not familiar, maybe you wouldn't consider a web browser an essential thing, but we do so, so many things through a web browser. Everything is through there. It's a critical, critical piece of equipment, like maybe even to the same degree as, I don't know, an airplane, like control. But maybe it's not as apparent, but we do have to fund this. And it's good to have some sovereignty with our critical infrastructure. So yeah, it could be great to receive more funding to push that goal. Yeah.
Eric Meyer: So, how do we keep Servo relevant, sort of up-to-date? What are the challenges there?
Eri: So, on a broader scope, like keeping the entirety of Servo relevant, is complicated, again, because of funding. We are trying to do our best, we are trying to push features, but it's not only pushing features, it's maintaining and fixing things. But we are competing with huge cooperation with unlimited money, basically. So, to keep Servo relevant is to invest in it. We need more funding. But going back to DevTools, this is a very important point, because we saw what happened in 2020. And in a few years we lost track of where Firefox was, and support broke, which is what happens when you rely sometimes on third parties. I think we're in a much better place now, and we are even in contact with people at Firefox that want to push to make this more of an easy process for both sides and to keep it in sync. So, a few things we are doing to keep us up-to-date. One is pushing for testing. The web has the web platform test, and JavaScript test, and everything. We also need DevTools tests. We have been writing a lot of them, and we are planning to write many more. It's the only way we can make sure that we are following things and we are not breaking things with updates. But maybe it's also good to push for this unified DevTool spec. We can start with Firefox, because even if it's called a protocol, it's not super specified, or it has gaps, and it does a lot of internal things. So, if we can get that to some kind of semi-standardized thing that we can test properly and we can implement properly, that would be a huge win, and who knows, maybe in the future we can extend it to use with other browsers. And there's things like WebDriver Bi-Di and other things that could be really interesting here.
Eric Meyer: So, a specification that describes how DevTools should work, how DevTools should communicate with the engine? I just want to make sure I'm clear.
Eri: More like on how DevTools should communicate, because in the end, every rendering engine will be very different under the hood, and Servo is very different from Firefox and other engines. But if we can have an idea of what DevTools is supposed to be, and what tools does it have, because in the end many browsers are using pretty similar tool, and inspector is an inspector, debugger's a debugger. If we can have like those standardized, I can see us being able to switch clients and servers, and maybe independent tools to raise that can help very niche cases that maybe are not covered by the browsers. And yeah, for that, we need a better way of handling this.
Eric Meyer: That feels a little bit like it's coming full circle, because the first DevTools that, at least that I ever used, were Firebug, which was not part of the engine, but it sort of laid the patterns or the foundation for what DevTools have become. And this seems like we're coming back around to, okay, well, we can have the DevTools be separate. They can be their own thing. And I mean, it even sounds like in a world where this, like we have a fully fledged DevTools specification, someone could write a completely standalone application that talks to a browser and does its own thing. So your inspector could actually be not in the browser at all. That's fascinating. I love it and I'm wary of it, but I think more I love it.
Rakhi Sharma: I was just thinking that another perspective of it is like how rendering engine is already working. Eri was mentioning that different rendering engine is working differently, right? So at the core they work differently, but at the end they're going in the same direction, right? They're trying to provide the same experience. And why it is possible? Because of specification. Doesn't matter which rendering engine you work on, you are reading the same specification. So as a developer, mentally I am like, yes, even though we are not working on same rendering engine, and then we are reading the same specification. So, another perspective of what Eri is saying, can we do same for DevTools as well? Maybe I'm not sure if Eri would agree with that, but I saw it that way
Eri: Yeah, yeah, that's exactly it. And I would love to see that. And I'm all for more modular software where it's not everything centralized in one tool and you can't easily modify it, because in the end, the web is used everywhere. And we have many users, many different perspectives. And it's obvious that all of the user's needs are going to be very different. So, we can try to create one tool to rule them all, but it's much better if you give people the freedom to modify and customize and do small tools that are really important to their workflows.
Ujjwal Sharma: I think between this direction, which is excellent, and I do feel like the software space that we're in is moving towards these values and at the risk of sometimes over-specifying things, specifying more things, and changing where the line is drawn in terms of DevTools versus browser stuff. We're now specifying source maps. Back in the day, somebody would say source maps is not an end user concern. I think we should be able to specify DevTools. Why not?
Rakhi Sharma: Now that you are bringing up source map, source map was something that caused us huge bug in the DevTools and we had to spend hours trying to just find the bugs, trying to just reproduce the bugs.
Ujjwal Sharma: And that's why it's great that we now only have one kind of source maps.
Eric Meyer: Very cool. Well, I think that brings us to the end of our time, but this has really been fascinating, and I'm looking forward to what the future will bring for Servo and specifically Servo DevTools. So Eri, Rakhi, thank you so much for joining us.
Eri: Thank you.
Rakhi Sharma: Thank you. Happy we got to talk about it here.
Ujjwal Sharma
Eric Meyer
Rakhi Sharma
Eri