I do it when I want to look up what a value of a returned variable is too without putting it into my script, in example say I want to know the value of document.getElementById("element-name").getBoundingClientRect().top, I type that into the console and I can see how it behaves while I scroll around to get a better understanding of the values I will be working with, or I can omit the .top entirely and see the array of values I can work with, like height to see how tall the element is, etc.
@@ΣτάθηςΣταθόπουλος-σ7ρThat is a good approach, but I prefer to get really close by using a multimeter with a probe on my motherboard. then disabling the clock signal and replacing it with a pedal switch. Then you can do everything step by step, and It is good exercise.
One thing to note about the error location. JavaScript is an interpreted language, so the error message shows the first line that was unsuccessfully read. it is possible that the actual error may be further up the file, as the interpreter attempts to make sense of the code till it can no longer make sense of it. it is true that data is a major cause of run time errors, but also bad syntax can be a cause, as the interpreter will often try to make sense of poor syntax and allow it to interpret code that is bad.
I cannot believe how many people don't do this. All the time when pairing up with coworkers I'm like... "Why are you writing it twice... just object-ify it."
As a 40 year veteran I constantly amazed at young developers not wanting to use the debugger. If you are not using a debugger you should definitely give it a try. Not only for debugging but for testing. I almost never release a bit of code without stepping through it once to verify it works as it should.
Yeah I use the debugger all the time. Sadly I sometimes have to work with code that doesn't have great debugger support and it hurts my sanity. I mean having logging isn't wrong but the debugger is the most important tool.
There is a tendency to stick with what you know even after it is no longer the appropriate tool. The simplest thing is to use console.log or printf or whatever and that’s fine for really simple projects like you might do in university. Debuggers are really useful for tricky code and medium sized projects. On really large projects, you can waste a lot of time using a debugger. This is especially true when there is a lot of data structure that needs to be visualized. Having a good logging system then becomes indispensable. If reading the log doesn’t help you identify the problem, it will at least tell you where to set the breakpoints and when they should be activated.
Hey man, Thank you for your videos! You really upskilled my knowledge to get through this javascript jungle. It's very overwhelming but you are really adding "simplified" in web dev simplified! Cheers
I've been working as a front-end dev for 10 years now, and still find your uploads helpful, thank you! Maybe one thing I would like to add, that I use a lot, is stopping at a breakpoint, and pointing my cursor on variables, to find out the value of the variable at that state.
Now Kyle, hold on for just one second. 10:35 When you say “step into handles asynchronous code”, you’re not exactly right I think. You see, the step into button actually changes the location and goes into the function call you were currently at; however, if the function is not pure JavaScript and instead is a ‘native code’, there is nothing for the debugger to step into so it skips a number of steps until it can reach the function that is acceptable down the stack. So when we’re not dealing with the setTimeout or any other built-in function but rather with the regular js, the debugger just steps into your code step-by-step like a regular interpreter would do. However, I really liked your point with the setTimeout step into. I wonder if the debugger employs certain heuristics to decide where the developer were actually intending on stepping into :) Thank you!
Helpful, for me 90% of writing code is write, test, debug, write, test, debug, build up piece by piece. If you do not have strong debug skills you are not going to be able to build up large programs. If you inherit code, debugging is most of what you do, in order to figure out what the code you inherited actually does (or does not do).
Debugging in VS Code also works for TypeScript. It may require simple configuring of a compiler, but as I remember, by default it's already configured properly. The goal of configuration is to tell the compiler to create a mapper file which maps a place in the compiled non-readable JS code to a corresponding place in the source TypeScript code. Everything else does the VS Code and browser. The browser's debugger via a special API sends to VS code the current position and other information and VS Code debugger uses the mapping file to translate this position to the actual position in the source code. Also this mapping file is used to deobfuscate the variable names. The technology may seem complicated but it all works under the hood, transparent to the programmer so you don't have to think about it. And identical approach is used for back-end debugging for decades, so the technology is well tested and it works excellent
Basic Debugger tips get a llinter/spell checker and learn to look at the code color differences & what they do in your IDE. Do not use console.log unless you are debugging. Issue with debugger is your code might not get there at all. Sometimes you just have to update DEV with logs and then make guesses, this is rare but can happen. Most DEVs just need Fetch in Network, unless you are working on UI work and even then it is where I stay 95% of the time when only doing UI. VSC debugger will not work in most frameworks so basically pointless. Like the uncaught, most of the time I know when I make them but still. Also think in larger projects I would never be able to get out of some of them.
Great overview of all the things you can do in the debugger tools. You only missed one bit, it is actually possible to modify the scripts directly in Chrome too so you can test out stuff without having to reload everything. I frequently actually fix a bug inside the debugger in Chrome first and do some more tests before fixing it in my code. When projects get bigger reloading everything can be a hassle at times.
I find the most frustrating thing about programming is lack of good documentation (what happened to tech writing?) and trying to find and fix bugs in other people’s code! The only way AI will ever be able to help us code effectively is by having well-written, well-documented code written by humans.
That was great! I thought I knew a lot, but only what I *thought* I needed to know. Thanks for deep diving into all the options and the VS Code debugging too!
Anonymous functions are unnamed, usually lambda, functions like the `timeout()` callback. The outermost anonymous is the internal caller to `main()`. (there's no particular tie between "anonymous" functions and "top-level"
I've been programming for 14 years, and I can confidently say that after all this time, there were still many things I didn't know, but I learned them in this video. Thank you brother
i use it and will be using it...i know there are many ways to debug...i use other things as well but console log is classic and very nice to debug with... it's been 7 years
@@wchorski for terminal you just "docker logs" with a name or id of your container as a parameter. docker ps -a to find all running and stopped containers
Another cool thing you can easily do within Javascript is to hijack the console.log function call and output it on a div you can e.g. dynamically show on top of your content. Admittedly the console in chrome is more powerful with how it displays objects so you would then have to implement that yourself. But at times I often like to have some simple debugger overlay in my actual page content, especially when watching some variables, but in those case I naturally make some kind of of custom logger class/object that all the code can use anywhere.
great job! I did not know, that it's possible to debug the frontend, something new for backend developers, I think we need tutorial for the whole tabs in dev tools
There is a reason the phrase "script kiddie" was a thing. These coding bootcamps are pumping out people who expect to go into an organization and use the latest tools, frameworks and languages ON GREENFIELD projects. Any developer/programmer who has real experience will know GreenField projects are rare and more often than not, you will be working on legacy code (ironically built with the latest and greatest tech of whatever time-period it was created in). Debugging skills are crucial to success. When we lowered the bar of entry, we let in hoards of people who did not have basic/traditional programming skills, and only knew what they read in a tutorial or watched in video. It's scary times out here. The problems such people create are the very ones I've had the fortune (and misfortune) of working on over the last 10+ years.
+1. Got absolutely the same experience. Having jung people coming from the university. Never touched the Linux console and never ever heard about *vim.*
Is there a way to break and catch exceptions on promises, especially with 3rd party scripts that swallow errors and serialize functions so they are illegible?
To be fair, console.log() or printf or whatever equivalent does the job in 80-90% of the case. It's why I never use the debugger unless I'm in real trouble
Thanks a ton for this videos, we need more of this kind of debugging in depth videos. It would be really helpful if you can make something like performance optimisation in React or vue app.
It's not so relevant to this video but since console.log has come up I wanted to mention that Console Ninja has been a beneficial extension in VS Code. It shows the console.log results from the browser next to the code calling it within VS Code. I've used that a lot for debugging.
All of this is fine and dandy, now do a video about the unholy mess that is react and how to debug a chain of useeffect and usewhatever, sudden memory leaks. Since i moved on from react i spend more time with friends and family, or in the vs code editing new code than banging my head in another all-night debug session.
I highly encourage to not use debugger in embedded apps, e.g Tauri apps will loop on internal functions and invoke backend code completely ruining DX on the frontend.
Another good one is console.time("foo") and console.timeEnd("foo"). This is shows how much time has passed between the two, super useful for measuring performance.
Great overview of debugging features! It would have been great, though, if you at least mentioned that Firefox and Safari have similar DevTools, or even showed them.
As the code base grows the debugger becomes more significant. If you join a project and have never seen the code then your really want to track where things are going. You may have to close 15 files when you are done but the bug you are fixing can happen anywhere in those 15 files and good luck not missing some files if you don't.
Thank you Kyle! I knew much of this but boy did it spackle in the gaps! This is exactly the kind of tutorial I look for. Super appreciative! If by chance you read this, apologies, but… Semicolons! Yes, they matter.
This motivated me to actually get the debug from front js inside vscode I didn't immediately managed to do it on first try and abandoned the idea... but it's actually working now and way more convenient (except i have to bundle with the mapping in the same file, if you know how to bundle via bun with mapping in a separate file while still making it work... please give me the secret)
Running code often, as it is being written is the best way to spot errors. I have seen the expert coders bash out a few hundred lines of code in 10 minutes and then spend 2 days fixing all the errors.
Most of these were familiar to me, but it's always good to fill those gaps in the knowledge. Triggered breakpoints I imagine would be great when you need to break conditionally, but the dependency is not in scope.
I enjoy using debuggers and I naturally always do so when using C#, C or C++ in an IDE where launching the program with the debugger enabled is the default. However when it comes to the browser debugger, I know it exists and I've sometimes used it, but the barrier to entry is often so high that I resort to console log instead..
Hello Kyle, thanks for the video! Could you please share your setup for audio/video recording? I'm impressed by the audio quality in your videos, considering you're in an empty room without acoustic panels. I started my own TH-cam channel, but I can't even reach a similar sound quality like in your videos... Lots of mic noise, room reverb and keyboard sounds
I also make videos, but have never had any problems with background noise. Even without a special setup (e. g. acoustic panels). Maybe it's the microphone?! I use the RØDE NT-USB [th-cam.com/video/obPxRUr7sGU/w-d-xo.html] which has an amazing good sound quality.
@@igomesigomes with console.log :) and overextended brainpower. I too find this video enlightening, and looking forward to seeing how it will change my life. Probably a lot :) What I find most interesting though is that I did use debuggers and breakpoints in many other languages, and yet it didn't occur to me that JS has it too. s/most interesting/the real WTF to be/ - but then again, I'm officially a sysadmin, not a developer, so... ;)
That is actually an amazing video. I'm myself a dev with around 5 years of exp and I found several new things. Especially the debugging + vs code debugging section is priceless!
what would you say is the best way to debug in a web app on an ios device web browser without needing to buy 3rd party software or by having the correct MacOS for an ios device?
How many people are here only use console log for debugging
I do it when I want to look up what a value of a returned variable is too without putting it into my script, in example say I want to know the value of document.getElementById("element-name").getBoundingClientRect().top, I type that into the console and I can see how it behaves while I scroll around to get a better understanding of the values I will be working with, or I can omit the .top entirely and see the array of values I can work with, like height to see how tall the element is, etc.
Uuuhh, I plead the fifth
Still the best 😅
I just learned about console log. I used to compile my react app down to web assembly and use IDA to debug it
@@ΣτάθηςΣταθόπουλος-σ7ρThat is a good approach, but I prefer to get really close by using a multimeter with a probe on my motherboard. then disabling the clock signal and replacing it with a pedal switch. Then you can do everything step by step, and It is good exercise.
Please make more of these debugging videos , really helpful stuff
this is as usefull as console.log, considering mst people use a combination of vite / typescript.
One thing to note about the error location. JavaScript is an interpreted language, so the error message shows the first line that was unsuccessfully read. it is possible that the actual error may be further up the file, as the interpreter attempts to make sense of the code till it can no longer make sense of it. it is true that data is a major cause of run time errors, but also bad syntax can be a cause, as the interpreter will often try to make sense of poor syntax and allow it to interpret code that is bad.
One more debugging point if you want to be bit lazy
Not lazy version:
console.log("value", value)
Lazy version:
console.log({value})
Lazy deluxe version: Make a VScode snippet
I cannot believe how many people don't do this. All the time when pairing up with coworkers I'm like... "Why are you writing it twice... just object-ify it."
I think I’m in love with you for this tip omg.
I cant believe i havent thought of this, oh wait i can believe.
Use this a lot, specifically for functions so I can test those at different points.
Downloaded this *amazing masterpiece* and placed it in the middle of my desktop.
Thank you so much for the support! I am really glad you enjoyed this video.
As a 40 year veteran I constantly amazed at young developers not wanting to use the debugger. If you are not using a debugger you should definitely give it a try. Not only for debugging but for testing. I almost never release a bit of code without stepping through it once to verify it works as it should.
Thanks for this, I’ll try it out
Yeah I use the debugger all the time. Sadly I sometimes have to work with code that doesn't have great debugger support and it hurts my sanity. I mean having logging isn't wrong but the debugger is the most important tool.
Yeah, try clicking 10,000 times through a loop. Log it!!
There is a tendency to stick with what you know even after it is no longer the appropriate tool. The simplest thing is to use console.log or printf or whatever and that’s fine for really simple projects like you might do in university. Debuggers are really useful for tricky code and medium sized projects. On really large projects, you can waste a lot of time using a debugger. This is especially true when there is a lot of data structure that needs to be visualized. Having a good logging system then becomes indispensable. If reading the log doesn’t help you identify the problem, it will at least tell you where to set the breakpoints and when they should be activated.
@@z352kdaf8324 conditional breakpoints?
Hey man, Thank you for your videos! You really upskilled my knowledge to get through this javascript jungle. It's very overwhelming but you are really adding "simplified" in web dev simplified!
Cheers
I've been working as a front-end dev for 10 years now, and still find your uploads helpful, thank you! Maybe one thing I would like to add, that I use a lot, is stopping at a breakpoint, and pointing my cursor on variables, to find out the value of the variable at that state.
Now Kyle, hold on for just one second. 10:35 When you say “step into handles asynchronous code”, you’re not exactly right I think. You see, the step into button actually changes the location and goes into the function call you were currently at; however, if the function is not pure JavaScript and instead is a ‘native code’, there is nothing for the debugger to step into so it skips a number of steps until it can reach the function that is acceptable down the stack. So when we’re not dealing with the setTimeout or any other built-in function but rather with the regular js, the debugger just steps into your code step-by-step like a regular interpreter would do. However, I really liked your point with the setTimeout step into. I wonder if the debugger employs certain heuristics to decide where the developer were actually intending on stepping into :)
Thank you!
Helpful, for me 90% of writing code is write, test, debug, write, test, debug, build up piece by piece. If you do not have strong debug skills you are not going to be able to build up large programs. If you inherit code, debugging is most of what you do, in order to figure out what the code you inherited actually does (or does not do).
That is basically the same for me. I literally check after each block for the most part.
Exactly a proper software developer words
amazing video. thanks so much ♥
Thank you for the support! I'm glad you liked the video.
Debugging in VS Code also works for TypeScript. It may require simple configuring of a compiler, but as I remember, by default it's already configured properly. The goal of configuration is to tell the compiler to create a mapper file which maps a place in the compiled non-readable JS code to a corresponding place in the source TypeScript code. Everything else does the VS Code and browser. The browser's debugger via a special API sends to VS code the current position and other information and VS Code debugger uses the mapping file to translate this position to the actual position in the source code. Also this mapping file is used to deobfuscate the variable names. The technology may seem complicated but it all works under the hood, transparent to the programmer so you don't have to think about it. And identical approach is used for back-end debugging for decades, so the technology is well tested and it works excellent
Basic Debugger tips get a llinter/spell checker and learn to look at the code color differences & what they do in your IDE.
Do not use console.log unless you are debugging. Issue with debugger is your code might not get there at all. Sometimes you just have to update DEV with logs and then make guesses, this is rare but can happen.
Most DEVs just need Fetch in Network, unless you are working on UI work and even then it is where I stay 95% of the time when only doing UI.
VSC debugger will not work in most frameworks so basically pointless.
Like the uncaught, most of the time I know when I make them but still. Also think in larger projects I would never be able to get out of some of them.
Well, I know the major part of tricks shown in the video, but there're few very powerful I've never heard of! Thank you for great video, Kyle!!!
Kyle's always been an amazing teacher, but this one really is an absolute banger. Thanks a lot for the free info!
Great overview of all the things you can do in the debugger tools. You only missed one bit, it is actually possible to modify the scripts directly in Chrome too so you can test out stuff without having to reload everything. I frequently actually fix a bug inside the debugger in Chrome first and do some more tests before fixing it in my code. When projects get bigger reloading everything can be a hassle at times.
I've been writing code for years, but I still found a few nuggets in here. Thanks!
there is always a bigger fish
you are a natural born teacher - many thanks!
I find the most frustrating thing about programming is lack of good documentation (what happened to tech writing?) and trying to find and fix bugs in other people’s code! The only way AI will ever be able to help us code effectively is by having well-written, well-documented code written by humans.
Thanks!
Thank you for the support!
That was great! I thought I knew a lot, but only what I *thought* I needed to know. Thanks for deep diving into all the options and the VS Code debugging too!
This is amazing, I didn't know you could do that with just the devtools, thanks!
`consile.log({ n })` rather than just (n) for added clarity. You can also `console.log({ value, n })` if you have multiple values to view.
"I was blind, and now I can see!" Praise be to Kyle! 😍
Anonymous functions are unnamed, usually lambda, functions like the `timeout()` callback. The outermost anonymous is the internal caller to `main()`. (there's no particular tie between "anonymous" functions and "top-level"
I've been programming for 14 years, and I can confidently say that after all this time, there were still many things I didn't know, but I learned them in this video. Thank you brother
Wow, that tip for debug from VSCode is golden! You are the man! 💪
i use it and will be using it...i know there are many ways to debug...i use other things as well but console log is classic and very nice to debug with... it's been 7 years
How do I use the debugger if my frontend app is being deployed from within a docker container?
build code with debugger command in it and run it locally
Source maps
if ur using Portainer it has a log output in the UI
if ur using Docker Desktop, each container has a log view
if just pure terminal idk
@@wchorski for terminal you just "docker logs" with a name or id of your container as a parameter. docker ps -a to find all running and stopped containers
Docker logs
Another cool thing you can easily do within Javascript is to hijack the console.log function call and output it on a div you can e.g. dynamically show on top of your content. Admittedly the console in chrome is more powerful with how it displays objects so you would then have to implement that yourself. But at times I often like to have some simple debugger overlay in my actual page content, especially when watching some variables, but in those case I naturally make some kind of of custom logger class/object that all the code can use anywhere.
After all these years I just learned the difference between step into and step. Great video
You speak very clearly! I can understand everything!
Just curiosity... What state is your accent from?
Nebraska
great job! I did not know, that it's possible to debug the frontend, something new for backend developers, I think we need tutorial for the whole tabs in dev tools
Been working for soo long with javascript and this debugging skills could have been quite helpful,, great video!
There is a reason the phrase "script kiddie" was a thing. These coding bootcamps are pumping out people who expect to go into an organization and use the latest tools, frameworks and languages ON GREENFIELD projects. Any developer/programmer who has real experience will know GreenField projects are rare and more often than not, you will be working on legacy code (ironically built with the latest and greatest tech of whatever time-period it was created in). Debugging skills are crucial to success.
When we lowered the bar of entry, we let in hoards of people who did not have basic/traditional programming skills, and only knew what they read in a tutorial or watched in video. It's scary times out here. The problems such people create are the very ones I've had the fortune (and misfortune) of working on over the last 10+ years.
+1. Got absolutely the same experience. Having jung people coming from the university. Never touched the Linux console and never ever heard about *vim.*
Is there a way to break and catch exceptions on promises, especially with 3rd party scripts that swallow errors and serialize functions so they are illegible?
To be fair, console.log() or printf or whatever equivalent does the job in 80-90% of the case. It's why I never use the debugger unless I'm in real trouble
The most important skill that I have ever searching for it. Thanks Man! you made my day.
Thanks a ton for this videos, we need more of this kind of debugging in depth videos. It would be really helpful if you can make something like performance optimisation in React or vue app.
It's not so relevant to this video but since console.log has come up I wanted to mention that Console Ninja has been a beneficial extension in VS Code. It shows the console.log results from the browser next to the code calling it within VS Code. I've used that a lot for debugging.
This is pure debugging sugar. Thanks!
this is a frontend-dev specific take. For backend and complex native apps logging is King, the debugger is the one that's for 'simpler' bugs
this is so far the best debug explaining video i've ever seen
You are amazing sir.
After this video I can confidently say -> I can successfully debug any code.
Thanks
Big respect to this chanel, content and creator 🙏
All of this is fine and dandy, now do a video about the unholy mess that is react and how to debug a chain of useeffect and usewhatever, sudden memory leaks. Since i moved on from react i spend more time with friends and family, or in the vs code editing new code than banging my head in another all-night debug session.
I highly encourage to not use debugger in embedded apps, e.g Tauri apps will loop on internal functions and invoke backend code completely ruining DX on the frontend.
Another good one is console.time("foo") and console.timeEnd("foo"). This is shows how much time has passed between the two, super useful for measuring performance.
Thank you Kyle this video has been really helpful to me.
I wonder how Watch works if you have multiple variables in your code with the same name, scoped differently. Does it show them all?
Great overview of debugging features! It would have been great, though, if you at least mentioned that Firefox and Safari have similar DevTools, or even showed them.
As the code base grows the debugger becomes more significant. If you join a project and have never seen the code then your really want to track where things are going. You may have to close 15 files when you are done but the bug you are fixing can happen anywhere in those 15 files and good luck not missing some files if you don't.
Thank you Kyle! I knew much of this but boy did it spackle in the gaps! This is exactly the kind of tutorial I look for. Super appreciative!
If by chance you read this, apologies, but…
Semicolons! Yes, they matter.
dude how did you know i've been looking for the error in my project for a week 😭😭😭 this video is a godsend
Same...
Thanks a lot. This is gold. Please do more tutorials on debugging. React and all good stuff
This motivated me to actually get the debug from front js inside vscode
I didn't immediately managed to do it on first try and abandoned the idea... but it's actually working now and way more convenient
(except i have to bundle with the mapping in the same file, if you know how to bundle via bun with mapping in a separate file while still making it work... please give me the secret)
Running code often, as it is being written is the best way to spot errors. I have seen the expert coders bash out a few hundred lines of code in 10 minutes and then spend 2 days fixing all the errors.
I've never know you could verify your SEO rating straight in chrome. that's awesome
I really liked your video mostly on your use of the debugger. Could you talk more in the future about CSP ? thanks @kyle
I was really in search of this kinda video. Thank you for all the tips!
Can you please make video on full stack website without using any external authentication library please it help alot 🙏🙏🙏
Most of these were familiar to me, but it's always good to fill those gaps in the knowledge. Triggered breakpoints I imagine would be great when you need to break conditionally, but the dependency is not in scope.
I enjoy using debuggers and I naturally always do so when using C#, C or C++ in an IDE where launching the program with the debugger enabled is the default. However when it comes to the browser debugger, I know it exists and I've sometimes used it, but the barrier to entry is often so high that I resort to console log instead..
awesome... what took you so long to think about this idea? immensly helpful
Your explanations were very helpful, thanks
Hey Kyle; please do a tutorial on how to style your hair
😂😂😂😂😂😂😂
I have always been intimidated by using an actual debugger, thank you so much for this video!
Thank you so much for the content! Pease, don't use white background in browser console.
Thank you for all the tips and hints!!
Hell yes! This the real practical stuff 🔥
Hello Kyle, thanks for the video! Could you please share your setup for audio/video recording? I'm impressed by the audio quality in your videos, considering you're in an empty room without acoustic panels.
I started my own TH-cam channel, but I can't even reach a similar sound quality like in your videos... Lots of mic noise, room reverb and keyboard sounds
I also make videos, but have never had any problems with background noise. Even without a special setup (e. g. acoustic panels). Maybe it's the microphone?! I use the RØDE NT-USB [th-cam.com/video/obPxRUr7sGU/w-d-xo.html] which has an amazing good sound quality.
Super helpful content. Thanks much!
I can’t believe how long I’ve been coding without knowing most of the tips in this video
I wonder how you find complex bugs solutions without debugging the code. 🙂
@@igomesigomes with console.log :) and overextended brainpower. I too find this video enlightening, and looking forward to seeing how it will change my life. Probably a lot :) What I find most interesting though is that I did use debuggers and breakpoints in many other languages, and yet it didn't occur to me that JS has it too. s/most interesting/the real WTF to be/ - but then again, I'm officially a sysadmin, not a developer, so... ;)
Thanks, a lot of good info here. Almost didn't watch because the title doesn't give much away.
You are a gift to the world.
A must to know skill. Thank you!
Truly Simplified , Thanks
That is actually an amazing video. I'm myself a dev with around 5 years of exp and I found several new things. Especially the debugging + vs code debugging section is priceless!
Everything is good. I would appreciate it if you could zoom out the camera a little bit.
I'm always marveled by your didactic skills. 11/10
Amazing Thankyou soo much for this amazing content! ❤
Debugging JavaScript is a walk in the park, you don't know what debugging hell is unless you've done graphics programming.
Awesome info. Thanks.
Your guitar precariously balanced on your guitar stand is giving me a brain aneurism.
Great greater greatest skilled developer ever🎉🎉
extremly helpful, need such more videos
Bro this is Gold! Thx a lot :D
just a suggestion if u r not using turbo console then i would recommend to use it, it definitely saves a lot of time.
Very informative tutorial, thank you
Great video Kyle.
This video was sorely needed.
Useful tips, thanks Kyle!
Hey sir, Thank you so much. It was so nice of you giving it for free.
Not the video we asked for, but the video we needed
It's been 6 months. The head bobbing is out of control now.
I noticed it, is everything good with Kyle?
Great video man. Thanks.
Thank you, this is very useful!
what would you say is the best way to debug in a web app on an ios device web browser without needing to buy 3rd party software or by having the correct MacOS for an ios device?
absolutely needed this . ty