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.
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.
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).
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.
Hi, I'm Dillion! I am a frontend engineer passionate about learning, teaching and building web applications. Check out my blog and follow me on Twitter!