In my last blog post of this series I covered the element inspector and network resources tab of modern day web browsers’ developer tools. Although there is a large set of what I like to call “modern” web browsers out there I decided to only take a look at three of them; Chrome, Firefox and Internet Explorer 9.
Keep in mind that below I’m utilizing Chrome 21, Firefox 14, and Internet Explorer 9. Except for Firefox, where I’m utilizing Firebug, all the developer tools are natively built in to the browsers.
In Chrome this tab is actually called “Sources”, but it has the same functionality as the “Scripts” tag from the other dev tools that I’ll be covering. So, what does this look like at initial glance?
We can see that there’s quite a bit going on here. The tab is more or less split up in to three different columns; the file structure on the left, the actual content of the file we have selected (in the middle), as well as a tab filled with debugging information (on the right). You might have noticed that it even shows us the CSS style sheet that was downloaded, as well as my local copy of jQuery.
Side-note: If I were to open up any other files, they would be displayed in the same area, just under another tab.
Why did we pick line number 21? It serves two purposes. First of all I want to make you aware of the fact that you can dynamically add or remove breakpoints as you want after the page has been loaded, there is no need to refresh the page or anything like that. Secondly, the piece of code we’re targeting here gets executed after the button on our page has been clicked, which hasn’t happened yet, and contains a variable: paragraph.
Let’s click on the button and see what happens.
First off you can see that we have the row we want to break at highlighted in blue, with a red arrow indicating where we have stopped over by the line numbers. This gives us a visualization of where we currently are in our code which is always extremely helpful. The more important items come off on the right-hand side though.
Taking a look at the “Breakpoints” area we see that our current breakpoint is highlighted in yellow, which helps us keep track of where exactly we might be in a potential sea of breakpoints. Additionally we get to see some other pretty interesting things. We get a view of the call stack for example, which right now is just letting us know that (from the bottom up) we’re adding a handle for a function, the event has been dispatched (the item was clicked) and that we’re currently executing an anonymous function (which is our current function since we did not name it). Finally we can also get a grasp of the variables that we have in scope.
We have two kinds of variables, local and global. Right now the global ones aren’t too interesting as nothing has been added there, but the local ones sure are! We currently have two variables; this and paragraph. The first variable just represents the element which was passed through our event, in this case our button. The second one is the variable we created ourselves. This is currently undefined because we haven’t actually executed the line we added a breakpoint to. In order to see what this might be let’s go to the next line by either pressing F10 or hitting the icon next to the play button on the top of this column.
Now that we’re on the next line we can see more information about our paragraph variable. In the above screenshot I took the liberty of expanding the item since the initial information mentioning e.fn.e.init doesn’t tell us anything aside from the fact that this is a jQuery variable. Once expanded we see all of the fields available from within this variable. As this is a jQuery object representing an item we’ve selected utilizing some jQuery syntax there are some fields relating to this which we can dig deeper in to. For a non-jQuery object, like this one:
It would look like this:
With the field name listed in alphabetical order.
Side-note: At any point you can highlight an object inside the actual file view (the middle column) and get the same perspective juts in a balloon popup:
What about Firefox and Firebug, what does this all look like? Well, taking a look at the same page in these tools we start off by seeing a somewhat similar view:
We also have the breakpoint information over on the right-hand side, only this is separated in a tab structure between the stack and watch views.
Again, we have the ability to not only see the line which as a breakpoint is indicated by the red dot, we also can see more information regarding all of our breakpoints (currently only one) just like we could in Google Chrome. Let’s press the button again and see what happens (insert mad scientist laugh here).
We hit the breakpoint as expected (highlighted and everything) and then in order to see the same variables as we had in the scope area in Google Chrome we have to click on the “Watch” tab on the right hand side. Just like before we have a view over this, as well as our variable paragraph. Since it is currently undefined we can go along another step with F10 again, then when expanding the paragraph variable we get this:
As you can see there are a lot of similarities, but FireBug shows us all the methods that are available to us as well (although some not really applicable ;))
How does this all look in IE9? Well, overall it looks similar when we start off.
However, when debugging things are a little different. For example, if we set the breakpoint at line 21 again and select “Breakpoints” over on the right hand side we get a similar UI to before:
The difference is when I press the “Press Me” button now nothing happens. The breakpoint never gets hit. We are in luck though because there is a huge “Start debugging” button which, when pressed, lets us debug everything! :)
When we hit that button the developer tools pop up in a separate window, but the exact same layout remains. So if we press our button on our page again, then switch over to the “Locals” tab we can see our paragraph variable like in previous browsers
For those of you from the .NET world you can see that our variables look very similar to what we might find within a Visual Studio debugging session.
When we press F10 to actually get paragraph defined we get:
This is similar to what we saw in FireBug. However, everything is listed in alphabetical order (including jQuery methods) and it takes a while to find the properties that appeared at the top with Chrome or Firefox but everything is still there.
This is where that huge explosion sound happens as your mind officially gets blown. Questions like “how can I have lived this long without knowing this?” and “Just how great is my life as a web developer?” have probably started to pop up as well. The Scripts tab is extremely valuable for any web developer attempting to figure out why obscure errors appear or why certain bugs are cropping up. Being able to step through, over, and into code just like you are already used to on the server-side of things makes debugging the client-side just that much easier. Keep a watch out for the third and final blog post of this mini-series coming out in the next couple of days where I’ll highlight some additional tabs found within the developer tools.
Subscribe to be the first to get our expert-written articles and tutorials for developers!