Modern Web Debugging


Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.

29 min
01 Jun, 2023


Sign in or register to post your comment.

AI Generated Video Summary

This Talk discusses modern web debugging and the latest updates in Chrome DevTools. It highlights new features that help pinpoint issues quicker, improved file visibility and source mapping, and ignoring and configuring files. The Breakpoints panel in DevTools has been redesigned for easier access and management. The Talk also covers the challenges of debugging with source maps and the efforts to standardize the source map format. Lastly, it provides tips for improving productivity with DevTools and emphasizes the importance of reporting bugs and using source maps for debugging production code.

1. Introduction to Web Debugging and DevTools

Short description:

Hello everyone. Today I'm going to talk about modern web debugging and DevTools. I work in the Chrome DevTools team and share exciting updates about Chrome DevTools. 15 years ago, web development was different. Now we use different languages and frameworks. I'll share tools to improve 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.

2. New Features for Quicker Issue Identification

Short description:

Let's start with how some of the new features that help you to pinpoint issues quicker. So, one of the things you'll do during debugging is check the console for error logs. Previously, irrelevant frameworks cluttered the console, making it harder to identify issues. Now, we hide the additional frames and show only what's relevant to your application. You can also view the call stack and hide irrelevant frames. Another feature is the ability to view your code first, making it closer to your IDE.

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.

3. Improved File Visibility and Source Mapping

Short description:

We show your component files first, making it easier to find and debug them. Angular applications also prioritize your files and blur out irrelevant ones like node modules. DevTools use Source Map to map your compressed files back to their original versions, ignoring framework files specified in the Source Map extension. Angular and Nuxt support this out of the box, while Rollup and Webpack have plugins and configuration options to ignore additional files during debugging.

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.

4. Ignoring and Configuring Files

Short description:

You can ignore irrelevant files manually and configure a list of ignored files in the settings. The files are visually greyed out to indicate their low importance during development. When searching for files using command P, the ignored files are also greyed out.

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.

5. Improvements in the Breakpoints Panel

Short description:

Next, I'll discuss some improvements we made to the Breakpoints panel in DevTools. We redesigned the UX to provide quicker access to common actions. Breakpoints are now grouped by files, making it easier to identify them. You can disable or delete Breakpoints by files, saving time. There are three types of Breakpoints: regular, Conditional, and Lockpoint. These improvements enhance the debugging experience in DevTools.

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.

6. Shortcut for Lockpoint and Conditional Breakpoint

Short description:

We added a shortcut to set a Lockpoint and Conditional Breakpoint. Previously, you had to right-click on the file or use a long shortcut. Now, you can simply command click on a point to set the Breakpoint easier. If you have any new features in mind, let us know and you might see them in the next release of DevTools.

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.

7. Debugging Challenges and Source Maps

Short description:

You can use command click to set conditional Breakpoints or Lockpoints quickly. Challenges arise when fixing the debugging experience due to imperfect source maps. Source maps map compressed files back to their original versions, but sometimes variables are removed. DevTools can show the preview and allow editing of values for mapped variables, but not for variables that are not in the source map. Source maps are an official standard that has not changed for a long time.

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.

8. Standardizing Source Maps

Short description:

Since 2011, we have been working on standardizing the source map format to improve the debugging experience. The current spec has some ambiguity, leading to slightly different interpretations and generated source maps. Our goal is to evolve and harden the spec, and ensure that all tools generate source maps in a standardized format.

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.

9. Dev Tools for Productivity

Short description:

In this part, I will share two tips to improve your productivity. The first tip is to use the toggle CSS class feature, which allows you to test different class styles on a webpage. The second tip is to override the HTTP response header using the network panel, which is useful when dealing with CORS origin errors. You can edit and add headers to continue development while waiting for backend changes. This feature is also applicable for loading JSON files.

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.

10. Using Header Override and JavaScript Snippets

Short description:

We can override the access origin for dummy JSON files. In the DevTools panel, you can save JavaScript snippets to run functions repeatedly. For example, you can highlight the largest contentful pane on any page using a snippet. Another snippet can retrieve and sort images on a page. Try using JavaScript snippets to simplify your workflow. Lastly, typing a search function on YouTube and debugging from there can be an effective technique.

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.

11. Putting Focus Back to Page and Debugging Tips

Short description:

To put the focus back to the page, click on the three-dot menu, pull out the rendering panel, and select the 'emulate a focus page' function. Another option is to use commands, such as 'command shift P', to access the command panel and run actions. Remember to report bugs and issues to the DevTools team. When debugging production or minified code, generate and save a source map in a secure location. Then, in the sources panel, attach the source map to debug the code.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance
user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
You will learn about one of the most popular package managers for JavaScript and its advantages over npm and Yarn.
A brief history of JavaScript package managers
The isolated node_modules structure created pnpm
What makes pnpm so fast
What makes pnpm disk space efficient
Monorepo support
Managing Node.js versions with pnpm

React Advanced Conference 2021React Advanced Conference 2021
27 min
Beyond Virtual Lists: How to Render 100K Items with 100s of Updates/sec in React
There is generally a good understanding on how to render large (say, 100K items) datasets using virtual lists, …if they remain largely static. But what if new entries are being added or updated at a rate of hundreds per second? And what if the user should be able to filter and sort them freely? How can we stay responsive in such scenarios? In this talk we discuss how Flipper introduced map-reduce inspired FSRW transformations to handle such scenarios gracefully. By applying the techniques introduced in this talk Flipper frame rates increased at least 10-fold and we hope to open-source this approach soon.

JSNation 2022JSNation 2022
30 min
High-Speed Web Applications: Beyond the Basics
Knowing how to run performance tests on your web application properly is one thing, and putting those metrics to good use is another. And both these aspects are crucial to the overall success of your performance optimization efforts. However, it can be quite an endeavor at times for it means you need to have a precise understanding of all the ins and outs of both performance data and performance tooling. This talk will shed light on how to overcome this challenge and walk you through the pitfalls and tricks of the trade of Chrome DevTools, providing you with a complete roadmap for performance analysis and optimization.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Workshop Free
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.

React Summit 2023React Summit 2023
171 min
React Performance Debugging Masterclass
Workshop Free
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2023JSNation 2023
44 min
Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
Workshop Free
You know that annoying bug? The one that doesn’t show up locally? And no matter how many times you try to recreate the environment you can’t reproduce it? You’ve gone through the breadcrumbs, read through the stack trace, and are now playing detective to piece together support tickets to make sure it’s real.
Join Sentry developer Ryan Albrecht in this talk to learn how developers can use Session Replay - a tool that provides video-like reproductions of user interactions - to identify, reproduce, and resolve errors and performance issues faster (without rolling your head on your keyboard).
JSNation 2022JSNation 2022
71 min
The Clinic.js Workshop
Learn the ways of the
clinic suite of tools
, which help you detect performance issues in your Node.js applications. This workshop walks you through a number of examples, and the knowledge required to do benchmarking and debug I/O and Event Loop issues.
TestJS Summit 2021TestJS Summit 2021
146 min
Live e2e test debugging for a distributed serverless application
Workshop Free
In this workshop, we will be building a testing environment for a pre-built application, then we will write and automate end-to-end tests for our serverless application. And in the final step, we will demonstrate how easy it is to understand the root cause of an erroneous test using distributed testing and how to debug it in our CI/CD pipeline with Thundra Foresight.
Table of contents:
- How to set up and test your cloud infrastructure
- How to write and automate end-to-end tests for your serverless workloads
- How to debug, trace, and troubleshot test failures with Thundra Foresight in your CI/CD pipelines