Welcome to the 2nd Episode of JSKongress meets Friends! 👬👫👭

Live-Chat: Ah, a JS Kongress meetup you can watch in your pyjamas, if you have pyjamas! 🛋️ #StayAtHome 🏠

This time we're talking about the Chrome DevTools and beyond, where we cover different topics from

• Architecture & History

• Workflow & Quality

• Team & Feedback

• Design & Accessibility and

• WebAssembly Debugging

I'm Johannes and your host for this episode. Sending you a warm welcome ❤️ from rainy Munich! ☔

The idea behind #JSKongress meets friends is to invite people and teams, where we think they can provide some inspiring insights. You may find some inspirations, which you can apply to your routines.

For getting the questions, we've collected them upfront on the various social media channels.

I'm happy to welcome Kim, Peter, Mathias and Paul from the Chrome DevTools Team in this episode! [editor’s note: Kim Anh Tran (WebAssembly SWE), Mathias Bynens (Design & Accessibility TL), Paul Lewis (Architecture & Testing TL), Peter Mueller (UX lead)]

alert("Hello, World!");

Johannes I’d like to start with a brief warm-up question: Who are you, what are you doing, and how is it going in the home office for you?

Kim I recently joined the Chrome DevTools team. I was an intern on the Wasm runtime team before. And I work on Wasm debugging right now.

I'm doing well. Juggling between taking care of my child and working in between.

Mathias hey I'm Mathias, I used to work on V8, and now I work on Chrome DevTools here in Munich where it's still raining indeed. For DevTools I lead the efforts on Design & Accessibility. And I also work on Puppeteer, which is something we could talk about later.

As to how it's going in my home office, I'm kind of an introvert so in normal circumstances I don't feel the need to go out all the time. But now that I kind of don't even have the option anymore it sucks, so yeah I can't wait for this thing to be over.

Paul Hi, as you said, I’m Paul, I am based in London unlike everybody else. You'll be pleased to hear it is also rainy. I used to be in developer relations and then I moved to working on the DevTools team, something like a year ago, nine months ago, something like that. And I work on the architecture and testing particularly, that's my main focus with a couple of folks in London particularly.

How's it going? Well, my house is actually 🏗️ a building site right now. We decided to do some building work right before the pandemic hit, and we haven't been able to make progress for a while. So it's been weird living on a building site, and yeah I don't recommend it. But there you go, that's just life in it.

Johannes Peter, how is it going in the most colorful Home Office? 🌱🌴🌵

Peter yes, so hi I'm Peter, and Design Lead on DevTools. So previously I come from a visual design background, and then just transitioned into UX design at Google.

How’s it going at home? So as you see I'm working in a greenhouse. I decorated with as many plants as possible, so it’s going good!

Johannes all right; thanks for the quick introduction round. I would say let's kick it off, and start with the questions we've collected.

Architecture & History

Johannes the first topic is about architecture and history, so the first question is directed to Paul: Can you please give us a brief overview about what DevTools are and how they can help engineers.

Paul okay, so the DevTools is a web app primarily that is embedded with Chrome. It comes with the Chrome binary, and it allows you to inspect the current page. So it helps developers by giving them insights about

• what elements are in the page,

• what the JavaScript is doing,

• the performance,

• the accessibility,

• what styles are applied to the page.

It gives them all that insight just by right-clicking on the page and saying “inspect element” and give them all that at their fingertips.

So that's what it's there to do: It’s there to help people build web apps really on sites.

Johannes I just got notification that the first 2 minutes have been without audio so I would like to ask the first question again. This is directed to you, Paul: Can you give us a brief overview of what the DevTools are and about how they can help engineers? [editor’s note: We are giving you both versions here, because it might help to understand it easily.]

Paul yeah, absolutely let's do that one again, I would 've said. I think I said nice things about DevTools 😂. So DevTools is a web app that we ship with the Chrome binary. So actually it's a surprise to a lot of people that it is a web app. When you open the DevTools front-end you are looking at a web app. So you can actually inspect DevTools with DevTools, which is always a fun thing – like Mattias is and rightly so 😃. So it's there, and it speaks to the various back-ends that we have in Chrome for like v8 and for Blink. And it's requesting information about the page that's being inspected. So if you're building a web app or you're building the website, and you want to know

• what elements you've got,

• which styles are in place,

• what the JavaScript’s doing,

• what your performance looks like,

• and your accessibility:

We have tools in the DevTools that are designed to help you through that process. To understand your web app, and to help you through the process of building it, and making the best possible app or site that you can.

Johannes alright, thanks for answering the first question

The next question is: Do you know how the idea came up to ship Chrome with native DevTools? Some keywords like, I think, Firebug was one of the first things I remember in my times. But I'd be curious about the history behind it, how it came up.

Mathias

The reason Chrome had DevTools from the very first version is because it's a fork of the WebKit project – at least the Chromium project is.

So it used to be that Google and Apple were working together on WebKit, and at some point they realized that they had different visions for the project. So they decided the best way to fix that issue is by forking and then WebKit and Blink became two separate projects. And so basically in Chromium we inherited the WebKit inspector code, which was the DevTools at the time in WebKit. There are still the very early versions of the Safari inspector right now. And also the DevTools codebase is still based on that, so this is a code base that is 14 to 15 years old right now.

And that's how DevTools ended up being in Chrome.

But I think the question you're getting at is: How did DevTools become a thing in browsers / that ships with browsers, right?

And I actually remember those days before this happened.

I remember having Internet Explorer 4 open, going to my page, and then typing javascript:alert(somethingSomething)

just to get something to appear, or like to interact with the page in some way. Because that was the only way I knew, other than viewing the source directly, which I still do too these days, actually.

And I think yeah, Firebug indeed was a big boon. It was a browser plugin that was created by developers to fix some of these issues and to make it possible to, at least, interact with the page a little bit more closely.

And there was another extension that I remember using: I think it was the Web Developer Toolbar by Chris Pederick. It had all these cool keyboard shortcuts that I remember using. And so I think what happened is that a lot of experimentation happened in these browser add-ons, these optional plugins that people could install. And based on that, browser developers were like: 💡 “yeah, what if we took some of these ideas, and shipped them with the browser. That we could actually do some of these things in a more efficient way that is not possible in an extension” and I think that's what happened.

Johannes I'm a software engineer and I'm all the time super curious about the architecture behind. Can you give a quick overview about the high level architecture? Because like there are so many things, which can be done in DevTools from the inspector. I think everybody needs the performance measurements to so many other things so:

What's the high level architecture of the DevTools?

Kim DevTools is a web app as Paul has already mentioned. The DevTools front-end, that the developer is normally interacting with, is talking to various back-ends in order to accomplish various tasks.

So one back-end, for example, is the v8 back-end. The v8 back-end is basically everything that answers to JavaScript and WebAssembly. If you are typing in an expression that you want to evaluate, it's the v8 back-end that we are talking to.

Between the front-end at the back-end there's the CDP, it's the Chrome DevTools Protocol. The CDP is specifying the methods, requests and responses that can be used in order to communicate between them.

And the DevTools front-end is not the only one that can actually use CDP in order to control Chrome. One example that was already mentioned before by Mathias is Puppeteer. And Puppeteer allows you to write end-to-end tests in JavaScript by controlling a Chrome browsing instance, for example.

Johannes So DevTools is not only for web apps as we know. We can debug our Node.js applications as well. What's the history behind extending the DevTools or making use of Node.js debugging?

Mathias okay I guess I'll take this question. So as Kim explained, there's this Chrome DevTools Protocol, and there's really no reason why only DevTools should be able to send these commands to the backend -- anyone can do it. That's why we also have Puppeteer as a library, which is a wrapper on top of the Chrome DevTools protocol that makes it very easy to use this, and to drive a Chrome instance from within Node.js using a very nice and modern API.

The same thing applies to Node.js: Once you know about this protocol, and specifically for Node.js, you probably mostly care about the JavaScript part of the protocol. So things like setting breakpoints in your code and evaluating a snippet of JavaScript, you can have the same possibilities that DevTools already supports within Node.js, as well. So through this protocol, it's now possible to use the DevTools UI to debug your Node.js code instead of the web apps that you're usually inspecting. It's just a matter of sending the proper commands and interacting in the right way that is described by the protocol.

Johannes Are there any numbers? Do you have any numbers about the usage, how the DevTools are used for debugging node and for debugging web apps? Do you collect any numbers?

Mathias I mean Chrome has this. Chrome can collect some telemetry if people actively opt into this in an anonymized fashion. So we do have some measurements. But I don't think we have a metric specifically for this, in fact the metrics that we have from within DevTools are fairly limited as far as I know. And this is actually one area, where I think we can improve a little bit. Because if we have more fine-grained details about which panels are the most popular, we can figure out where to invest more of our time.

Johannes Is there an API I can use to automatically use DevTools features on a given Chrome?

Mathias oh yeah, so this goes back to Puppeteer a little bit. Because many of the features you would find in DevTools are things like: I want to preview what the page would look like with print styles instead of my screen media. There is a setting in DevTools in the Renderer panel that lets you do this and so because it might be useful to try to do this kind of thing as part of an automated test. There's also a Puppeteer API that behind-the-scenes just sends the same Chrome DevTools protocol commands so that you can now write a Puppeteer script that says “okay, open the browser, navigate to this URL, emulate print styles, and then take a screenshot and save it somewhere for me, and that script would just be four lines of JavaScript. The same thing goes for many of the features that you will find in DevTools: if we deem it useful as part of this automated testing scenario or maybe even for other use cases like creating web pages then we will add an Puppeteer API on top of the CDP API so that developers can easily use it.

Johannes okay, so when I'm using Puppeteer for my end-to-end tests I can make use of not all but some of them, and automate them as well – that's pretty cool

Mathias exactly, and you actually can use the whole protocol. You can also send raw protocol commands but it's just not very nice to do so. It's nicer if there's a dedicated first-class Puppeteer API because yeah doing it the other way it doesn't feel very JavaScript-y.

Johannes We started the first question with the architecture and the history behind. So when it comes to architecture: Architecture is like living all the time. How has the DevTools architecture evolved all the last years? And what are some of the main pain points in the past or currently?

Paul Depending on how you look at it. Some of that's been around for up to 10 to 15 years and that means that the code that you have … The code that would have been written 10-15 years ago in web is very different to the code you'd write today because best practices change, new patterns, you sort of evolve, and it's just they say:

Architecture is a living thing.

Now the size of the DevTools front-end in particular. We're talking about an awful lot of JavaScript that's in play, and so it's not just a case. In fact one of the words that we try to avoid in my team, is the word “just”. Because of the size of the code base we're talking about, there is no “just”. And I'll give you one example: So recently the web got ES modules, so that we could do imports and exports around the place. Before that, there wasn't a way really to do on the platform anything that looked like modules. And one of the things we wanted to do is move the code base to ES modules. Because it's a good thing for us to have the two links that support visual studio code – it understands it really well.

But there is no “just”, so we can't just migrate to ES modules. There's a lot of things that need to change like the tool-chain. The actual code itself is written in a way that was before ES modules, and expects certain things to be in certain places. And so the largest pain point we typically have is migration. So my team is particularly tasked with keeping the architecture and the testing in a good shape. And we decided there's this new platform primitive that would help us here, would make the software better. We have to migrate everybody across to that without breaking DevTools. And that applies to the people using DevTools everyday, which obviously is incredibly important. But also the rest of the team. Because if the rest of the team is trying to work on the DevTools code base and we're busy just changing the architecture, we could break their patches, and we could break their workflow. So we have to be very careful about how we do it. And we have to do it at the scale of a very very large web app so it's constantly evolving.

As you said, it's challenging to make sure that we make decisions as well that will have a long lifespan. Because at the scale we're doing them, when the time scales it takes to get them done. But what we don't want to do is make a quick decision that though we would have to undo later on. So we sort of constantly try to understand how much a technology would give us, if we returned it to use it. And then as we migrate people, to make sure that we don't break anybody, which is always a challenge.

Johannes migrating in architecture – that's a good keyword for the last question for this topic. In my team the last weeks, technical debt is more and more a topic. I'm curious: How does your team handle technical debt in this scale and for this lifespan?

Paul it's a constant question. I think that's the way it goes because the best practice today can be tomorrow's tech debt. And I don't mean that rudely. Doesn't mean anybody is coding badly at that point. It's just that things change, and things do get better. And you can look at tech debtors “oh somebody made a mistake”. But often that's not what it is – often it's the constraints they had at the time. And sometimes the platform didn't support the thing they wanted to do. So in our case – sort of to repeat myself I suppose a little bit – we try and take a very tactical view on it. Is that thing just different, or is it actually bad in some way? As in, if somebody's had to code around a problem, that the platform didn't do something. And is it worth fixing that or is it worth delaying that until some other things are in place?

So we're forever having conversations, and that's actually the main thing I think we've just hit time and time and again. It's so much about the conversation, about making sure that people both understand the trade-off and the trades that you're making back and forth. Like “we're not going to fix that now, because we'd like to do this instead” or “we think we should fix that next” or “we should change that over there”. And then trying to just make sure, as I say, that you do it in a considerate and thoughtful way so that you don't break anything. But there is no sense in which you're going to go “right, we're done”. Because while the platform moves you're gonna have new things to try, new tools that you need to add. If you're us we're adding things to the product, we're trying better ways of working. And that just means that inevitably there's always going to be some form of change that you need to manage.

Workflow & Quality

Johannes One of the most interesting questions, I think a lot of people are having, is: How do you build the UI of the DevTools? And are you using any libraries therefore?

Paul I'm fortunate you are hearing quite a lot from me, so I can only apologize to everybody that you’re getting a lot of Paul-time [Live-Chat: “We love Paul-time ❤️”]. My team was probably gonna nod along and like “yeah we hear from him a lot” but:

How we're building the UI? Well, I think our constraints are not unique. But they are probably unusual in the sense that the DevTools front-end is a long-standing web app. And that means that we need to pick technologies that we feel have the same the next 10 years in them or more. And so our preferences are normally to use the platform primitives where they're available because

the platform moves at a slower rate than libraries and frameworks

And anybody who's worked on the web for a while knows that the rate of change in the web is extremely high. And that means that if you were to pick a library or a framework that's popular today in a year, two years, five years, you might find that it's not. And at the scale that we were talking about before in terms of tech debt and change, that would be perhaps an unwise technical decision. So that's the kind of the background philosophy or most that we have.

The second thing that we want to do is, we want to maintain control in the sense that we need the flexibility to do certain things at certain times, and know that we're going to do certain tasks at certain times. And so if you find that a piece of software – say a framework – is going to invert the control, so that it calls you rather than you call it, then there's a potential problem there. So we do libraries and we do want to use libraries, and we do make the best use of libraries where we can – generally speaking. But the idea has to be, that not only is it that we think it's maintainable for the long term. Secondarily, if we need to replace it with something else, that we can. And thirdly, it allows us to maintain control over the life cycle of the application, so that we can call into it, it will do the task, and it will come back. And if there's a problem with it, we can swap it out and so on. I hope that answers the question.

You can look through the DevTools code base if you want to see the kinds of libraries that we are looking at.

Johannes Regarding quality and workflow: How does your Q&A look? Which actions are you taking in order to ensure you ship the best possible quality?

Paul this is another one for me isn't it? Well, testing… I mean, this is not the most exciting answer that you could imagine, but it is the most sort of truthful – I suppose:

if you don't write tests you don't know what your software is doing

And that means that writing high-quality testing, and investing in your testing and infrastructure and your architecture and those kinds of things, are the long-term best play that you have. Now we also happen to have a wonderful community of developers [❤️] generally, who give us good feedback. And that's actually really helpful for us. So we can speak to framework people. We can speak to web developers in all kinds of walks of life. And that gives us a fairly good signal on what they are struggling with, what they care about. So we can use that in combination with the fact that we're trying to build high-quality software with good testing and infrastructure that supports us. That sort of hopefully comes together into something that genuinely adds value to everybody every day.

Johannes The discussions and the feedback you're collecting: Where is this communicated? Do you communicate that on github as well, where the whole source code is available?

Paul how do we communicate with the framework people, with the library people in order to collect the feedback? It tends to be a lot more ad hoc. So we will tend to set up calls with people if that makes sense. Or sometimes we will just simply look at what they're creating. I mean, there are some wonderful tools for Vue and React in particular that augment the DevTools. And that gives us a fair idea of “hey, what are these people trying to get done, what things make sense in their world”. So it's a fairly informal thing, I would say.

Johannes When you add new features to the DevTools, what's the workflow behind? Who is structuring the issues or the feature? Who is taking care of the requirements? Who is doing the UI and the UX? Is there a big testing ongoing? How do you handle new features like the rough workflow from the idea until it gets shipped?

Peter that sounds like a question for me. Okay, so I'd say, the design process and DevTools, or the process from idea to productions for the unit. So it's definitely not like the traditional process, a top-down design team, and that created designs, and having enough developers. And at some point it's unstable. So it's rather more on the opposite way around, looks like from the bottom up. So you can't develop such a super complex tool just by your own. Probably not even a team alone has enough knowledge to cover everything. So you constantly need to collaborate with experts, not only at Google but also other companies, other browsers even.

So really interesting, well so we have like a tool internally to make this collaboration happen just called “the design docs”. It's basically just a Google Doc and after a certain four hours format. So everybody can start such a design doc and just write like a basic outline, what your future might look like. And we use this a lot to collaborate with experts on different topics because usually it gets so technical we really need expertise outside of our team. Even or especially if it's about security and so on. So everybody can come up with such a design work. Ao there's not like a single person that sets up the roadmap but you can already imagine there is a lot of stuff coming up. It's like everybody is fighting feature requests and like that. Some days there are so many design docs just popping up I can't even read them all. So you need some workflow to focus, and we also have this in place. So we define our focus area for each year. We want to improve that to it. So for example in this year's design and accessibility or WebAssembly is like a huge topic, we want to focus on them. And if we find a feature that plays into one of those areas, we prioritize it higher, and we spend a little bit more time on this. Ao it doesn't mean that we neglect everything else but we have like all photons. So in a lot of features, in general all, ourselves happening under the hood.

So not everything is involving UI but sometimes, my job is just to take a loop, and find out in which part of the workflow makes sense to service something. Where we can actually be useful for the developer, not intrusive. So sometimes it's really just about making sense of things. And this all happens in design docs so. But yeah this all doesn't end in production. So eventually the design doc hits. One of those focus groups is “develop and relent and Canaries”. So “canary” is like our free beta build. Everybody can try out, and we test functionality in canary. So it's like a safe playground for us to get early feedback from the community. So the user group is large enough that it's meaningful feedback, but also it’s not that stable. One won't break everybody's browsing experience and monitor all the feedback from canary really closely and start iterating on and on to ensure that it's stable. So yeah, I'd say this is like a rough outline of our “feature comes to production”.

Right, and for people, who really want to try out what stuff will burn and look in the next upcoming versions

Johannes Are you making use of any workflow related KPIs? Are you measuring the team performances and if so, what's your model of measuring it?

Kim yeah, KPIs and these Objective Key Results are set for the quarter for example. These are the ones that we want to achieve until then, and that's exactly what we use in order to measure the performance.

Johannes How do you involve the developer community's needs and wishes when it comes to new products features and involvement?

Peter I mean it's pretty difficult. It feels like such a huge user base to really go down to the individual. But we always try to be really close to our user base. So what helps us to demonstrate are people and dev relations positions. They really foster relationships with their community. And help to understand the opinion that’s out there. And what's really bugging people. And what's really in demand right now. And make it actionable for us. So we don't need to go through one gazillion Twitter feed to really filter out. But in general the whole team has a close look on Twitter. And the general vote comes into the factory post in the Chrome box. So this is generally how it will be written so it is monitored closely.

Johannes another question regarding the team and the feedback: Do you stay in regular contact with the engineers, with the product managers, and people who are working on other browsers’ tech tools?

Peter well, actually yes we do. I think this might come like a surprise to some people. But it should be like in regular contact with most big browser vendors. So especially if we like to develop a new feature for something lately we had experts like engineers from Firefox, and with us in it, we had UX experts and engineers from Microsoft in there as well. So yeah definitely something like DevTools doesn't happen in a vacuum. And we are very well-connected with others.

Design & Accessibility

Johannes Layout debugging has been one of the weak spots in Chrome's DevTools, and in particular Firefox DevTools have done a better job here. Do you have plans to tackle that?

Peter yeah it's definitely true. I mean Firefox did a great job doing this. I especially like the great implemented fkex interpretation. But I think I mentioned earlier, design is one of the key areas. And we have been working really closely with Microsoft over the last month. Actually on written documentation, which is actually pretty cool. Tomorrow [editor’s note: April 29th] we will demo our first preview of CSS grid. So if you want to see it you should really take a close to our account, because people demo it tomorrow.

Mathias the team’s Twitter account is @ChromeDevTools

Johannes Take a look on Twitter if interested in the twitter handles from Peter, Kim, Paul, and Mathias.

So the next question is also design and accessibility related: You recently shipped support for color vision deficiency emulation as a means to improve accessibility support. Can you provide some details here?

Mathias DevTools help to optimize your websites to pick a color palette that is accessible. And so by adding this new functionality to DevTools, where you can almost put yourself a little bit closer to being in the shoes of a person, who suffers from such a thing. You can now visually see what is going on and how they might experience the colors that you choose. And so by doing this and by simulating several of these color vision deficiencies you can ensure that what you design is accessible for everyone. Not just for people with perfect vision.

Johannes there is one question specifically to Peter: What or how you think you can improve the Chrome DevTools UI?

Peter right, so at the moment how we are approaching this is, we are refactoring a lot of features that fills your eyes. So it's like what happens to evolve portraits: At one moment, you will edit features but you're really reluctant to remove them. Because we will abandon doing this, using it like every program; like Photoshop, the Excels, the After Effects. They all have been there at one point. So it would be like actually thinking about it. It's not so much like improving the style of like next elements but rather refactoring the UI. But so, one example is that we want to declutter the console a lot. Because right now the console's full of messages, which are not really actionable. So we want in the future to come up with a new panel: The “issues panel” actually gives you all the issues with your website and a really nice actionable format. So those are the things we have at the moment.

WebAssembly Debugging

Johannes WebAssembly launched back in 2017 but there was only very basic debugging support until recently. What is the timeline here? And what can we expect here?

Kim yeah, so what we want to do is to make sure that debugging raw Wasm actually comes along with an environment that makes sense for Wasm. So this means changing the views that are already existing, for example a scope view that makes sense for Wasm. Then, using consistent Wasm text across all our views and having a better memory view. But also to make it possible to set breakpoints across threads and allow for seamless profiling. Some of these features will already be available in Chrome 84 but others will continue to ship by the end of the year. But we also want to go a step further: We want to introduce a language server using C++ DWARF symbols. The idea behind this is that we don't only want to have access to static information but also to dynamic information. So you don't only see the C++ source code when you're debugging in C++ using Wasm. But you also have the possibility to evaluate expressions, which is very valuable when actually debugging an application. And then we want to support large-scale applications in C++ with this language server. And the plan to ship on this side is that we want to have the basic support for a symbol server with capabilities to step in C++ by the end of June from Chrome 85. But we want to introduce that with life expression support and a scope view here in Chrome 86 / 87, which is August / October. So the big difference to the current source map-based debugging approach is that the source maps only give the source location. It doesn't work within inlining, and you cannot evaluate expressions. And that's exactly what the new symbol server will be.

Johannes Ingvar announced an improved solution at Chrome Dev Summit (CDS) that uses native DWARF debugging debugging information. Is this an extension of that?

Kim no, it's not an extension. So the solution that Ingvar presented at the Chrome Dev Summit was rather a proof of concept that we can actually use DWARF information to debug. The symbol server is a new solution that we want to present. It gives you all the features that I've been talking about: with the dynamic information. And the solution scales with large applications. Because the solution that was presented before, was actually running in the DevTools front-end itself. And just handling that massive amount of DWARF data wouldn't be scalable in DevTools itself.

Johannes by the way “scalable”: Google Earth recently announced that they made the switch to WebAssembly. Debugging a large code base like that probably comes with different challenges than toy examples, I suppose?

Kim yeah, big applications also means a lot of DWARF data. And a lot of DWARF data needs to be parsed, needs to be read, needs to be found in order to find the symbol names that were used for debugging. And this is especially difficult if, for example, the data is not indexed. So that you can actually … you have to actually read through everything. We also need better mechanisms for stepping and showing big scopes. Because now that you actually have a large application, you have a huge scope. And we need to find out how to show the scope in a way that is accessible to the developer. And then there’s also profiling. Profiling with big data is also difficult.

Questions from the Live Chat

Johannes we got some questions now from the people, who are watching the live stream. Let's start with one of the first, which is: DevTools are getting more and more IDE features like editing files, mapping to the local file system, changing things in the code directly without going to the IDE. What do you think, how will this develop? I think the question is directed to you, Paul.

Paul 🔇 [muted; find answer below]

Paul … then we would look at those features at that time. So if it sounds like I'm avoiding the answer, it is a little bit because we tend to respond and think through before we commit ourselves to one particular path. And that's just how it works really.

Johannes Paul, I have to re-ask you again to answer a question because I got the feedback that audio was unavailable, when you answered the question about the DevTools and the IDE features; for getting more and more IDE features, like editing files, a good listing, to know how you think that will continue and develop.

Paul that's actually kind of good, cuz I was thinking as my answer came out: There are other ways that I could answer this. But I'll give it another shot. 🤔

Johannes different answer, let's go

Paul no, I had a completely different answer that doesn't sound like the first one.

No, the first answer I think is the actual truth, which is when we try, and like I said before if you look at something like code editors, they've changed: People were using Sublime or whatever before, and then everybody seemed to move to VScode and that so the world of web development changes an awful lot and very quickly. And so the way that we integrate with it changes fairly quickly as well, and so it's not necessarily a case of saying “uh, this is our known path, this is the path we're going to go down”. Because a lot of the time we're looking at the trends and we're looking at – like Peter said earlier – we look at Twitter, we also go to conferences, and we also just try, and have conversations with lots of different types of developers and different walks of life.

And that hopefully gives us a sense of what the needs are and if the needs take us in a certain direction. Then that's the direction in which we will go. So while it is very tempting to say “oh yes, we should definitely add this feature or that feature or the other”, it's a lot of engineering time to put to something if it's not actually what the developer community needs. So I think, all I would say is, if we're always trying to be open to the feedback to iterate on DevTools, it hopefully goes in the direction that it needs to. I think again:

if you rewind the clock five years 🕰️: Would you have expected that the Chrome DevTools would look like they would today?

No, they probably wouldn't but at the same time, we try and walk a line between responding to people and also trying to make sure that we have features in there – even before lots of sites have them. I'll give you an example of that one: Progressive Web Apps. We knew that PWAs were a thing that we were keen to support, and those features were probably in DevTools – I would imagine – much before the browser support was there. And that was partly because you have a chicken-and-egg problem 🐓🥚🐣. Sometimes with these things, if you can't debug the technology then it's harder for developers to use that technology. So they tend not to use the technology, right? But on the other side, you want to make sure that you don't over-invest in tooling for a technology if it's not actually the right fit for your developers.

So again I'm saying a lot of words. But what I'm trying to say is that we're walking a fine line of trying to respond to user needs, and also make provision for the things that we think are going to be necessary and popular. And that just means it's very difficult for us to say: Well in 6 months, that's exactly what we're going to do. Because sometimes we just have to play it a little bit and see what happens, which is why it's important that we have all those things about experiments and extensions, and all those other ways of trying things out.

Paul did they have the audio this time? 🙉

Johannes yep, I haven't heard otherwise 👍

Johannes Let's go to the next question from the audience: It's WebAssembly related: What features can we expect for WebAssembly in DevTools? Will there be any special support for various languages and for Wasm?

Kim so regarding the features, I guess I've talked about that before. Regarding various languages: When we previously talked about the symbol server we talked – or I talked – about the C++ symbol server. So that is our focus for this year. We want to focus on C++ this year because we want to concentrate on large high performance applications. After this year we were thinking about also adding support for other languages, but let's see. It's not on our agenda. Other than that we don't know yet.

Johannes There is another question directed to Peter: Do you test new tools with outside users? And if so: How do you choose the users to try out new features for UX tweaks and so on?

Peter actually that's a good question. So at the moment, actually it's not so much testing happening with outside users. And it's definitely like negotiating at the moment. So it's quite difficult to find the appropriate testing users. You ask a huge group of developers “hey Ruth, you might want one to test me features”. You will get this super Pro users usually, and you will get feedback that's usually very very pro focused. And right now we're trying to find ways to find user segments to test free features. For example also non-developers because Devtools is also used by non-developers, right? So we want to actually see how those people – like other designers – use that to achieve certain stuff. And right now we're figuring out how we can set up something that's scalable and gives good insights for us.

Mathias From another angle, we also have these Experiments within DevTools so if there's a feature where we say: okay we're just trying something out, we're not sure if we're gonna keep this, or if it's even the right tool or if it's useful, then we can still build it and add it behind a flag so that it doesn't appear in DevTools by default. But developers can go to their DevTools, open the settings, and then go to Experiments and opt into the experiment first. So it's not exactly A/B-testing or anything like that but it gives the developers a way to play around with new ideas that we're trying out, and to give early feedback. And one of my favorite examples of such experiments is actually the CSS Overview that Paul implemented recently. Yeah, everyone watching the live stream should really just go and check it out, because there's no way to explain it in words that does justice to what you would see. It analyzes your page's styles and gives you an overview of all the different colors that you're using, all the different font sizes, all the media queries that appear in your page, and this kind of thing is really useful if you have something like a style guide that you want to adhere to. Maybe you're using a slightly wrong shade of blue on one line of your CSS but everything else is fine and this tool will help you figure that out. So try the experiment!

Paul yet another angle for you: When you look at something like lighthouse, which we ship as part of the DevTools. Now, that didn't start out inside of DevTools, that started out life in a separate repo. It was an extension and CLI that Paul Irish and I started with it. And then it sort of rapidly changed and grew. And we started to see, developers were actually using it, and giving us feedback and thoughts, and so on. And eventually it made sense to integrate that into the audit panel. So that was another path, where that grew organically. And then we integrated it into the DevTools later. So yeah, that's another take on it as well.

Johannes so, it's already more than 45 minutes passed. So let’s get a last question [editor’s note: from the chat], which is a good open question I think. To all of you: What do you think has been the most and the hardest challenging task building and maintaining in DevTools?

Kim, Peter, Paul, Mathias who do you want to answer first? I think you should nominate people.

Johannes okay let's go for you Mathias

Mathias oh okay now I need to think :) Now for me what is simultaneously the most interesting but also the most challenging about working on DevTools is that depending on the feature that you want to implement you might end up interfacing with all kinds of different parts of Chrome. DevTools is really where everything else in Chrome comes together. It could be that you need to fix a bug in DevTools or add a new feature and you end up working on V8, or you end up working on the Blink Renderer. That happened with color vision deficiency simulation, for example: I had never touched the Blink Renderer code before, but there you go! You have to implement the feature there now. So that is really challenging but also super interesting because you learn about all these little corners within Chromium that you otherwise would never touch.

Johannes so Paul, what do you think as the second one? You had some time to think about

Paul I'm just gonna say “Mathias stole my answer”. He didn't really. Although if I had to pick, I would have actually said that it’s a thing more close to home for me. It is a bit about what I touched on earlier: That we are looking at a code base, a big code base. And even with the best tools in the world, you do have a lot of change in that code base. And it has to be managed well, and that's not just about the code. There are people, whose lives are affected when you go and change a product like DevTools or Chrome. And it's just about making sure that you do the decent thing, and the right, and the responsible thing.

But I guess Mathias was saying the same thing.

That the most challenging things are actually the most rewarding things, as well in some ways.

Because when you get it right, you know that you're actually making somebody's day better. You're building tools that they love. You're building tools that they value. And that's an incredibly rewarding thing. Even if you have to sometimes just kind of get a bigger perspective. Or do something that you're a bit uncomfortable with in terms of “I don't know this code. I'm not as comfortable in this space. I have to go and learn about what this means.” You know, those are all challenges and they add to your day. But then you come out at the other side of it, and actually you've grown an awful lot. And hopefully you brought maybe one or two other people with you on that journey, as well. And that's just hugely rewarding.

Johannes so I nominate as next Peter: From the UX perspective, I am curious about your answer about the hardest and most challenging tasks building and containing the DevTools.

Peter yeah so definitely everything security-related is like super hard from UX perspective. First of all, understanding yourself, because it's so incredibly complicated. And then the next problem is web-surfaced. Often when something security-related happens, like something that's pulled off, like an iframe, a cookie, or maybe like even a window you open. And you mean, are you open, you don't really know what is happening, it was pretty security policies. You just get a “null” return and the developer working on this, also normally does not know this happens. And this is incredibly difficult to communicate, because the underlying concepts are very hard to understand. It's like you wouldn't go one page explanation, and it's also hard to detect when this happens, and to be useful in this moment, and to explain to the developer “hey this is happening because of a new security policy from users”. I think it's really hard, this gives me headaches sometimes.

Johannes Kim, what do you think? What's your opinion and in your perspective: What has been the most challenging and hardest part of living and maintaining the DevTools?

Kim this also relates to Mathias and Paul with front-end and back-end. So basically I am pretty new to the team and for me it's not only looking at the front-end but also at the back-end when I actually debug bugs. That comes up during Wasm debugging. So I have to first understand what's happening in the front-end but then I have to see what's happening CDP what is sent back and forth, and then I have to see where it's happening in the back-end, and what is going wrong in the back-end or in the front-end. So it's actually a lot of different things to consider together in order to be able to catch that bug 🐞 and to write a test for that.

Johannes Paul, I'm having another question to you, it's audio related. 😂 No, we've got the feedback from Kerstin “perfect audio quality on Paul's last question” ❤️

Paul I didn't realize I was gonna be such a problematic person today “hope you could repeat the answer to that because we had no sound”, that's today

Johannes sometimes it happens, yeah …

Johannes Let's close it out. Thank you very much, Kim, Peter, Mathias and Paul for your time, for answering the questions! I'm curious about your feedback as well.

And to all the ones, who watched the live stream and will watch the video later on: This is like the 2nd episode of the so called “JSKongress meets friends” series and we want to improve based on your feedback.

So I think, compared to the first episode, it's been better from the quality, from the technical descriptions, we did some technical deep-dive, which was one of the feedback you wished. So please, leave a comment on Twitter and comments and that's it for today.

Thank you very much!

Kim, Peter, Paul, Mathias thanks for having us! thank you!