Telerik blogs

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.

Today I want to continue this series and cover another useful aspect of web development tools – the Scripts tab. This tab not only allows you to inspect all of the JavaScript that has been downloaded to the client, it also allows you to set up breakpoints and debug your JS, which is tremendously helpful! In the earlier days we had to rely on writing alerts left and right, which is kind of like attempting to do heart surgery with a blind fold on (well OK, maybe not just like that, but it was pretty difficult/annoying :P).

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.


For the sake of this blog post I’ll expand a bit on the last blog post’s application and have the following HTML page with a little HTML, CSS and JavaScript goodness all baked in to one tasty cake. Mmmm, HTML cake.

        <script src="Scripts/jquery-1.7.2.min.js"></script>
        <link href="Styles/Styles.css" rel="stylesheet" />
        <title>Quick Dev Tools Sample</title>
                color: #000000;
        <button id="changeButton">Press me</button>
        <p id="sampleParagraph">
            This is a sample paragraph
                $('#changeButton').on("click", function(){
                    var paragraph = $('#sampleParagraph');
                    paragraph.html('New sample paragraph');

The important part here is the JavaScript that I’ve thrown in there inside of the HTML document. All it does is grab my paragraph element and change the HTML so that the text is slightly altered. While it’s a simple script it will do a lot for us in demonstrating what the Scripts tab can do and who isn’t a fan of having simple things teaching us a lot?

The great thing about the scripts tab is that it allows us to see every piece of JavaScript that gets downloaded to our machine whenever we visit a webpage. While accessing some larger pages this can kind of get confusing – especially with minified versions of JS files – it is extremely helpful to utilize while debugging your project locally or even remotely! We can open up each JavaScript file related to our current page and navigate through the code to see what might be going on. Additionally, and this is the most useful feature if you ask me, we have the ability to set up breakpoints! For those of you that were unaware of this I recommend proceeding with caution – there is a high risk for your mind getting blown with the details below.


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.

Since I wrote the JavaScript inside of the HTML page itself (and not in an external file) I have that file selected.

Side-note: If I were to open up any other files, they would be displayed in the same area, just under another tab.

Once the HTML page has been selected we see the entire page’s content and code, including the script tag that I added for this particular example. Notice those page lines on the left hand side there? Extremely helpful when trying to figure out exactly where an issue might be occurring. The best part though is this is where we can easily set up breakpoints in our JavaScript code. So, if I click on the number 21 we get the following:

We now have a little indication that something is going on at line number 21 and we also have an item that has been added under the “Breakpoints” area on the right hand side. This area shows us all of the breakpoints that we have available across our entire page’s content, so if we have multiple JavaScript files with multiple breakpoints they’ll all be added here. Additionally you can uncheck them if you still want to retain that as a possible breakpoint, but skip it for a while, and then just re-check it to have it as an active breakpoint once more.

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.

Chrome Dev Tools at a breakpoint

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.

Chrome Dev Tools past the breakpoint

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[1] 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:

var person = new Object();
person.firstName = "John";
person.lastName = "Smith";
person.isHappy = true;

It would look like this:

Person Object in Chrome Dev Tools

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:

Chrome Dev Tools highlighting object


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:

Firefox and Firebug

We don’t have the same three column structure as we do in the Chrome developer tools, but all of the same information is there. Instead of the file structure layout on the left hand side we have a dropdown containing all of the files we can debug. In the picture above it defaults to index.html, but we can click on it and see additional files, which right now is just jQuery (the only other JavaScript files).

Firebug scripts file dropdown

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.

One interesting note about Firebug is that it highlights the line numbers which represent accurate points for setting breakpoints in green. Didn’t notice? Take a look at the first screenshot again. Lines 19 through 24 are all green, indicating that these are indeed lines of JavaScript which we can set up a breakpoint on. If we go to Line 21 and set a breakpoint by clicking on the number and then go over to the breakpoints tab we see the following:

Firefub insert breakpoint

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).

Firebug at breakpoint

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:

Firebug inspecting variables

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.

IE9 Dev Tools

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:

IE9 dev tools setting a breakpoint

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

IE9 hitting breakpoint

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:

IE9 Dev Tools inspecting variable

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.

That’s Not All!

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.

Carl Bergenhem
About the Author

Carl Bergenhem

Carl Bergenhem is the Product Manager for Kendo UI. Throughout his time at Telerik/Progress he has covered the entire portfolio of products offered, but mainly spent his time in the web development arena covering ASP.NET Ajax, ASP.NET MVC, and JavaScript-based products. He’s passionate about web technologies and tries to stay on top of all JavaScript libraries and frameworks relating to Kendo UI, developing with jQuery, Angular, React, and Vue.js on a regular basis. In his free time Carl enjoys slaying virtual monsters, snowboarding and playing his guitar.


Comments are disabled in preview mode.