Table of Contents
Developing web applications is sometimes easy when you get the logic you want at first or after just a few tries. Sometimes it is hard and frustrating when you’re not getting the result of what you’re writing after countless tries. It becomes especially tiring when you have to continuously switch between your code editor and the browser to see your new changes:
Thankfully, we have Dev Tools. The Dev Tools say, “You can avoid switching to your editor and do all you want in the browser until you’re satisfied.” They actually say more than that, so in this article, we’ll learn what Dev Tools are and how they make the development process easier for frontend developers like you and me.
They are called Dev Tools (or Development Tools) because they help us do a lot of things like testing and debugging during development...fully inside the browser. Different browsers have different Dev Tools integrated into them. This article is focused on the Dev Tools in Chrome, but you'll find similar features (or even more) in other browsers.
Now, before getting into the details of the Dev Tools, let's quickly understand what browsers do. Our browsers do a lot of things behind the scenes to render our web page - fetch the resources, parse the HTML, run JavaScript, and a whole lot more. Typically, these things stay hidden from our view. That’s a good thing for 99.9999% of everybody out there, but we are web developers! This isn’t always the case for us. There will be many moments where we would like to have more details on what our browser is doing - especially when something in our page isn’t working right. This is where the browser’s built-in Dev Tools come in. They give you an inside look into analyzing all aspects of the browser’s internals when working on our page. This is what makes the Dev Tools awesome!
First, to open the Chrome Dev Tools, from inside Chrome, hold on Ctrl, Shift and I. There are other methods to bring them up as well. When the Dev Tools launch, the result would be similar to this:
There are different panels and tools that we can use, but we don't have time to look into all of the cool stuff featured (and hidden) here. Instead, we'll look at some highlights that will be helpful for frontend development.
From the Console Panel, you can run your JavaScript - calculations, DOM manipulations and so on. You can use this tool to test and run scripts before using them in the source code:
Read more here - Console Logging Basics.
While building web applications, most of the time you will want to test what you are building on a smaller screen. This is termed responsiveness. You know your application works well on a big screen (since that’s what you are probably developing on) but how do smaller screens present your application? Deploy your application and test the URL on phone? That would be very inconvenient. How do you get to know this? Luckily, the Dev Tools have a handy featured called Device Mode.
We can bring up Device Mode by clicking on the icon before Elements, which looks like a tablet and an android:
With Device Mode, the process of testing for responsiveness is really seamless, for you can easily change the screen size to your target size. Below is a random size (512 by 542) I can immediately test my page against and see how things look:
You can change the size to something else or use the already configured sizes for different devices:
So, if you aren’t using Device Mode to test how your web pages look on smaller screens, hopefully these images should convince you to! 😉
The Elements panel gives you access to the HTML that makes up what you currently see in your browser:
More specifically, the Elements panel exposes the Live DOM which consists of the existing elements, the dynamic elements, and their associated styles that the browser uses to build up the web page.
If you want to change something you see in your page using only your code editor, you'll be going through a lot of steps. The steps could involve: applying your change, refreshing your browser manually (or automatically with a live server), applying a different change (if what you did didn't work), refreshing your browser, and on...and on...and on. Jumping from the editor to the browser to see the changes you made becomes strenuous when you're trying to debug or achieve something specific. With direct access to the elements from inside our browser, this saves us time. Let's dive deeper and look at two (time saving!) things that can be done via this panel:
From the Live DOM view, you can select elements, edit them, and the changes you make will be updated in your browser in real-time. You also have the ability to visually select the element from your web page to modify instead of rummaging through lines of HTML. To visually select an element, click on the Select Element icon that is found just to the left of the Device Mode icon:
Let's test our new powers out. If you are on the Google home page in a small screen size, let’s inspect the Images link on the navigation bar. First, select the link by clicking on the Select Element icon from the Dev Tool and then clicking on the Images link in your page:
When you select the Images link, you'll see that element automatically highlights in the document with its styles panel updating on the right. From here, we can see what all makes up this link. We can also make any changes, and these changes will get reflected in our live web page in real-time. For example, double-click the anchor tag and change it to a button. Here's what that looks like:
Then you can preview how a button fits in. This is just one example. You can also delete elements, add elements, and add attributes. All in real-time. Neat, yeah? And after achieving all you want, you can copy the HTML directly and place it in your source code.
With the Dev Tools you can manipulate your CSS in real-time. When you're comfortable with all properties applied (or finally fixed the bug), you can copy the CSS directly from there. All of this happens in the Styles tab under the Elements panel we saw earlier. Continuing our example from earlier, if we have the button selected, we can see all the styles applied on it:
What you can see is a nice visualization of the cascade and which properties get set from where. You can also do more. You can also uncheck applied styles too to see how that may impact what you see in your browser. For example, in the above screenshot we are setting the background color of our button to red, and that change is reflected in the live view of the page on the left.
All resources a web application uses are downloaded over the network (or loaded from cache). Having a way to see all the resources is handy, and that's what the Network panel helps you with. Here's what the network panel displays for Google's homepage:
Each resource is displayed with their status, type, size, time to fetch, and a waterfall diagram which shows when they were loaded.
This panel gives access to all the files used in a web page:
One of the most useful features from this panel is, besides inspecting the contents of each file, is being able to set and inspect breakpoints. You can view any existing breakpoints set manually or via the debugger keyword under the breakpoint-related areas:
Let's say that one of the script files has some code that looks as follows:
console.log('google');
let a = 5;
debugger;
a = 6;
console.log(a);
Notice what our variable a is initialized/set to, the debugger keyword, and then what we change the value of a to afterwards. When you refresh this page (with the Dev Tools open), you'll notice a pause in the execution when the debugger keyword gets hit:
At this point, a still has a value of 5. You can check that out in the console or by looking at the Scope tab just above the Breakpoints tab. Right now everything in our page looks like it is stuck. To resume execution, click on the Play icon next to the 'Paused in debugger' message or the one in the Dev Tools. The execution continues to the end or until it hits the next breakpoint (you can have as many as possible).
By using breakpoints, you can easily debug where the flow of your code breaks. There are other types of breakpoints besides the JavaScript one we spent time with. As seen in the breakpoints screenshot, you can also have breakpoints in fetch requests and DOM events. Learn More about breakpoints.
There are more tools than we've covered (Security, Application, etc). Kindly refer to this MDN documentation which goes into more detail on the potentials of these tools. Dev Tools make debugging, testing, and other related manipulations easier. Some developers prefer manipulating CSS in Dev Tools first before placing them in the source code. I especially love this as it allows you to edit in real-time instead of switching between editor and window. I hope this article explains what Dev Tools are and how they made our lives easier. Go and start doing awesome things with them! 🙌
If you have any questions, feel free to post on the forums.
