 Welcome back. DevTools is shipping with five new features in Chrome 63, including multi-client debugging, Workspace is 2.0, custom push notifications and background sync events, and four new audits. Up until now, DevTools hasn't played nicely with other developer tools. If you've ever tried debugging a Chrome driver test with DevTools or using the debugging extension in VS Code or WebStorm, you know what I'm talking about. Once you open up DevTools, your session and that other tool gets demolished. As of Chrome 63, this is fixed. We call it multi-client debugging, and it opens up a whole bunch of new interactions between tools. Generally speaking, clients can now run at the same time as DevTools, and multiple clients can now connect to the same time. For a while now, we've had a feature called Workspaces, which essentially lets you use DevTools as your code editor. Within DevTools, you make some changes to your code, and the changes get saved to your file system. Version 2.0 brings some UX improvements to this workflow. Here on my desktop, I've got the repository where I frantically hacked together the last minute demos for these videos. Let's serve the repo locally and work on the demo that I'm going to show you next. To map the local code to the network, go to the Sources panel, then click the File System tab, then drag and drop the directory. Chrome asks you to confirm that you want to give DevTools read and write access to the directory. After I reload the page, there's a green dot next to some of the files in the Network tab. This means they're mapped to local resources. DevTools does these mappings automatically. Style changes in the Elements panel persist to disk, for example, when I change the color of this H1. The green dot here next to the link means that this change is persisted in the source. Click on the link, and back in the Sources tab, we can see the change has been written to the file. Just to confirm, let's run git diff on the repo, and yes, we can see the change has been recorded in the Git repo too. Now, a big current gotcha to be aware of is that changes you make in the DOM tree don't persist. For example, change this H1's text, go back to the Sources panel and view the file there, and the change isn't there. Reload the page, and the text reverts to what was there before. So if you want to persist DOM changes, just edit the file from the Sources panel. Reload the page, and you can see that the DOM change persists across pagelets. In the Service Workers tab, you can now send push notifications with custom content and background sync events with custom tags. Go to the Application panel, then click the Service Workers tab. To send a custom push notification, put some content in the pushbox, then click the Push button. To send a background sync event with a custom tag, enter the custom tag in the sync box, then click the Sync button. For this demo, I've just set up the Service Worker to log the tag text to the console. In real apps, this feature is useful when your app is offline and you want the Service Worker to do some work once an internet connection is re-established, using the tag as the command keyword for which logic to execute. The Audis panel has four new audits, including Serving Images as WebP, using images with appropriate aspect ratios, avoiding front-end JavaScript libraries with known security vulnerabilities, and logging browser errors to the console. That's all for Chrome 63. Here's a tip about a lesser-known DevTools feature. Say you're debugging a page or deconstructing somebody else's page, and you want to study the logic that gets triggered when an event fires. You could dig around the code and search blindly for the event handler logic, or you can use an event listener breakpoint. Here I've got Serma's Tinder for Bananas app open, and I really need to figure out what logic runs when I click the Like button. To set an event listener breakpoint, go to the Sources panel, then expand the event listener breakpoint section. Check the mouse checkbox to break on any mouse event, or expand the section and check the click checkbox to break on click events specifically. When I trigger their click listener by clicking the Like button, DevTools automatically pauses on the first line of code in the listener. Sometimes an event causes multiple listeners to run. For example, if you've got some analytics tracking setup, you might pause in the click listener from the analytics code. In which case, you can just click Resume Script Execution, and the page runs until the first line of the next event listener. That's it. Thanks for watching. See you in six weeks for Chrome 64.