Modern Web Debugging

Hello everyone. Yes. So today I'm going to talk about modern web debugging and DevTools. So my name is Jesslyn. This is my handler because I like fish so much. That's why my handler is Jackfish as well.

So I work in the Chrome DevTools team. If every release you did not just dismiss this what's new tab, if you click on it, you might have seen my face before because every new release I will share some exciting news, exciting updates about Chrome DevTools and show you some tips about how to make you be productivity with Chrome DevTools.

So let's start my talk with this screenshot from 15 years ago. So this is the DevTools 15 years ago. You'll notice that there's much less tab, much less panel that you can use. And more interestingly, there's something called crypto as well. So crypto started since that time, but not really. The time, that time when we developed web applications, is so much more different than how we develop web applications now.

For example, back in the time you, when you started we just use HTML, CSS and pure JavaScript to do development. Then after that, we want to improve the performance. Then we start to compress and minify our CSS and JavaScript. Go to the days, now, nowadays what you write is not exactly what the browser reads. For example, you use different languages to write your applications. You use JSX, you use Spark, for example. You use CSS or less for CSS. You use TypeScript to replace JavaScript. And you use a lot of different frameworks as well, like Angular, React and Vue. And we have even meta frameworks like Next and Nuxt as well. And all these tools need to go through a process to compile it and compress it and transform it to what the browsers can understand. And we also need Vue 2 like Vite, Webpack, rollout and ESVue, like a lot of these tools to make everything work.

Now, since the day that we start Web development until now that we are no longer using just HTML, CSS and JavaScript to develop your applications, how about debugging? Do we have any advancement on debugging as well? So, today, I'm going to share with you a few tools to improve your debugging because it is important. This is us. We code for six minutes probably, copy paste, do some research, check GPT or Stack Overflow, paste the code in, but it just doesn't work and we spent six hours to debug it. Okay.

Let's start with how some of the new features that help you to pinpoint issues quicker. So, one of the thing that when you face and you have any issues during the debugging, the first thing probably you will go to is the console to see there is any error log in the console.

So, imagine you go to this page and then you see this console. It doesn't quite helpful when you do development. So, the first screenshot here is a screenshot from the Angular app, and the next one is from Vue.js. So, let me open a sample applications here. Okay.

So, for example, if I click on this increase button. If I open it, this is what we see now. So, previously, if you compare this screenshot, this application on the previous one, you notice that previously, you see a lot of irrelevant frameworks called like Zone.js, Async to Generator.js, like all these irrelevant JavaScript file which is belong to the framework itself. But now, if you open this, what we do is that we hide all the additional frames. All the irrelevant frames just show you what exactly happens in your application, your components. So, for example, you see, like, we show you, like, the problem could be in the app component and the button component. And if you want to see like the framework's code itself, you can click on Show More Frames and to open and check for all the others as well. But you don't have to do it. This is what you see previously. There's a long list until you can identify where is the issues.

Another thing that you can do is that during the debugging, we also improve the... So this is a Vue.js application. During the debugging, you have the same... We have the same features as well. So, for example, I put a breakpoint here. If I click on Add, increase the number. You can see that in the call stack, on the right here, we also hide all the irrelevant frames. We only show you what is relevant. Like, we show you the increment functions, and we show that you're currently in await functions in the increment. And if you want to see all the ignored frames, you can click on this and expand, and you see all the others that are not so relevant to what you are debugging right now. And another new feature that you can try it out is to view your code first. Like, some of the feedback that we get is that, from the view here, like your sources panel here, what you see is what the browser actually reads mixed with what your actual code, when you open it in IDE. So, if you want to see the view that's closer to your IDE, what you can do is click on this file button in the sources panel, select group by authored and deployed.

This way, what we do is that we show you your component files first or the file that your authored files first, whatever the browsers your deployed file will show will push it to below so that you can find your component quicker if you want to debug it.

The seams go to Angular as well. So if you go to the Angular applications, click on the three dot, group it by author and deploy, you can see that we show your web pack file, your sources file, your app, your component first as well. And this is not all, did you see that we actually blurred out the node modules because this is the file that you might not want to see as well.

So what you can do here is that you can also click on the three dot and hide all the files that is probably is the framework code. You can say hide ignore listed sources, and you click it and now you get an even cleaner page tree which shows you only your source files. Okay.

Then the next question is how DevTools know what to hide. Like do we apply AI to do that or do we not? So we use Source Map in order to do that. So Source Map, in short, so I have a video to explain like what are the Source Map and this is a joke. So there's a source and there's a map that are pointing. So there's Source Map. Yeah.

So Source Map is the file that we use to map your sources from the compressed versions of your file, map it back to TypeScript or whatever script that you are writing. So this is one of the examples of the Source Map. If you look at this file, there are sources field which consist of an array of different files, different original files that you are writing. This could be a TypeScript file or anything. So in this case, we have a full file and a library.js file. Imagine that the library.js is the files from the frameworks or any libraries. So what the frameworks can do is they can add another field, we call that Source Map extension but it's basically a field, to tell us that, hey, this file, lib.js file, you should ignore it. So as long as the frameworks or the build tools when they generate the source map file, when they populate this field, then dev tools will read that field and ignore the file accordingly. That's why you have the Cleaner Stack Trace. So framework need to tell us this. And then the good thing is if you are using angular or nuts, it is supported, it work out of the box. You don't need to do anything. And if you use read and roll up or webpack, webpack have a plug-in as well if you want to use. And you can also like for read and roll up, there is a field like source map ignore list that you can use to configure some additional file that you want to ignore during debugging. So this is an example of the roll up file. So if you, the source here is this one. So what you can do is that you can populate your, these are functions source map ignore list.

So you can return, you say that for whatever path that include node modules, just ignore it. Or for whatever path that includes like third party library, if you don't want to debug it, just add it there and you can start ignoring it. Okay. That's great. What if I'm a React users? Did I not mention, I did not mention any React now, right? So who is using, who is using React for development? Okay, so almost half of the room. Okay. We are working with the React team to have it out of the box, but it doesn't support yet. What you can do is you can do it manually. So from here, let me just show you. So for example, let's say this is your React applications, and let me just show the height as well. So let's say like one of these files, polyfield.ts file, this is one of the files that you don't want to debug. You can right click on the file, and you say add this script to acknowledge. That's how you can do it, or if the environment folder, like the whole folder, you don't want to debug. You can just right click and add the directory to acknowledge. This has the same effect the browsers did with the XGoogleAcknowledge, but in this case, you need to manually do it for one time for the browsers to remember your setting. So you can ignore the irrelevant files manually, and then you can also configure a list of ignore file in the settings. So once you ignore the file, there is a pop-up that will show up here. You can see that if you want to remove it from the acknowledge, you can just click and remove it. But if you want to configure it, you can click on the configure, and then you can open the settings and you can set your own custom exclusion rules. You can add more or put less inside. You can just disable it or just totally remove it. Okay. So, the good thing is like I mentioned just now, and what you see just now, the files are greyed out visually so that you know that these are the files that are not so important during development. And when you use command P to search for any file, we will grey out those files that are not important as well, that you have ignored. Okay.

Next, I want to talk slightly about beyondconsole.log. How many of you use console.log for debugging? Every one of us, right? This is us when we debug wherever, anyone use Breakpoint for debugging? Okay, not bad, still a lot of hands. So every time when we talk about console.log, we see that oh, everyone raised their hand and Breakpoint is like, oh, no, yeah, but... Okay, so I want to talk about a few slight improvements that we did in the Breakpoints panel to help you to use this feature slightly better.

So the first thing is that we redesign the Breakpoint UX to give you quicker access to some common actions. Now we group the Breakpoints by files, making it easier for you to identify which file is it. You can also disable or delete Breakpoints by files, saving you time and effort. Instead of scrolling through your file and disabling each Breakpoint individually, you can now hover over the file and use the shortcut actions to disable or delete everything at once.

Additionally, I want to mention that there are three types of Breakpoints in DevTools. The first type is the regular Breakpoint that you set by clicking on it. The second type is the Conditional Breakpoint, which allows you to set conditions for when the Breakpoint should be hit. And finally, there is the Lockpoint, which is similar to Console.Lock but doesn't require sprinkling Console.Lock in your code. With Lockpoints, you can avoid warnings about Console.Lock when you check in your code. These improvements in the Breakpoints panel will make your debugging experience smoother and more efficient.

Or you need to, like, right-click on the file. Now, what we did is that we add some shortcut action when you hover to the file. And we add a disable function here so that you can disable everything at once. Or you can delete everything at once as well.

And how many of you know that there are three types of Breakpoint in DevTools? Okay. Cool. There are good news for those who know as well. So, there are three types of Breakpoint in DevTools. The first one is the Breakpoint when you click on it, then you set a Breakpoint, that's done. The other type is Conditional Breakpoint. So, when you want to hit the Breakpoint, only when it reaches to certain conditions. For example, you need to be on certain numbers. And then, you can use this Conditional Breakpoint to set your conditions so that you don't just keep on breaking on it because you just want to break when you need it. And the last one is Lockpoint. Lockpoint is like Console.Lock, but the good thing is that you don't need to sprinkle Console.Lock in your code. And when you check in, right? Then you maybe get some warnings that there's Console.Lock in your code, please remove it. Using Lockpoint, you can do it in DevTools and you don't need to add the... it has the same features and you don't need to do it in your code.

So the good news here is, we add a shortcut to set a Lockpoint and Conditional Breakpoint. Let me show you here. So, in the last conference I went, we have this shortcut which is using command, option B, in order to set Conditional Breakpoint and Lockpoint Conditional. But then there is this... one of the attendee just told me, how about you don't give us a really long shortcut. Just give me... what I want is that when I click on a point just support a command click and then just help us to set the Breakpoint easier. You know, this is like easy request but we just, our team just never thought of it before. And now that we added the command click. So, if you have any new features in your mind, you can talk to me later and tell us. Probably you will see it in the next release of DevTools. Who knows? Okay.

So what you can do here is you can instead of right click you can use command click on any of the line to set a conditional Breakpoint or a Lockpoint. And to make it even quicker what you can do is that next to all this list of Breakpoints, you can click on the edit button to toggle the edit of the conditional Breakpoint or the Lockpoint. Last time what you need to do is that you need to go here and then you right click and then you add condition, edit the conditions and stuff like that. Now you can just use command click to do that.

Okay. I also want to share with you some challenges that our team when we try to fix the debugging experience, we hit some root block and we are trying to solve that. Source map as I mentioned just now is not perfect. So for example, this is a function. In this function, in this random reading functions, I have a number variable and a grid variable. And I use this both variable to compute to show up the test, grid and num. And in this case, you will use some minifier or some build tool to compress it. So this is your compress file. So minified JavaScript file. So what you see here is that you see hello E. And what you can see is that the number variable now become a shorter variable, E. And there's no grid variable as well. Because the great was removed. Because your build tool is so smart, it know that it doesn't need it during the run time. So it just totally remove it. This is okay if you don't debug your code. But if you are debugging your code, this sometimes might happen. For example, here, when you are debugging into the functions, what DevTools will do is that for the number, we can show you the preview of the value, and you can edit the value in the scope pane as well. But we cannot do that for the grid. Because this information is not mapped at all. This information is not in the source map at all. And it's impossible for us to know this variable. Because we will just know information for us to map it. So for your information, source map is an official standard. Although our development changed for so many years. But source map spec is not changing for a very long time.

Like, since 2011, it's 12 years from now. It hasn't changed much. And what we are currently doing is that... There are a few teams currently doing is that we are trying to standardize the source map, work with a web standards organization to get it standardized, so that different tools, different build tools or TypeScript or whatever tools when they generate our source map, it's in the format that everyone agreed upon. The current source map spec has some ambiguity in the terms itself so everyone sort of interpret it slightly different and generate out some slightly different source map. And we are also working on evolving the source map, harden the spec, and to improve the debugging experience. So we need build tool and other tools to work together to improve it.

Okay. The last part is about dev tools for productivity. So I want to share with you some tips to improve your productivity. Okay. So the first one, start with toggle CSS class. Who here use Tailwind CSS? Okay. If you use Tailwind CSS, so let me open the Tailwind page. Or if you are not, it works for all the other CSS files as well so this is the Tailwind webpage. So what I do here is I will focus on this and then you can use, you can toggle this class and what you can do here, you can just try to toggle different class to test on the different features. And what you can do, you can also type like, for example, I want to set the background so it will show you all the class that you have defined for the background. And if you want to remove the, you want the text to be centered, you can use this dot class field, toggle it, open it and then toggle the class and play around with it. So, this is one of the features that you can use.

And another one is that to override HTTP respond header. So, I think most of us in our development journey, we sort of hit this error before. Let me just refresh this page. Oh, no, is it okay? Okay. So, we sort of hit this course origin errors. Oh, no errors now. Where's my errors? Really? Oh, yeah, the error is here. So, it say that this, that there are some access control allow origins here doesn't work. So, what we need to do here, sometimes you just go to the back-end or if you are a front-end engineer, you will ask the back-end to like add some course header in the back-end. Let's say you just want to keep on developing. You sort of want to overwrite that in the front-end while waiting for the back-end changes. What you can do now is you can go to the network panel, click on the request, you can edit, you can overwrite the header to add whatever you want. So, in this case, what I do is that I will add a header, I will add the access origin course header and I just set it to all because I just want to continue my development. And what I do here, if I refresh the page, see, it will start loading all the JSON file at all. Yes. Cool. This is a really new feature that you can use. And not only that, you can do the same thing basically for dummy JSON because we only do that for To-Do JSON.

We can do the same thing for dummy JSON. What is even better that you can click on this header override link so it will link you to this file. Basically it's a file. So what we do is that you can change this apply to to change it to a wildcard. So you say, like, all the JSON file, I want to change the access origin. So I will just refresh. See, now after you change it, you can load the dummy.json file as well without any effort. Nice, right?

Okay. And another thing is that in the DevTools panel, it supports JavaScript snippets as well. So this JavaScript snippet, what you can do is can save you a lot of time, especially there are some functions that you need to run over and over again. You can just save it as a snippet. So for example, in this page, I have a getImages snippet, I have a getLCPS snippet. So I want to always like get the largest contentful pane in this page. So I have this snippet here which will help me to highlight it. So no matter what page I'm in, so for example, I'm in the Elements panel. If I want to run these functions, what I need, once I save the snippet, what I can do is I can click Command P and then I can use the exclamation mark and then I just run the function. So for example, getLCP in this case. So in this case, it will just highlight the greatest LCP things for me because I know that this is as performance engineer, this is the function that I will run over and over again. So I just save it. So for example, I have another function to get images. So in this function, when I run it, it will get all the images of this page and then I can like sort the page, sort the size so that I can see like what are the images that I can remove from this page. So try it out. Use the JavaScript snippet to make your life easier.

And the last one, this one in the last conference, when I shared this, I get a lot of claps. Let's see if this one gets more claps than the overwrite. So let's go to YouTube. What sometimes is we do is that we want to type a search function here. And from here, you might want to debug. There's some issues here. You want to debug this.

But whatever you click on the want to focus on the element, it is gone. So what you can do here is that you can click on the three dot menu, pull out the rendering panel, there is a function called emulate a focus page here. So this function helps you to put the focus back to the page instead of in dev tool. So if you click on it, bam! It will keep showing and you can edit it. I tell you, these features have been there for ten years or many years and... Yeah. Before even I joined Google. Yeah. So this is a good feature.

And if you don't remember the rendering tab, right, the last thing I can get you is that everything is a command. So you can use command, basically, you can use command shift P to pull out the command panel to run it. And if you don't remember this command, you can always click on the three dot menu, click run command, and you can click, like, focus page. And do not emulate focus page and emulate focus page, or you want to set the page to, like, switch DevTools to Doug Team. Just pull out that and you can basically run any command, open a panel, and do some actions just with the command panel itself. Go to run command. Okay, with that, I left 38 seconds.

And this is one last thing. I go to, like, conference, a lot of people just told me, I never report the bugs. And DevTools will just fix them automatically. There are some bugs that is really annoying you. But you just think you don't need to report it, and DevTools team will know it. Unfortunately, we are not AI, so if you have any issues, report it in this URL or just tweet it at Chrome DevTools so our team know that you have these issues and we can fix it. That's all. And there's a link for the slides if you want to take the slides. And thank you, everyone.

One question for you. What would be your top tip for debugging production or minified code? If you are going to debug a production for minified code, what you can do is that you can generate a source map and save it in a secret place. And then when you really want to debug it, you can, in the sources panel, you can right click on any JavaScript file, click on attach source map, and you can attach your source map of the production code to debug your code. So this is easier. And you can hide your source map from anyone else. Just attach it when you need to debug your production code. Amazing. Thank you. And then there was clearly a lot of interest. So if you have questions, please go over to the booth or find you later on your socials or something like that. And thank you so much for the talk. Thank you. It was great. One more round of applause, please.