Quick Tips for Browser Dev Tools – The Console

Browser developer tools have been around for quite some time now, yet a surprising amount of current, or people looking in to becoming, web developers are unaware of them. This is why I wanted to spend some time on creating a short series looking at, what I think, are the important items to know about these great tools. This is actually the last post out of the series with part one covering the element inspector ant network resources, and part two going over the scripts tab. Today I want to take a look in to the all mighty console which is my most-used feature of any web development tool by far. I constantly sit and tinker in the console when I experiment with potential JavaScript to write before I jump back in to my IDE and actually update my code. It’s the perfect playground because at the end of it all you just have to hit refresh and you’re back at the beginning, just like those awesome Etch-A-Sketches of yore ;)

Hail to the King

The console is king and top dog when it comes to working with and debugging JavaScript. Not only can we write JavaScript directly in the console and see how it affects the page, this is also where all of our errors will be displayed. Whether it is showing a 404 error message or one that has been triggered by our own JavaScript it will pop up in the console. Additionally the console can completely replace all of our alert(variableName) calls that we might be doing today by allowing us to write directly to it. This is ridiculously awesome when dealing with JavaScript objects as it actually shows us the object and allows us to drill down in to the various fields that might be contained within it.

I’ll be working off of the code from the last two blog posts today and I’ve just added a couple of lines to show you some of the power of the console.

Nothing special here. I still have the button that upon getting pressed changes the text of our paragraph element. The only difference from the previous blog post’s code is that I have now added a new variable, paraHTML, which I use to just grab the content of the paragraph before and after the change. Additionally you might see that I use console.log(paraHTML) twice. Well, this will play a major part in the blog post soon so remember it as we jump in to Chrome 21, Firefox 14 and IE9 and see how the console works in each browser.

Chrome

As you can see above, initially the Console area doesn’t look like much. We see a couple of lines related to the ChromeSniffer, which is just a neat little Chrome Extension that allows us to detect what technologies might be behind a website. For example, if you navigate to a page created via WordPress it will actually inform you that this is indeed the case instead of having you attempt to break down a page by looking at the raw code.

Aside from the ChromeSniffer everything is pretty much blank. We can see that at the bottom of the view we have “All”, “Errors”, “Warnings”, and “Logs”, which are simply there to allow us to filter down any potential issues.

Speaking of issues (and boy do we have some ;)) what if I did the following in my JavaScript function that is executed when I press my button?

You might be thinking “where did this errorVar come from?” and that’s exactly the thing I want to point out. I’ve never defined errorVar and I’m treating it like it exists. Let me just press the button and see what happens.

Aha! An error occurs and is displayed! Not only does the error let me know what kind of error (Uncaught ReferenceError) it also gives me some additional detail, which in this case tells me errorVar is not defined. The error also has an expand/collapse icon next to it (which I expanded for the above screenshot) that allows me to look in to the call stack that existed when this error was reported. You can also see that in the bottom right hand corner we have an indicator which shows off how many errors that have been reported (just one right now, luckily ;))

Let’s just take out that line as it has served its purpose. What if I want to just run through the code I originally wrote for this blog post? What will happen then?

See those two lines underneath the last ChromeSniffer message? Well, these are the two console.log() calls that we made in the JavaScript code snippet! Console.log() is a pretty awesome feature which allows you to place just about anything in the output of the console so that you can inspect it. Additionally we see where this piece of information is coming from as index.html:24 and 29 are the file name followed by the line number where this console.log() call was made.

This also works great with objects. Say that I had the following piece of code which creates a new person object and outputs it to the console:

What will this look like in the console?

Well, we first see that we have a line that just says “Object” with the expand/collapse icon next to it. Upon expanding we see that it contains the same fields that we added to our person object! This means that while we’re going through and debugging code we can also just output any of our objects to the console to give us the ability to dive deeper in to them and see if they contain the values we are expecting.

We can also write JavaScript in the console. Check out this screenshot for example:

That’s correct – I can actually write the same JavaScript in the console as I have in the “Press me” button. Not only can I execute lines of JS in this magical place, I can also have variables defined which I can later work with; just like I did above.

This can also be very useful when debugging using breakpoints. Any time you have a breakpoint in a function you can access all of the variables in scope in the console with intellisense! So all you have to do is switch over to the Console tab and then type away with the variables you have. You can even just type the variable name and hit enter to see the same kind of output we saw with the person object or any of the console.log() method calls we had.

Firefox

The Firefox/Firebug console looks like the following:

While there is no ChromeSniffer here, initially everything looks pretty much the same. Let’s go through the same steps to see if there are any differences.

Here’s what happened after I placed that errorVal statement in my code again:

Again, we get the ReferenceError with some additional details, and we also get to see which file and line gave this error. One new thing that we didn’t see in Chrome is the actual code that triggered the whole thing. Nice additional detail if you ask me!

Now, taking out the error and pressing the button we see:

Awesome! We get the two console.log() method calls outputted, as well as knowing which lines these came from.

Adding the person object to my page and outputting that:

We get to see our object again! This is all on one line though, which can be a little cumbersome to read and understand. No need to fear though, you can actually click on the object and get the following:

Perfect! While this is now under the DOM tab we can drill down to see each field of our object and their respective values.

Of course, we can also write JavaScript right in this console as well!

While it looks just slightly different with all of our lines that we input having “>>>” in front of them, we still have the same ability to dynamically execute JavaScript via the console.

IE

Now it’s Internet Explorers turn to show off its chops with the console.

Nothing special so far, let’s check out the error message again.

Well, we’re not sure what type of error it is, but we can still see that errorVar is undefined. Alright, how about we go back to our original code and see the output.

Alright then! IE9 gives us a nice little prefix that lets us know that it comes from a console.log() which is nice. However, we don’t see from what file or what line number this is derived from. Perhaps not a big deal in this situation since it’s all from the same file, but what if we start working with console.log() throughout various JavaScript files?
Let’s check out our person object while we can:

Ah, this is a bit of a problem. This is the same message we’d see if we did alert(variableName). We see that it’s an object, but no details about it what so ever. Luckily there is a way to show the details of the object in IE9 – and it does work for other browsers as well! Instead of console.log() we should use console.dir(). Doing that we get:

Much better! There we have the object we’ve been wanting all along! Cue the celebration :)
Of course we can run our own JavaScript code in the console as well, although quite a lot of information gets written to the console when we do:

As you can see, I couldn’t even fit it all in this screenshot. Nonetheless, I defined paragraph like I did in my other JavaScript code, then used the same variable to change the HTML of the paragraph we have above and it worked!

Go Forth and Debug!

So there you have it folks, the console tab of three of the modern browsers that are out there today. This information, combined with what you read in part one and part two of this blog post series should gear you up to have some good fundamentals of what is available in the various dev tools that modern browsers provide us with. These posts have merely covered a small part of what is available and only scratched the power of what you can do within each one of the developer tool tabs, so you should take the time to explore what else you can do within these awesome tools. So, the next time you have issues with odd elements or JavaScript not being executed properly open up those dev tools and start debugging!

Was this series helpful to you or did I miss something? Feel free to leave a comment below and let me know! :)