This Tutorial assumes you are using Google Chrome or Firefox as your browser. These tutorial steps may not work for other browsers.

Javascript is a language that doesn't execute in a regular IDE environment, for it is executed by a browser. Luckily, Firefox and Google Chrome have client-side debugging tools integrated in the browser that allow the user to debug in a break-point style similar to Visual Studio. There are other very useful features included in the Developer tools in each, including a console that allows you to execute accessible JavaScript functions, and the network tab that allows you to track the resources being fetched. More on these later.

The Developer tools are accessible in a variety of ways. For Google Chrome, you can access developer tool either by clicking on this icon at the top of the browser window, and select 'More Tools → Developer Tools':

Similarly, in Firefox, you can find the icon in the same place, but instead, select 'Developer → Debugger':

You can also access the tools directly by right-clicking on the page you want to open in developer tools and select “inspect” (which will open the Elements/Inspector tab of the Developer Tools), or through the hotkey ctrl+shift+I

Google Chrome Developer Tools:

FireFox Developer Tools:

Whether you're in Chrome or Firefox, their consoles work fairly similarly. There are tabs to explore the source code, use the web console, look at the elements of a page, and other useful utilities such as the Network tab. These all serve a useful development purpose, and you'll eventually want to understand them fairly well if you want to become a junior web developer. Here is a quick breakdown of each tab you'll be making the most use of when debugging JavaScript.

This tab allows you to inspect the elements of a page, which can provide information about a page's structure and allow you to gather information about the ways you can reference an element on a page. This is important whenever you are working with JQuery or the structure of the DOM when creating dynamically changing pages.

This tab is perhaps one of the most important, for it provides error information for any executed JavaScript that may have run into errors. Keep in mind that this information can be limited, because it only applies to functions that have been executed during it's run time, and that the error messages are often generalized. This can help catch typos in JavaScript that you may have missed, such as variables being misspelled or other referential errors.
Also know that a lack of errors isn't an absence of issues. Rather, if there is something not working as expected and the console hasn't logged anything, it's more likely that the browser is executing as expected and that there's a logical error in the code.
The console can also be used to manually trigger functions in your JavaScript by calling them. Note - if you are using ES6 classes in your JavaScript, you can only call the methods of an ES6 class object when the object being instantiated during run-time has been given a variable name). Otherwise, the functions lack an access point.

This tab allows you to access the source code of any JavaScript that is being used directly in the browser. This is where the debugging magic happens, where you can set breakpoints in the script and observe the variables, and page, change as the script executes step by step. This process works similarly to the Visual Studio break-point style debugging.

This is the only tab with a more niche use that we'll cover in this tutorial, for you may use it while debugging API requests (such as fetch, in the 233 JavaScript course). This tab allows you to view the network traffic and the different requests made to a server. This is particularly useful when debugging events in your script that look to fetch a source of information from a server. Whenever you send a request to a server, it'll log the results here, where you can look at the contents of what was, or wasn't, returned from the request.
Know that if there is a lack of an expected request log when interacting with your page, it's likely a logical issue with the JavaScript not making the call like it should.

As you might expect, these tabs each are more optimal at catching certain bugs than others because they provide different types of information. We'll cover some useful ways to utilize these tools here.

In the Sources/Debugger tab, there is a list of different scripts that are being used by the browser that you can look into. For more complicated web pages that use libraries such as Bootstrap or JQuery, there may be scripts you don't recognize. Just look for the script that you are personally working on.
Once you select the script you are trying to debug, it will pull up the code. Here, you can set break-points that will pause the thread of execution when the break-point is hit. to do this, simply click on the line number that you want the code to stop at. Keep in mind that pages will open and run all of the functions called by 'onload' event handlers before you can set breakpoints for the first time. If you want to debug these functions, you'll need to set the breakpoints you want on those functions, and then refresh the page. However, any other events that are called from another event, such as a 'click' event, you can hit breakpoints set in those anytime you trigger those events.
From hitting the break-point, you can look at the changes over time in the page, the script's variables, and see if the scripts execute as expected. This information is very useful when debugging important control statements that determine the thread of execution in your code. It can also help you catch data that isn't being instantiated or handled correctly when using general data type names like 'var' or 'let'.

If there's one big thing the elements tab gives you right away is the structure of your document and the details of the elements of the html. A common bug in the development stage of a web application is typos when trying to reference an element, or group of elements. This is useful, because the document you have to work with in your JavaScript is not always the same document that you wrote up prior to run-time. This can also be complicated further by the framework that you may be using, such as ASP.net, which dynamically generates html using cshtml pages known as Razor pages.
In general, checking the browser for what page it received can often be a better practice than relying on knowing the pages prior to run-time.

For anyone who is pulling from a web API using JavaScript, the network tab shows you what data you are attempting to pull and what response you get. By clicking on the name of the request, it pulls up a group of sub-tabs that break down what came back.
Under the tab “Headers”, you can view the header of the response, which contains various types of information. One of the most important of which is the status code. Knowing if you are getting a “404 Not Found” or not lets you know that the data isn't being pulled. You can then ask yourself a few questions:
Do you have a typo in the URL?
Does the data exist at that URL?
Is there a potential issue with the browser being out of date?
If you do get a response, you may not know the exact structure of the data you are getting. Thankfully, if you are pulling ASCII data like JSON, you can view it through the “Response” tab. With a JSON response, it will show the JSON object structure. With this information, you can figure out how to properly navigate the response data to get to the pieces you need.