Michael Hablich is the product lead for Chrome DevTools and Puppeteer. They delve into a comprehensive discussion on various features and uses of the network tab for monitoring API calls, performance debugging with cache, simulating network conditions, and visual understanding of page loading. They cover topics such as debugging, PHP, and the history of dev tools. Michael Hablich shares insights into the development and evolution of Chrome DevTools, highlighting its migration to TypeScript and the team behind it.

Tune in to uncover the challenges and advancements in debugging tools, the potential integration of AI, and a range of powerful features within Chrome DevTools.

 

STEVE: Hello, everybody. Welcome back to another thrilling, exciting episode of JavaScript Jabber. I am Steve Edwards, the host with the Facebook Radio and the Voice for being a mom, but I'm your host today because Dan didn't want to do it. Speaking of Dan, he is here with my panel on my panel with me. How are you doing, Dan? 

DAN: I'm doing really well on the personal level. 

STEVE: Good. Good. Dan is coming from Tel Aviv. I am here in the Portland area where Mount Hood is getting dumped on with snow, which is great for us skiers. 

DAN: Yay. 

STEVE: Um, although the winds are like 40 miles an hour too, so it makes it sort of hard to go down instead of across, but anyway. 

Hey folks, this is Charles Maxwood. I've been talking to a whole bunch of people that want to update their resume and find a better job. And I figure, well, why not just share my resume? See you if you go to topendevs.com slash resume enter your name and email address, then you'll get a copy of the resume that I use, that I've used through freelancing through most of my career, as I've kind of refined it and tweaked it to get me the jobs that I want. Like I said, topendevs.com slash resume will get you that. And you can just kind of use the formatting. It comes in Word and pages formats and you can just fill it in from there. 

STEVE: Our guest today is Mr. Michael Hublich. I think I sort of said it right. I think that had more of the Hebrew accent than German. But how are you doing, Michael? 

MICHAEL: Hi, I'm doing well. Thank you very much. 

STEVE: And you are coming to us from Austria, correct? 

MICHAEL: Yeah, that's right. I'm based in Austria. And there I work as the product manager for Chrome DevTools and Puppeteer. So essentially, I think a lot about testing and debugging web applications. 

STEVE: All righty. So you work for Google? 

MICHAEL: Am I? Yeah, right. I work in the Chrome team at Google. 

STEVE: Excellent, excellent. Talk about getting stuff right from the horse's mouth doesn't get any better than that. Uh, alright. So as he mentioned, we're here to talk about one of my favorite topics, which is debugging in the Chrome dev tools. Um, for, you know, for someone like me who came up starting with PHP, where I had X debug on the server and I could debug the crap out of anything with my breakpoints and profilers and stuff. It was when I started writing first AngularJS and then Vue on the front end, the dev tools and debugging became one of my better friends. So I'm all about debugging and how to troubleshoot and debug things on the front end. So where do you want to start, Michael? 

MICHAEL: That's a good question. So...We can start a PHP because I also started a program with PHP. 

DAN: I'm the only one here who's never really programmed in PHP. Interesting. 

MICHAEL: Wow. I'm impressed. How did you dodge that bullet? Great deck, super useful. I got it all the results and oh my God, I would never ever want to use the applications I wrote 20 years ago. 

DAN: And by the way, just so you know, I think that PHP kind of got its start in Israel, but it got a significant push in Israel. One of the first versions of PHP was actually implemented by two Israelis. 

STEVE:  Is Rasmus one of them? 

DAN: They're the guys that created Zend Technologies. 

STEVE: All right. Okay. Yeah. That's still, you see that as an option in like PHP storm is using the Zen debugger as compared to that's the other option other than X debug. Anybody remember real quick what PHP initially stood for? 

MICHAEL: Personally, the homepage. 

STEVE: That's right. It was just, you know, it was like Drupal. It was like, heck, anything else. So someone started out, Hey, I want to do this for myself. Oh, look, this is cool. Everybody else likes it. Let's watch it go. 

DAN: I did manage to dodge PHP, but I didn't manage to dodge ASP and JSP. So yeah, so you know, I didn't dodge that bullet completely. I did want to say though, that I'm the one who invited Michael on and really wanted to talk with him. Because I think for me, first of all, I for two big reasons. One is that a lot of goodness is recently coming out of Chrome into the Chrome Dev, out of Google into the Chrome DevTools, I see features coming fast and furious, and I'm really happy with all the advancements that are being made there. But it really goes for me beyond that, because for me, the debuggers that are built into the browser are the big reason that web development has been able to advance so much. We take these tools for granted because they're built in, because they're ubiquitous. But you can't imagine how the world would have been without them. And I sort of can, because I was there at the time, and debugging with alerts and stuff like that. And I really can't imagine modern web development without the various debuggers and development tools that are built into modern browsers. And personally, I like using DevTools the best. So that's the one that I mostly use when I have a choice. 

MICHAEL: That's very nice of you to say. 

STEVE: So Michael, let's start with history, I guess, of the DevTools. And I know from back early 2000s, I can remember the first thing I remember seeing that was like this was Firebug in the Firefox browser. And I think that predates the Chrome DevTools. I could be wrong. Is that correct? 

MICHAEL: Yeah, that's correct. So, fire. I don't know if Firebug was the first. I guess Netscape and so on also had the debugger. I can't remember. 

DAN: I think Internet Explorer had the debugger before Firebug. 

STEVE: That's just the first one that I recall. 

DAN: I'm not sure, to be honest. 

MICHAEL: I mean, at that point it was a blurry line also using Wish You Basic and so on to debug your web applications because you had all those nice active fix content. Yeah, Firebug for sure was first And as far as I can recall, when Chrome actually was released, there was already DevTools included. 

STEVE: OK. That sounds right. 

DAN: And one of the really cool things about Chrome DevTools, that again, I don't know if a lot of our listeners realize, is that it's actually implemented in JavaScript and HTML and other web technologies. 

MICHAEL: That's correct, which is also essentially, when people start talking about debuggers or about Chrome DevTools or Firebug and so on and so on, they need to realize it's actually going to be two main components. One of them is going to be the introspection capabilities for the runtime, which is like exposing what's currently happening in runtime, so all the information, the backend, essentially. But on the other side, you're also going to have the frontend because we need to surface the deformation somehow to the user, give the user a way to control breakpoints and so on. And that particular frontend, for example, in Chrome DevTools is written in, now this is in TypeScript. I think we migrated to TypeScript two years ago or something like that, 

DAN: from JavaScript 

MICHAEL: to TypeScript. 

DAN: That must have been a really big rewrite. 

MICHAEL: Yes, it was. I mean, it changed a lot of files and a lot of lines of codes, of course. So we did actually try doing it in small chunks, but then it was like, also not great. So we actually had hackathons where we changed bigger chunks of the code and so on. But yeah, that took a lot of time. But TypeScript is simply more ergonomic to develop a publication like that. 

DAN: How many people, by the way, if you can say, work on the Chrome DevTools inside Google? 

MICHAEL: Let's say it's roughly 20-ish. Something like that, yeah. So including software engineers, UX designers, UXR people, PMs, program managers, managers, and so on. It's roughly 20. 

DAN: And you, like I mentioned before, you release features really fast and furious. I mean that literally every time a new version of Chrome comes out, which is what, like every month or two? 

MICHAEL:  Every month, yeah. 

DAN: Every month. I see you guys coming out with a video about the new features and capabilities that you're adding into it. So how are you able to add so much capabilities into the DevTools at such a rapid pace? 

MICHAEL: Right. So quick shout out regarding the videos. I forgot our DevTools people that are also working on the team that are creating this content. And yes, I really like their videos. They are so great. And also that's what our user actually also telling us, like the videos are great super useful for them to actually get to know about the features. 

STEVE: Now, which videos are these? Where are they at? 

MICHAEL: What's new in DevTools? I think the cadence now is every two major, so every two months we're releasing a new one or something like that. I need to check. Or maybe it's for each major version nowadays. 

DAN: By the way, in the Chrome DevTools itself, when you open it in the drawer, it will actually tell you what's new and have a link to that video so you can actually get at the video from inside the Chrome DevTools. 

MICHAEL: Yeah, that's great. And this also has release notes more or less, like this feature showcase. It's linking to, yeah, that's probably a playlist. 

STEVE: It is. I didn't know that. Oh my god. 

MICHAEL: Oh yeah, that's really useful. If you have eight minutes of stuff like that every month and look at that, you will see all the big features. How we do that? Yeah. I mean, it's a constant evolution. So the debugger always needs to adapt to how the debugging target is also changing. What I'm saying is the web platform constantly changes. In particular, Chrome constantly changes, so it exposes new APIs, so APIs are going to be changed, and so on. That requires a certain amount of maintenance on our end to also make sure that they're not breaking which is taking up quite a lot of capacity honestly, because there's a lot of churn and we need to keep having hold on those issues. And how we select what we are going to work on next, that depends heavily on feedback we get from developers, but also initiatives that we know that are important to us. Like for example, core web models and performance debugging. We know we have the case studies that this is important, that this is really going to change the conversion rate. So we are investing a lot in performance debugging to make that more, let's call it more efficient. So essentially that you get more bang for the buck out of your time invested as a developer. Or similarly network debugging, which this year we want to take a deeper look into network debugging, network panel, for example, that because nearly every DevTools user out there is using network debugging one sort or another for performance debugging or for network debugging where something doesn't show up and so on and so on. So network panel is used quite often. And for this year, we actually said, okay, we are going to take a deeper look and what we can improve there. Which is not easy because if you ask two people, which of the changes is better, you get two answers. So very often it's finding a good middle ground or opening up or don't find the middle ground and providing capabilities to make it configurable what is best for users. 

DAN: Although there's this maxim that I've heard like a while back which says that every checkbox you see in an options dialogue is two product managers fighting and couldn't decide who's got the right opinion. So they said, let's just make it an option. And then of course you start fighting over what should be the default. But that said, you know, so you said that you get a lot of the decisions are actually driven by community feedback. How do you actually get that feedback? If I have certain ideas for things that I would like to see in Chrome DevTools, I think, hey, I think they can make the network tab so much better if they do X. How do I send this feedback over to you, or suggestions, or whatever? 

MICHAEL: OK, so the most straightforward thing is open Chrome DevTools. And there's this hamburger menu, the three dots menu. There's help, and there's report a DevTools issue. That is going to open issue track and there you can submit a bug or a feature request. And that is regular triage. We have SLOs to actually go over this list and actually triage those. 

DAN: So it's not just issues, it's also suggestions and requests and stuff like that. Cool. 

MICHAEL: Yes. So the issue is like either a feature request or a bug. Triage process should hopefully categorize them correctly because it also depends for some users, feature requests is actually the perceivers of the bug, which is fine. Yeah. That takes some conversations. 

DAN: And when are you going to integrate AI? 

MICHAEL: That's a good question. 

STEVE: How would you see the dev tools integrating AI, Dan? 

DAN: I was just joking. I mean, AI is everywhere. I'm just, 

STEVE: I know I'm just trying to think of how would you use, I guess I could see some applications. I'm not sure. 

MICHAEL: I mean, we obviously are talking with web developers about how you're using AI, like chat GPT or Gemini and so on and so on for web development tasks, which is super interesting. And it's, but it's very new. Their results are very nuanced and need a lot of understanding when you interpret the results. So what I'm saying with that is, it's not a magic or silver bullet. For example, you get a result back from your random AI assistant, and you still need to be able to interpret what is coming back, if this is actually correct or not. Because if you can't do that you're going to be, you could be in a very bad spot. So the quality of responses is very, is actually very important. Having said that, with all those new model updates that are coming in, the Gemini Ultra, or be it Open GPT with version four, all of them are getting more powerful, of course, because you can also apply more information to it, and so on. Bye-bye. understanding, touching the quality of the response is super important. That actually requires a certain level of experience from the user to touch that. So yeah, there's potential, but it's nuanced. 

DAN: Yeah. So on a more serious note though, so as I said, a lot of new features and capabilities being added in, can you like give us an overview of let's say like a couple of your recent favorite features that made it in that you're really happy that made it into the product? 

MICHAEL: Okay. So that's going to- 

DAN: I'm stumping you. 

MICHAEL: No, no, no, no, I'm just thinking how to start explaining that. Oh, I think a year ago or something like that, it might be longer. We started, um, tracking down bucks in our, how, how we are treating breakpoints. And if we are hitting breakpoints by debugging. Which means sometimes breakpoints were not hit, and sometimes they were hit, and then they reloaded, and then they were hit, but then you didn't reload, and they weren't hit, and sometimes new breakpoints appeared and stuff like that. 

DAN: Yeah, I'm guessing usually issues come up with like virtual code, right? 

MICHAEL: Yes. That's what... So we did go down that rabbit hole, what's actually happening there and it turned out, of course, it was a number of issues, which is, for example, web applications might look the same when you reload, but they might not actually be the same under the hood, because code gets injected, or you might be running an A-B test, and so on, and so on, and so on. So if you set breakpoints in version A of the application and now that breakpoint should move to somewhere else because the code, when you have to reload this version B and it's actually a little bit of different code, the debugging backend actually needs to migrate that breakpoint. And that's that's not super straightforward. 

DAN: So basically you're saying that in an ideal world, you'll be able to somehow magically identify that a particular piece of code has moved down a few lines or moved up a few lines and then move the break point along with it instead of just hard coding it to a particular line number in a file. 

MICHAEL: Right. And there are heuristics that help you there, of course, built into DevTools and other debuggers. There is also technology like SourceMaps that also, again, 

DAN: help you doing that. 

MICHAEL: Yes, and you're saying, oh, SourceMaps. And I'm saying, yes, oh, SourceMaps. But it's the technology that we have. And there is actually no standard for that yet, which is going to change hopefully. hopefully is going to then result in a more reliable usage of source maps. Um, right. Where was I? Yes, source maps. Whatever. I know going back to breakpoints and how them, so migration of breakpoints when you reload, for example, then we found out, oh yeah, there are a few issues in there. So we fixed those and then we found new issues. And then we started digging into, well, what if you set a breakpoint, but that breakpoint is in the ignored code section. So we actually don't want to see that. Should it trigger? Should it not trigger? We had, I think two camps or what in the team, like, no, we should be doing that. No, we should be doing that. Okay, can we answer that somehow with UXR? It's like, oh yeah, yeah, let's do that. So we have in Chrome DevTools, we have a process called RFC, request for commands, where we have the GitHub repository and we are asking the community as an engineer, hey, we have this hard problem to solve. We know there's different solutions please help us identify what they actually prefer or in such cases. So we did that. Yeah, long story short, that is a perfect example of like, wow, the results were split a little bit for preferences. So, okay, what this means essentially is we need to make it configurable because there's no winner. Right. So I found that particular endeavor quite interesting. It wasn't like a very technical and it was like, Oh my God, it's so complicated to think through all of that. But honestly, that's not something that a lot of people or that's something that a lot of people might be encountering, but might be able to fix with a reload, but still under the hood, something else is happening. So. 

Hey there, this is Charles Maxwood. I'm excited because I wanted to let you know about this thing that I pulled together that I had just, I've been dying to have this for years and I never felt like I could. And then I just realized that there's no reason why I can't. So I'm putting together a book club and we're gonna read development-focused books, career books, technical books, whatever. The first book that we're gonna do is going to be Clean Architecture by Uncle Bob Martin. If you're not familiar with Clean Code or some of the other stuff that Bob has done Check that out. I've also talked to him on the Clean Coders podcast, which is on Top End Devs. But yeah, we're going to get on. He's going to show up to some of our meetings. And what I'm thinking is we'll probably have like five or six people part of the conversation along with Bob and I at the same time. And we'll just, so somebody can come on, they can ask their question, and then we'll just rotate people through. So we'll mute one person, unmute another person when it's their turn to come on and be part of the discussion. So We'll do that for like an hour, hour and a half. And then the other part of it that I'm putting together is just kind of a meet and greet gather area on Gather Town. And so after the, the meetup and the call, what we'll do is we'll all go over to Gather Town and you can just log in, walk up to a group and have a conversation. And that way we can all kind of get to know each other and, and make friends and, and get to know people across the world. Uh, one thing that I'm finding is that, yeah, the meetups are starting to come back but a lot of people don't have the opportunity to go to a meetup. And I really want to meet you guys and talk to you. So we're going to put all that together. It'll all be part of that book club. You can go to topendevs.com slash book club to be part of it. And I'm looking forward to seeing you there. The first book club meeting will be in December, the beginning of December. We're starting the first week of December. And, um, you'll also be part of the conversation about which book we do next. I have one in mind, but I want to see where everybody's at. So there you go. 

STEVE: So I've been playing around and I've noticed recently, and I don't know how recently these have been added in, but we were talking about the YouTube channel of all the what's new in DevTools videos, and you were talking about issues. And so if you bring up the DevTools, over to the right, you'll notice, if you have any console errors, it'll give you a little red X that shows you you've got one error, a bazillion, which is my case sometimes and then you'll get another little icon with a triangle with an exclamation mark and a looks like a quote balloon with an exclamation mark. And if you click on those, brings up another little window. And this is really cool. One is labeled what's new and it has the latest video right there in the dev tools. And this, as we're recording right now, the YouTube channel shows up through number 120 and in the dev tools itself, it has a video on number 121 and it lists a whole bunch of different issues like source map improvements, enhanced performance, and so on. So right within the DevTools itself, you can see what's latest. And then there's an issues tab, and it looks like there's what, current issues. Right now, for instance, there's one about a deprecated feature use, reading a cookie and cross-site context will be blocked in future Chrome versions setting cookie and cross site content won't be blocked in future com versions. So really cool way, I guess, to get, instead of having to go hunt around right there in the tools, you can get to the latest and see what ongoing issues are being addressed. That a fair statement? 

MICHAEL: Yes, so if you're talking about the issues panel, then yes, the idea, the division for that one is actually to be something like a launchpad where you look at the issues panel and then you can go through a list and fix the issues on the page. Because, so that was introduced like a few years back because we have seen a lot of console spam. Everybody was spamming the warnings and errors to the console. So that's the rebel interface that you have in, that you have in DevTools, also everybody's using. And it was simply spammed with a lot of warnings and errors. So we moved a certain amount of those errors into something called an issue panel where you actually can, instead of throwing errors, you can put structured information in there also with the information, okay, you're facing this issue, that's what they should be doing. Like also with a suggestion or link to a web.dev article and so on. 

DAN: I really like this approach of trying to clean up like the like you said, it's kind of the console had to a certain extent has become this kind of a grab bag of like Everything and a lot of organizations basically even started kind of ignoring it because there was just so much stuff there By the way, I'm old enough to remember the days when companies would actually like post jobs in there So you would like going to a website open the dev tools and says if you can read that then we would like you to apply for a job with our company. I think that's kind of, I don't see that happening very much anymore, but that was an interesting time. 

MICHAEL: Sometimes I still see that. What I see more often is messages to end users, not developers, with the content of, you shouldn't be here. If anybody told you to open DevTools, you are looking at this thing close it right now. 

DAN: Yeah, I'm guessing, yeah, for security reasons, they're worried about the phishing attacks or stuff like that. 

MICHAEL: Yeah, Greg. That's why we also, half a year ago, something like that, we had a little bit of a wall or a speed bump there where we feel a pasting in some code into the console the first time going to reply to you, hey, you're not allowed to do that because for security reasons, essentially. Please type in, I need to check, I'm a developer or something like that. And then actually that feature was enabled that you can paste code into the console. 

DAN: Interesting. You mentioned source maps before and indeed one of my biggest gripes like forever with effectively like every dev tools ever that I've ever used is how kind of problematic or how limited source maps are like they're better than nothing for sure but then not always by much so you know the lines never actually match up exactly and when you're in the console the names of the variables don't match and stuff like that. So it's a real pain sometimes to debug code when it's minified and whatnot. And even if you ship the source maps for it. And the reality is that I often do debug in production. So is there anything you can say about that? 

MICHAEL: Yes, I can say a lot about that. Let me structure my thoughts a little bit about that.. Um, summarizing, yeah, that's what we also see like, um, when you're debugging something, you're going to have source maps, you're not going to have source maps. And let's go down with the route of, uh, you don't have source maps. Then the features like pre-print or local overrides are going to be very, very useful for you and it would be really useful to actually somehow. And you can also attach the source map afterwards to it and so on. But if you're using source maps, you actually have them available. Getting that working correctly is really hard. And it really depends if your technology stack can set it up correctly as default. It turns out that creating good source maps actually takes a lot of time when you're building. So that's why sometimes there are options like speedier of creating, fast creating source maps that are not 100% correct. And that's also, again, I talked about interesting breakpoint bugs that then result in very interesting breakpoints or debugging bugs when you're, when you're resolving a variable, for example. We also, we encounter when we do using the views, we encounter a lot of users also running into those problems. Okay. But what, what are we actually doing in order to improve this situation? On one hand, we are working with TCFood9 to standardize source maps. Because you're not standardized. 

DAN: Yeah, that's one of the, that's one of the things that I kind of wanted to mention is that people don't realize that the source maps are something that kind of like, kind of like happened, rather than being properly designed in, you know, with like this really nice process. As I recall, some guy just created them and we're more or less stuck with whatever he created or something like that. 

MICHAEL: The story is probably a little bit more complicated than that, but yeah, it's not standardized and that's a problem, of course. So standardization should hopefully, when it's actually standardized, result in a more reliable usage of source maps and also for stakeholders enable them to actually change the standard and add new features to it. Because right now it's super hard for an entity that, for any entity to actually make changes to or additions to the source map spec, except with the ex-Google extensions and stuff like that. If you have a standard, there's actually a way to do that in an orchestrated way. 

DAN: So the bottom line, is there going to be like a solution for let's say using proper the correct variable names or the original variable names in the console, for example? 

MICHAEL: Yes, there could be a solution. And I think I need to check. 

DAN: So you're going to tell me that the solution is already there. 

MICHAEL: So I'm 80 percent. I think we did something in that direction. Well, I know we did something in that direction. I don't know how much of that already has shipped. Yeah, I would need to check that. But yeah, because again, I think we also did some user testing, was like, oh, but I would expect the opposite as it works. 

DAN: The problem then is that it's really difficult to, if you're working with the source maps, then you see the original code, but the variable in the console is the minified variable. It's actually really difficult to find out what the unified variable name that matches what you see in the code is. So you're kind of like screwed both ways. It would have been easier to see the original code or because then at least you would have seen the correct variable names as it were, but you're like kind of stuck in the middle. 

MICHAEL: Right. Uh, it's a good segue into, um, something we shipped last year. Oh yeah. one and a half years ago, which is called the authored and deployed mode. So in the source panel, if you can actually switch between the authored code, which is you, which is all the, the source map code and the deployed code, which is not, which is completely ignoring source maps at all. It's really new to think of how it's actually. 

DAN: How do you do that? 

MICHAEL: There should be a button up there. If there's no button, then you need to enable it in the preferences under experiment seconds. Oh yeah, under experiments in the settings, group sources into alpha and deploy trees. And with that you can actually switch between the two of them for exactly the reason you just outlined. Like, hey, actually you're debugging two worlds and you would want to switch. And that's a concept we in the future, sometime in the future, we want to explore a little bit more. Like, can you switch between those two modes and what are the implications? variable or alternatively 

DAN: maybe show a tooltip like if you're hovering on top of the variable in the mini like you know in the source map at least show the name of the minified variable or something like that that might be useful as well. 

STEVE: Okay along the lines of practicality I'm all about practicality. What I'd like to do is you know there's i'm counting what eight or nine different tabs. The first four, at least for me, the first four are the ones that I use the most, the elements, the console, the sources, and the network tabs. So what I'd like to do is sort of walk through those different tabs, different pages within the DevTools, and just sort of go over how you would normally use them, and maybe if you can think of any lesser known feature that you could think would be really useful. So for instance, if we start with the elements, yeah, right, the elements basically shows your HTML markup and then if you click on, for instance, if you click on an element over on the side, you can see the CSS that's applied and the layout, what are the computed styles, how are things all put together and so on. 

MICHAEL: Okay. So let me also go with a bonus thing there. So what I'm quite often using is our command palette. So which means command palette. Similar to what they have in Visual Studio code, for example, if you do shift, I think it's the option key on Mac and P. Shift command P. Yeah, exactly. Okay, 

MICHAEL: shift command. Yeah, sorry. I have a combined keyboard here. It's a little bit hard to identify which of those Mac keys it is. And that actually enables you to run all the commands in DevTools. That's what I'm using quite often if I want to look for something and that is the segue into when I'm talking about elements. One feature that I find very useful is emulate focus page. So essentially if you are using DevTools, the page is actually losing the focus because DevTools had the focus, but with that thing you cannot let the page lose the focus, which is relevant. For example, If you're debugging some styling problems with hover over menus or something like that, it will disappear when the focus falls. 

STEVE: Heck yes. Like drop down menus or something like that. 

MICHAEL: Yeah, right. But I think that one is actually in the rendering drawer or something like that. Whatever. But I find it very useful. And the other one is elements that I more or less use regularly, and that don't debug very often in elements. I'm not that much into styling is breaking down, so making long breakpoints. So for example, if I want to know, oh, I wonder when that particular element is going to change or is going to be created, I can set a breakpoint there. And then if a new sub item, for example, is going to be added and filled into that particular element, the execution breaks. And I know exactly what's happening there. They can... 

DAN: Yeah. Unfortunately, that's a lot less useful than it used to be with modern frameworks. I mean, you know, so it breaks in the middle of the React code somewhere. You know, what do you do now? But it was much more useful in the jQuery days. Let's put it this way. 

MICHAEL: Right. Which is also a nice segue to another topic. So previously I mentioned a little bit about ignore lists and stuff. So you can use ignore list to ignore files and stacks in your stack trace. What this means, for example, typically the inner workings of the React framework, typically you're not going to be interested in that. You're probably going to be more interested in the code that they actually wrote, or that they actually have influence and control of. So with ignore list, you can let those things be ignored in stack traces and then everything else. So that's super useful. 

STEVE: And now where is the list? How do you set that? 

MICHAEL: That's also in the settings. Yeah, I think in the, so 

DAN: I think that in the sources panel, when you see a stack, you can actually right click, I think on an entry in the second, say like ignore this. 

MICHAEL: You can also do that and they'll also add folders and files or use the settings dialog in the DevTool settings. Or a framework might already pre-populate in that list because that list, I think we added this as an experimental source maps extension or something like that. I need to check how it's actually implemented. And if the framework, like for example, Angular is already supporting that then you actually don't need to do anything. Then the whole framework code is not going to show up at all. 

STEVE: Yeah, I just, here's one I found. If you do the command shift P, you get quite a extensive list of different things that you can do. There's one that shows CSS overview. 

MICHAEL: Oh yeah. 

STEVE: That's a great panel. And you can see a summary and shows all your background colors being used, text colors, contrasts. You can see in all their codes and what they look like font info, media queries, oh my gosh, just the colors and the overview summaries. I can think of many times I've been looking for like browser extensions to find this stuff and it's already there. Okay, so let's move on to the console. So probably, you know, Dan mentioned debugging by alerts. I think, you know, everybody knows how to do like alert something, you know, oh, I hit my code here. Great, that tells me, I know there's a heck of a lot more you can do with the console. And I have an article bookmarked somewhere about all these different things you can do with the console, like console error and console thinking, you can do stack traces and there's just all kinds of crazy stuff that you can put out in the console that even, you know, break points are awesome, but they don't do everything. And so the console really helps you see some stuff there. Uh, anything else? What can you think about the console? Maybe some hidden gems in there. 

MICHAEL: So what I find useful in the console is using snippets. 

STEVE: Okay. 

MICHAEL: essentially that it can run code that they have prepared for some tasks in there. What I really find useful in console is the dollar sign 0 to I think four or something like that, which give you automatic access to the last selected HTML element If you do something zero, you get access to the last selected estimate element. That's very useful when you want to try out something. 

DAN: One thing that I really love about the console in DevTools is that when you log out elements, it behaves as if you copied something out of the elements view, that you can actually like expand them and you can obviously you can right click on them and go to the elements panel itself but you can also do a lot of stuff even like in the console with elements as if you're in the elements panel, which is really nice. And I also like the various dollar shortcuts. They are useful. And the one thing that I haven't found very useful, maybe I'm just not using it right, is the ability to watch expressions. I don't know. I've yet to find a really useful use case for that. One thing to watch out for though with the console is if you change, if you put in a filter, or if you change the default levels, or if you go into an iframe, then you might suddenly be surprised why you're not seeing things that you expect to see. So always be careful about what you put in the filter and remember to take into account that your filter potentially filtering out stuff that you may want to see. 

MICHAEL: Yeah, that's true. Thank you for saying that. Yeah, the console is actually super powerful. Yeah, live expressions. I find them useful when I want to have a live evaluation, a live update when something happens on a page. So if I run in a console, for example, next to the page and I do some interactions on the page. Then the live expression is going to change depending what the live expression is for example. But I don't need to go back to console all the time to issue new command but it's simply automatically update. 

DAN: I do put watches like in the source panel which kind of do similar thing. I've yet to really find the need for live expressions in the console. But like I said, you know, maybe it's... 

MICHAEL: Yeah. Well, it's not every user is going to use all the features. It's often mixed. The watch expressions are going... are great. Same with breakpoints. Sometimes you will not be able to use them properly and print after debugging is going to be more useful. Yeah, 

STEVE: so live expression is that where a value changes as as the code is running, it changes right there in the console for you or? 

DAN: Yeah, you see is Steve if you go to the console tab, you will see the eye icon. 

STEVE: Oh, right. 

DAN: And if you click that, it opens up this new line where you can write in an expression. 

STEVE: Oh, OK. 

DAN: And that expression will update automatically as things change. 

STEVE: Oh, OK. So like a value of a variable maybe or? 

DAN: Yeah, for example, anything really. 

STEVE: That's like a watch. OK, yeah, the PHP dev tools in my IDE has a watch thing that just has an exchange. 

DAN: Like I said, you have in the sources panel, you have something called watch, which effectively does exactly the same thing. It's just a different panel. 

STEVE: This is just doing it in the console. OK. Yeah, console log, there's console errors. There's all kinds of stuff you can do. 

DAN: I like console table, which a lot of people are not familiar with. 

STEVE: Right. Because it prints out everything in a nice little neat table in your dev tool. 

DAN: Yeah, if your data is appropriately organized or configured, if it's effectively tabular data, then the table can be really useful. I also like using the some of the web performance APIs directly from the console. So things like performance, get entries or get entries by name or get entries by type are really powerful things to be able to do directly from the console. 

MICHAEL: Yeah. 

STEVE: and going over from the promises and stuff. You just sit there and worked in the console the entire time. You know, write out some code, set a variable, run this, run that, and everything was just right in the console. 

DAN: Yeah, I know that a lot of people like launch node in the terminal. I just open DevTools and go to the console. I feel right at home there for a lot of these sort of things. So a lot when I want to play with code and get immediate feedback. The console is often where I like to do it. But for example, one of the things is when, so for example, let's say we mentioned that one of the other tabs that Steve that you talked about as being a really commonly used tab is the network tab. But the problem with the network tab is let's say I open the page after the page is already loaded. So I kind of miss stuff but I can use the performance get entries or get entries by type to see network information about things that already happened, even if the dev tools was closed. So that's really useful. 

STEVE: So you just go into the console, open a new line and type that in and it shows you. 

DAN: Yeah, I do like, yeah, get entries by type resource and I can see the various resources that are downloaded. Now it's not as like visually pleasing to see as the network tab, but it's better than nothing. 

STEVE: Sure. Yeah, I will try to find the article I used to have bookmarked or I had bookmarked somewhere that shows all the different things you can do in the console. It's really amazing. You know, there's more than, let's just say there's a lot more than console logs. 

DAN: One of the funny changes that you recently did, well it's not recent anymore, but it was like this small thing and it was really helpful, is that const isn't really const in the console anymore. That you can redefine const. 

MICHAEL: Yeah, I can recall that. 

DAN: It was such a great thing, it was such a useful thing. It was so small yet so useful because you would accidentally type cons something because you copied some line of code out of somewhere and then you were kind of screwed because you couldn't change it anymore until you like reloaded the tab or something like that. And now you can effectively just redefine the cons. So that's really nice. 

STEVE: All right. So let's move over to the sources tab. That's one of my, uh, one of my favorites that I use quite a bit. Um, Now, I do have one question, Michael, before we get started. And I don't know if this is a bug or way things have changed. Maybe it has to do with the source maps discussion that you were talking about. I work mostly in Vue when it comes to the JavaScript on the front end. And it used to be pretty easy to be able to go to my document tree over on the left and find a file and open it. And that was it. Now, I have to use like a debugger line to find it to write open the file because Webpack has created so many different variations you know of a particular file and it's not so easy just to you know command P type my file name and open it. Is that something that's changed? Does it have to do with source maps? What what do you know what you understand what I'm talking about? 

MICHAEL: Are you talking about files that are ending with a hash? 

STEVE: Yes well yeah that's what I see is when I go to open them and I can't find the one that actually is running my, you know, that has my code. So if I put a debugger line in there and run it, then it'll hit that, okay, that's the one that I want to put my break points in and enter. It's just, it didn't used to be so difficult. So I'm not sure what's changed, if it's a combination of the view code or if it's the dev tools or something. 

MICHAEL: So it's, so we, I think it was one and a half or three years ago when we started that, we actually did have a look at the default experience from different popular frameworks and how the debugging experience is out of the box essentially. That was enlightening and very interesting. And we found bugs in Chrome DevTools that we addressed, but we also found enhancements that frameworks can be doing in order to provide essentially better information or stuff like that. So the default debugging experience is better. I think we also, so I can recall that particular issue, for example, with the hashes because again, same thing. Hey, now I hot model loading kicked in and now I have five files with the same name, but different touches. Which one is the last one? I don't care about anything else anyway. And some fixes have been made. I would need to check if that affected you. I think it has because then it also depends what version of you you're actually running and so on. 

DAN: So a question about that, do you actually work with the framework makers directly Like if let's say you say, hey, we think that the view could be doing something a bit differently and that that would really improve the integration. Do you actually reach out to the view contributors and suggest a change to them? How does it work? 

MICHAEL: Sure, answer that question. Yes. That's what we're doing. So we, we obviously can't fix every, everything ourselves, be it because we don't have the know how or they don't have the capacity or we don't have control over the source code. Um, so we need to work with partners like you, like react, like Angular and so on to get a better experience to our users. So yes, we are reaching out to them and ask them, Hey, we have seen that. Can you add that or Hey, we are really interested in making the experience for React users better. What are the top issues that they see when they are debugging and how can we help them and so on. 

DAN: Now, one of my favorite features in Chrome DevTools and it's part of the sources panel is the overrides aspect. For those of you who don't know, overrides mean that you can effectively like edit the file and save a local copy of the edited file so that then if you even if you reload the page, it will read it will use your your edited changes. And it's a really cool way of trying out a fix without having to redeploy a new version. Of course, there are problems with it. I mean, bundlers get in the way if your code is bundled, then then then editing it can be, you know, editing. Let's say adding the minified bundle code is a lot less fun. It's doable and I've done it, but it's a lot less fun. So that's one option. I've even done like crazy things like copy the non-minified version and paste it over the entire file and then edit that and save it into the override. Uh, but, but when you can get them to work, overrides are immensely powerful feature. One thing that I would have liked, which is kind of similar to overrides would have been the ability to redirect. Say like, you know, instead of download the file from this URL, like, like behaviors, if you're downloading the file from this URL, but actually download it from a different URL. Like what you might get with certain local proxies. 

MICHAEL: Right. Okay. So yes, override is a great feature. Network overrides and local overrides. And we also did actually spend a few cycles to prove it at the end of last year, I think. 

DAN: Yeah, the timing, the low timing, I think you improved that it behaves as if it's not local, but downloads from the network. 

MICHAEL: Yeah, and also we also did some UI changes with local overrides, I think, because it was hard. It's a super useful feature, super hard to find if you don't know where it's looking, or you might find if somebody else that already knows about this is going to tell you about that. 

DAN: Are you familiar with it, by the way, Steve, with the override feature? 

STEVE: No, I haven't used it before. I've seen something similar. I remember Chris Coyer a few years ago from CSS Tricks and CodePen and Shop Talk Show did a video about making your CSS local. So you can change it and tweak it. You know, if you're working like a remote site and you can tweak it actually locally, which I thought was awesome. This sounds familiar, although the question I have for you, Dan, is how is using the overrides panel within the dev tools different? Say if I'm working locally, right, and I'm editing code in my IDE, and I change that and the hot model reload happens, what's the difference? 

DAN: Obviously, if you have hot reload with actual debugging, local debugging, that's the better option. 

STEVE: Okay. 

DAN: But let's say you've got it already shipped in production, let's say, and you're thinking, hey, you know, I think we could do X bette if we do this instead of that, but you know, you, you don't want to be, instead of, you know, firing up the development environment and starting and doing like that way, you just open, open it up to the override and test the, and effectively test your change in production. 

STEVE: Oh, oh, that's nice. 

DAN: And for example, I did a workshop like once I remember, and instead of having people like install a whole development environment i created the website with demo code and we basically worked together by overriding it with more and more sophisticated versions. So they actually used Chrome DevTools as their development environment creating overrides. 

MICHAEL: And the sibling of override is the workspace feature. So if you actually have access to resource code and you want to keep on hacking in DevTools because you want to make small changes and stuff like that, you can use Workspace to actually hook up to your file system and make a link to your actual source code. 

DAN: Yeah, so that's really about using the DevTools effectively as your development environment, effectively. 

STEVE: So what is it doing? It's creating a local copy within the browser there and then you're tweaking it. 

DAN: No, it's that. No, it's really mapping to your actual code. Think about instead of using VS code for your coding, using Chrome DevTools for your coding. 

MICHAEL: Yep. 

STEVE: OK, so if I if I add a folder, I'm adding it so I can do that on my prod site. You know my whatever.com and it's actually connecting with that code that's bundled code that's running on my server. 

DAN: Well, that's if your server is local. Or or or accessible as via the file system. 

STEVE: OK, so then, but you were talking about running using the Chrome dev tools like Azure Workspace against check against prod. How does? How does that work? I guess that's what I'm trying. Is that what you're talking about? 

DAN: No, so we're saying that there are two different features which are related. One is a feature called overrides and the other called a feature called workspace. Workspace is about mapping your actual development workspace into dev tools. 

STEVE: Okay. 

DAN: So that when you make changes, you're actually making changes in your original code files. 

STEVE: Okay. 

DAN: Override is a feature that lets you override. The file coming from the server remains the same, but you're creating like a local copy that the browser uses instead. 

STEVE: Gotcha. Nice. I like that. 

MICHAEL: Very nicely summarized, yes. 

STEVE: Okay, that makes a lot of sense. I mean, the classic case that comes to mind is, hey, it works on local, but why isn't it working on prod? You know, as a way to... 

MICHAEL: Yeah, I also said, definitely it like if you, for example, are debugging, if you are offering a library, for example, and you need to debug while it's not working on the client side, you will not have access to the client source code, but you still need to debug it. So with all rights, you can actually try out fixes and stuff like that in the production environment. It's very useful for debugging. Very, very useful. 

STEVE: That's cool. OK. Learn something new every day. All right. Now, the other thing that I want to talk about in this DevTools environment, we're running out of time here, is breakpoints just because they are so incredibly useful. The ways I use them, and I sure I don't come close to maxing them out is the way they could be. And they work pretty much the same as they do in my PHP IDE is one, obviously just to stop code and see what's the value of certain variables at a certain point. If you're in a loop, you're in a function, whatever, that's probably the most useful thing. sometime, but I know there's other things where you can edit the breakpoints and set conditions, you know, whether it's, okay, only hit this breakpoint if this variable has a specific value because you're inside of a monster loop and you don't wanna stop every single time. Or you can, you know, just temporary disable it instead of removing it. You know, there's all kinds of conditions. If you right click on a breakpoint and edit it, you can see all the different options, but it's a lot more useful than just click it. Okay, it's going to stop every time it runs here.Yeah, go ahead. 

DAN: Yeah, conditional breakpoints are very useful. There's also the option of log points, which is, instead of breaking, it just logs something to the console. You could do it in the old days by just creating a condition with a console log in it. But I guess that a lot of people just didn't think about that trick. So, so yeah. But so, but it's useful because something you just want to like you saying, it would have been really useful if I had this log statement, but I don't have it in the code. So I'll just add it as a, as a logs option. Or if you're doing prod debugging again, where we can't change the source code, except if you're overriding, but that doesn't Might not, for some reason not working. So you can do a log point and it's like a printf. 

MICHAEL: Or you can actually, can you actually even change local variables in, in kind of like this log point, like effectively add some logic in a log point? I, 

DAN: yeah, you can add the expression in there. I think it needs to be side effect free or something like that. Or I might be mixing that up, 

MICHAEL: but you can add an expression. 

DAN: That's interesting. One more thing that it's worth while mentioning about breakpoints is that sometimes you have like a complex line with multiple instructions on it. If you put a breakpoint, you will actually see that there are small arrows inside the line itself, and you can actually turn on and off breakpoints inside the line. 

MICHAEL: Yep. Welcome to JavaScript. 

DAN: Well, that's true even from the C days, you know. 

MICHAEL: I know, I know. But why it gets super interesting is when you have minimizers at work in bundlers, everything gets crammed together into one line to squeeze out as many bytes as possible. 

DAN: Yeah, that's kind of why I think DHH is now trying to get us all to just working the original source code without minifiers and basically rely on the compression and not on the minification. And there's a lot of truth in that in a lot of ways, but he's trying to take it even a step further and trying to convince us not to use bundlers. And we're not there yet. 

STEVE: Alright, so finally we want to go to the talk about the network tab and there's a lot you can see on your network tab in terms of basically all the files that are being downloaded as XHR requests that are being made. There's all kinds of information. My primary use of them where I'm dealing with a. You know a front end framework that's communicating over APIs to a back end is to see OK what calls were made. What was the What was the response? Was it an error code? Was it, you know, error within the return JSON or the return, you know, whatever the response is, et cetera. So that's my primary use. I usually have, for instance, you can filter all the different items that are written to the console log. I usually have my fetch slash XHR button enabled so I can just see the traffic going back and forth. But you can see CSS files that are downloaded, JS files, font, images, et cetera, sizes, how long they took, and so on. And then you even have filter capabilities. So if you have a huge console, you can just type in and filter, and pretty standard stuff. What other stuff can you do in the network tab that I haven't touched on? 

MICHAEL: So what I see that's heavily utilized and also controversial most people are setting it on or off is disabled cache, for example. 

STEVE: Yes. 

MICHAEL: So we see people are running quite often either having it enabled. So cache is always disabled or disabled. And yeah, why is this useful? It's useful if you want to debug a code load of a website, for example, or if you're interested in performance debugging, where you want to replicate a similar situation and so on. In particular, in performance cases, disabled cache is quite often heavily used. 

DAN: Just a comment on that, as somebody who's really into performance, it's important to understand that while disabling cache is the easiest way to simulate the first load, it's not really the same, because in the first load, you're starting with an empty cache, that's true, but cache is not disabled. So if you have things like prefetches and preloads, disabled cache kind of kills them, whereas in the normal flow of things, they do work. So disabled cache, like I said, is the easiest way to simulate the first load, but it's not the same as the first load. If you want to do that, you probably want to do like open your like create a special profile or even use the incognito or whatever, that would be potentially a better simulation. 

MICHAEL: Yes, that's true. It's for users often about economics because we've like, we've been to get 80% there. So fine enough. Similarly, also going into with the, with demolition of the different network conditions. Um, that's also very often being used. Like the throttling feature, for example, that we see. 

STEVE: The throttling feature? 

MICHAEL: Yeah. 

STEVE: Okay, right. So in other words, as I understand it, that's, you know, if you're working on a, you know, a hundred gigabit connection on a very fast computer, you're gonna think, hey, everything is great, but then if someone gets out there, you know, in a remote location where they have 3G or, you know, something really slow, you're not gonna be able to see what those effects are. And so what this allows you to do is throttle down your connection so that you can emulate as best possible a much slower connection to see how your code loads and performs. 

MICHAEL: Right, but keep in mind that's only an emulation and as Dan already said, it's same with disabled cache, but only emulating. It's not 100% how it actually would be, but it's close enough for at least to debug such cases and to understand what's actually happening, and see how slow your webpage, for example, would load on a free G connection. 

STEVE: Alright, so best well any emulation is never going to be perfect, so I think that goes without saying, but it can certainly get you a lot closer. 

DAN: One configuration that I often like to change when I'm using the network tab is I actually prefer color coded resources. So the bars in in the in the waterfall part of the network. Actually, they show you the green for the time to first byte and then the blue for the actual byte downloads. But instead, you can go to the general settings. And in the network section, you can change to color code the resources. And if you do that, then instead of all the resources,being shown in green and blue, you'll actually see the JavaScript in yellow and the fonts in red and CSS in purple and HTML in blue. And it's much easier to identify the various different resources this way. So that's the only downside of that. And I've complained to you guys, Michael, about it, is that when you do that, you don't actually see the DNS times and the TCP handshake times. So you kind of either see this or you see that, you can't see them together, which is kind of unfortunate. In an ideal world, I would like to have it color coded and still be able to see the TCP time and the DNS time. 

MICHAEL: Right. Have you created an issue for that? 

DAN: I think I did. 

MICHAEL: OK. 

DAN: Like a long time ago. 

MICHAEL: OK. I need to check. That's interesting. One other thing that might also be useful in particular for performance debugging is also if you are capturing screenshots. Similar to the performance panel typically works with capturing screenshots and show you how the page actually looks at a certain point in time. You can also do the same thing for the network on the network panel and let it capture screenshots, which helps if you want to understand how the page is actually visually loading. 

STEVE: So if I go to the performance tab, I see the screenshots checkbox. You said it's on the network tab as well? 

MICHAEL: Yeah, yes. The network on the top right has the ski icon. You can click on that and then you will get some additional settings. 

STEVE: Okay, more tools. Oh, yes. Recorder rendering. Okay, yes, I see those three little dots there. And there are more tools. There's quite a long list of more tools. We could probably spend a few hours going over all these tools, that's for sure. But we don't have a few hours, so we're gonna wrap it up for here and move on to picks. Thank you, Mike, for coming. This is one of my favorite topics to discuss. And- 

MICHAEL:  Thank you for having me. 

STEVE: The more you understand the debugging tools you have, the better you can do it right in your code. Or in Dan's favorite subject, you can make it more performant. 

DAN: We didn't even get to the various performance tabs. Like there are like three or four different tabs just for performance and we didn't even talk about them. 

STEVE: Right, we might have to have Michael back to cover more of this stuff for sure. We do have, well. Put this in the show notes, the link to the list of YouTube videos on what's new in DevTools. I have found something to take up a large part of my afternoon for a while to catch up on these videos for sure. Who is that that's doing it? It looks like the same person. 

MICHAEL: Yes, it's just a normal person that's mainly doing them. They're just teaming up with colleagues of her. But it's mainly Justin. 

STEVE: Okay. 

Have you ever wished that you had a group of people that were just as passionate about writing code as you are? I know I did, I did that for most of my career. I'd go to the meetups, I'd try and create other opportunities and it was just really hard, right? The meetups, I got some of that, but they were only like once or twice a month and it was just really hard to find that group of people that I connected with and really wanted to, you know, talk about code a lot, right? I mean, I love writing code, I think it's the best. And so I've decided to create this community and create a worldwide community that we can all jump in and do it. So we're going to have two workshops every week. One of those or two of those every month are going to be Q and A calls, right? Where you can get on, you can ask me or me and another expert questions. Uh, the rest of them are going to be focused on different aspects of career or programming or things like that. Right? So it'll go anywhere from like deployments and containers all the way up to managing your 401k and negotiating your benefits package. Well, we'll cover all of it. Okay. And then we're also going to have meetups every month for your particular technology area. So we have shows about JavaScript, React, Angular view, and so on. We're going to have meetups for all of those things. I'm going to revive the freelancer show. We'll have one about that, right? So you can get started freelancing or continue freelancing if that's where you're at. And I'm working on finding authors who can actually do weekly video tutorials on some thing for 10 minutes this related again to those technology areas so that you can stay current, keep growing. So if you're interested, go to topendevs.com slash sign up and you can get in right now for $39. When we're done, that price is going to go up to $75. The $39 price gets you access to two calls per week. The full price at $150, which is going to be $75 over the next few weeks, that price is going to get you access to all of the calls and all of the tutorials and everything else that we put out from Top End Devs along with member pricing for our remote conferences that are coming up next year. So go check it out topendevs.com slash sign up. 

STEVE: Alrighty, so that will move on to pics. Pics are the part of the show where we get to talk about something other than code or we can talk about code if we want. All depends. Dan, what do you got for us? 

DAN: Well, I'm not. Not a lot this time, so I'll refrain from talking about the various wars that are going on in Ukraine and Israel, because it's just too unfortunate and sad and I don't feel like it. So instead, I'll mention a nice TV show that I'm kind of enjoying, which is called Killing Eve. It's on Netflix. 

STEVE: Sounds very pleasant. 

DAN: Yeah, it's about this It's like a woman led TV show. So there are two, like, I would say main figures there. One is this kind of wacko hit person for some clandestine organization. It's unclear for whom. And she's basically a psychopath, but they're taking advantage of that and using her as a hit person. And then there's the MI6 agent who's trying to hunt her which is the other lead figure female figure in the show and It's it's really interesting and I'm and I'm you know, it's not an amazing TV show, but it's a really enjoyable one And I'm liking it 

STEVE: awesome 

DAN: So those would be my picks for today and unfortunately, I actually have to drop off So Michael I really enjoyed our conversation today and and hopefully we can have you on the show again talk about more Chrome DevTools features, because I think we talked about less than half the panels. 

MICHAEL: I think it was a quarter of them. 

DAN: Yeah, and we didn't even get to the drawer at the bottom and all the options that are there. So there's a lot more to talk about. So guys, thank you for having me. And Michael, thank you for coming on. And I'll see you next time. Bye. 

STEVE: Shalom. 

DAN: Thank you. 

STEVE: All right, so my turn. Um, before I get to the high point of every episode, which are the dad jokes, uh, I do have one pick. One of the ways I, I do my working out exercises with CrossFit and no, I'm not one of those CrossFit people that always has to blob about me doing CrossFit, but, uh, there's this one, uh, piece of equipment that I have started using recently that has been a lifesaver or other handsaver. So part of CrossFit is doing a lot on a bar. So there's like pull-ups, bar muscle-ups, toes to bar, that kind of stuff. Bars can really, really, really, really tear up your hands. I've had that happen a few times. And so there's a company called Victory Grips. They make these grips that are various kinds. The ones I use are these leather ones. And what they do is they strap around your wrist and then it only has material right there in the palm of your hand. It's not like a glove or something that goes over your hand and so then what you can do is you can just use them while you're holding onto the bar and doing whatever you're doing. And then you can spin them around so they get out of the way for, you know, whatever else you're doing that you don't want them in the way and you can just put them back in place, but they give you a really good grip. A lot of bars tend to be really slick and it's really hard to do those kinds of workouts when you're trying to do a pull up by your hand slipping. So you're trying to get a grip half the time and wasting half your energy. So, but they're at victorygrips.com and they got some Some really great things. Even with them on, I've sort of torn up my hands a little time, but far less than if I didn't use the grips at all. And then finally, the dad jokes of the week. So I went out to dinner recently and the server said to me, there was refill your glass with water and they said, I see your glass is empty, sir, would you like another one? And I said, why would I want two empty glasses? as compared to a full one. Question, so why did the vulture get kicked off of the airplane? People kept complaining about his carry-on luggage. C-A-R-R-I-O-N for those who don't get it. And then finally, this one, I saw this, as soon as I saw this topic, I go, this one is just perfect. So I went to my boss and I said, what web browser do you use? He said, I use Chrome. I said, why does everybody on the team say you're always on Edge? Pfft. 

MICHAEL: Oh my God. 

STEVE: Very good. Very good. I figured that was appropriate for today. All right. So that's all I have. Michael, do you have any picks for us? 

MICHAEL: Okay. So I like playing board games. And I think I have one favorite game, which is called Spirit Island. So imagine, instead of you colonizing an island and then building a nice city there. Imagine you are actually playing the island that you are not very eager of being colonized So you're playing a spirit on that island that tries to defy the invaders Which is a great cooperative super complex of what came? Well, I really enjoy playing together 

STEVE: So you're playing so the other players you're playing as a team as compared to playing against yourself against each other 

MICHAEL: correct, correct Right. So you try to define invaders and they're all of us. So they have different spirits with different powers and so on, uh, with different complexity. And I always want to like, it would be cool if you would play something like a Godzilla or something like that. Uh, like wandering over the, over the island and then simply traveling everything. And, um, like a few months ago, actually they released an expansion and He had essentially Godzilla in there. It is a turtle, but it's like Godzilla. And it really feels that way. Like you are traveling over villages and destroy them because that's what Godzilla is doing. And yeah, I was like, you really needed it. I really liked it. 

STEVE: Spirit Island. That's something. Yeah. I've seen some other games. There's another game I played and I forget what it's called where it's like the Island is sinking and you're trying to get off of it. It's another. I have a neighbor who plays a lot of these types of games. So I have to ask him about this one, but yeah, it's a board game week. I'm not sure what the rating is, but there's a page there for sure. Excellent. All right, Michael. Well, thank you for coming on. It sounds like we do need to have you back to talk about more of the dev tools, considering at least for myself, they're sort of an integral part of web development. 

MICHAEL: I think so, love to. 

STEVE: All right. Thank you. And we will talk to everybody next time on JavaScript Jabber. Adios.