 Welcome! I'm Michael Hablich, Product Manager on the Chrome team. In this talk, I will demystify Chrome DevTools features that help you as a web developer to debug in web applications more ergonomically. I will cover how Modern Text Act changed the requirements on debugging tools and how interactive debugging techniques are used to make debugging easier. Finally, I want to highlight how you can help the Chrome DevTools team to help you. Okay, let's start. DevTools exists for nearly 15 years already. Here you can see a screenshot of the launch blog post of Chrome DevTools from 2008. 15 years ago, the web looked very different. No big frameworks. No chairs. Slow JavaScript. The in-top gap between browsers was even bigger than today. Essentially, web applications, how we built them today, were not on the menu. Web applications started to get written in TypeScript, SAS, and new inventive markup formats. WebAssembly even brought any source language to the web. This also made the requirements for developer tools change. Source maps were invented. Transpilers and bundlers like Babel and Webpack emerged. Made the frameworks got popular. Big frameworks even built their own developer tools to make their users cope with the complexity. For example, React DevTools, Angular DevTools, Flutter DevTools, and so on. Last year, the Chrome DevTools team took inventory of how well debugging works with the current web application tag stack. The vast majority of web developers are using at least one of the big frameworks. This means Chrome DevTools target audience is using at least one of the big frameworks of force 2. As I said, the Chrome DevTools team did the deep dive. The verdict, it works if it's set up correctly and well maintained to keep pace with the contents change to applications. The result, developers can debug a cache. Essentially, there is a narrow, well-lit path that works well for a few pedestrians a day. That's not enough for today's reality. As mentioned in today's web applications, 10th of different tools and frameworks are combined to create a resulting web experience. Actually, we would prefer something like this. A well-coordinated, low-accident, high-throughput, well-lit cross-section. Building such a street involves a lot of parts and stakeholders to make sure that there are no accidents. Transpilers like Babel, debugging tools like Chrome DevTools, frameworks like Angular, React or Vue, technologies like Source Maps, standard bodies, and so on and so on. That's a lot of complexity requiring plenty of orchestration. In 2022, the Chrome DevTools team started to tame this complexity and asked the question, where's the most friction for developers when they debug modern web applications? The 10th different tools and framework used to build and deploy a web application make the code the developer actually debugs in Chrome DevTools very much different to the code they actually wrote. This can be quite a speed bump when debugging. So what if you can actually debug the code that they wrote instead of the code that they ship? Let me show you a selection of readily available features that you can use today. For each of the features shown, there is a link to the documentation with a lot more in-depth information provided than in the slides. Nowadays, if you open the sources panel and navigate the files with the page explorer, you get hit with this mesh of artifacts. You will notice duplicate files, some of them your actual source files, some of them are the files that the browser receives. That is confusing. Last year, Chrome DevTools introduced the concept of the offered and deployed view. It lets you navigate both worlds. The good news is that you don't need to do anything to use both views in Chrome DevTools' source panel, except to enable the experiment in DevTools, like this. It will automatically appear when source maps are detected. I will talk later more about source maps in case you wonder what they are. As you can imagine, there are some rough edges. In collaboration with frameworks like View and Bundles like Veet, we planted set edges quite a lot lately. So you should consider updating to the latest version of set frameworks and bundles. And of course, don't forget to update a Chrome version. When using dependencies or building on top of frameworks, the third party files can get in your way. Most of the time, you only want to see just your code, not the code of some third party library, tucked away in node modules. Or maybe you're working on a big team and you're not interested in taking a deep dive into the scheduler code every time you need to debug an event handler. Chrome DevTools has recovered. With IgnoreLists, you are able to ignore and step over specific files and folders. Roughly, this manifests in three things. IgnoreLists and folders we will create out in a page explorer. You can also make them completely invisible. Stacktraces will not show these code locations, and thus the stacktraces that you see will be a lot more relevant than to the point. This works in the console and the debugger interface itself. Chrome DevTools is automatically configured to ignore for party scripts. You can populate this IgnoreList manually, or if you're in luck, your used framework already does the needful for you and tells Chrome DevTools which folders to ignore. For example, Angular supports this feature since version 14.1. Supporting VIT, rollup, and NUXT has recently landed. Stackframe ergonomics can be made even better with linked stacktraces and friendly callframes. Your chosen framework needs to support them full. If you're using the latest version of NUXT or Angular, you should have them ready to go out of the box. A lot of the transformation between the code you wrote and the code you shipped is codified with a technology called SourceMaps. Chrome DevTools and various frameworks receive a bunch of optimizations on how SourceMaps are handled and leveraged. In case you're abandoned using SourceMaps over the years, give them another shot. In case you've never heard of SourceMaps before, you're probably already using them under their hood, as every major framework or bundler is generating them in the DevBuild configurations. To see if SourceMaps are loaded correctly by Chrome DevTools, there is a nice little draw called developer resources that will serve as any errors. You can find it in other tools, developer resources, or via the command palette. Modern web applications are complex and often debugged with console log. Console log is great and sometimes not enough. That's when interactive debugging becomes relevant. Breakpoints, logpoints, stepping through code, etc. Let's have a look. I guess most people are accustomed with breakpoints. You pause the execution at a certain point in the application. Now consider that you're setting such a breakpoint in a function that processes all incoming events like the code shown here. You notice that handling click events has a bug. As mentioned, all incoming events are sent to this function including mouse position changes. If you set a breakpoint in here, you're going to break a lot. You can convert an existing breakpoint to a conditional breakpoint, which will only pause the execution if the condition is true. So in this case, event.type equals click will only pause the execution when a click event is processed. Let's try it out and debug it. I already talked about source maps and that enable Chrome DevTools to make a connection between the code you wrote and the code you ship. So if source maps are set up correctly, you will be able to step through the code you wrote automatically. Console log and its siblings, console trace and console debug are super useful to understand what's going on in the application. They have one big drawback though. You need to add them to your code and sprinkle them all over the place. This requires redeployment of affected code paths. After the debugging session is done, all the console log statements need to be perched. Log points are a non-invasive alternative, providing you most of the benefits of console log without requiring code changes and redeployment. Add them with a right click on the breakpoint path in the sources panel. Same as you would add conditional breakpoints from scratch. You can add any JavaScript expression and it will be logged to the console. Which can result in a lot of logging to the console that you can also ignore, of course. Now consider that you are deep into your debugging session and you want to get the help of a colleague. The teammate wants to reproduce the bug locally. Instead of writing out the reproduction steps, you can use the Chrome DevTools recorder to record your reproducer and share them to export at the recording. How? Open the recorder panel. It will record interactions on the currently opened page. Finish the recording when you are satisfied with your reproducer. Don't forget to try out your recording replaying it once locally. When you are satisfied, use the export menu to save the flow in a local chasen file or public script. Your colleague can use that file to import it into their local DevTools, with the recorder panel again. That's it. This import-export flow can also be extended by Chrome extensions in case you need a streamlined integration, for example with a test infrastructure or bug tracker. Going back to my metaphor on biting the well-lit path for web debugging. Obviously, we also want to increase the lightning of the path. This involves updating the wiring to cope with the increased throughput, and in particular also listening to feedback. New streets should never be built without involving the neighborhood. At the end of last year, Chrome DevTools introduced their request for command, ROC in short process, to give web developers, framework vendors and library creators out there the chance to have a voice when major changes happen in Chrome DevTools. You might have noticed that over the past year, the UI for handling breakpoints in Chrome DevTools received an overhaul. Before committing to one direction, the DevTools team did put up an ROC to influence the direction. If you want to participate in future ROCs, keep watch of our dedicated GitHub repository and or follow us on Twitter. We of course also listen and fix. In 2022, up until now, the Chrome DevTools team has resolved over 130 long-standing friction-creating bugs. It's a tedious and worthwhile endeavor with more to come in the future. Summarizing. Here are three things to upgrade your debugging in Chrome DevTools. Use the authored and deployed view to focus on the code that you wrote. Extend this view with a no list for even better results. Conditional breakpoints let you define at a more granular level when to break because sometimes a simple code location is not enough. Lock points are a non-invasive alternative to console lock, providing you most of the benefits of console lock without requiring code changes and redeployment. With the extensive recorder, you can easily share reproducers with your colleagues. So, that's it for me today. If you're interested in more techniques to debug modern web applications, subscribe to our What's New in DevTools series on YouTube or read our Accompine blog post on this topic. We would be delighted to get your participation in upcoming features via Chrome DevTools RFC repository or Twitter. In case you spotted bug in DevTools, file is an issue, so the DevTools team can take a look. Thank you for watching and have a pleasant day.