In my work assisting teams with JavaScript related problems, I’ve noticed some common issues. If you’re experiencing frustrations with the language too, this article might be of some assistance. Disclaimer: a few of my tips might be obvious to some of you, but hopefully you’ll find at least some useful nuggets of information here! These pointers are especially useful when dealing with enterprise applications and CMS solutions. This is where we have our code, the CMS code, the code from that team nobody wants to mention…and of course, all of them are loaded asynchronously.

The Debugger Statement

This is one of the most underused features when dealing with JavaScript, especially since it’s supported by the majority of browsers. The debugger statement was part of the first edition of ECMA Script so it’s been here for quite some time.

Fundamentally it’s a simple way of adding a breakpoint. If we have code where we loop over an element list and then process the elements…

Screen Shot 2014-11-26 at 17.08.56

…we can add the debugger statement inside the loop so that we have a breakpoint on each iteration:

Screen Shot 2014-11-26 at 17.10.59

The triggering of the breakpoint happens  when the execution of the code is done in the place where we have added it. In cases where there is no debugger handler – for example in most browsers without dev tools – this statement has no effect.

On the dev tools side it will appear as if we have manually placed the breakpoint.

Screen Shot 2014-11-26 at 17.11.37

Of course, this is not for code you want to leave in production, but it is an extremely useful feature during the development period. It has been a life changing feature for me, especially when dealing with vendor based JavaScript and a whole lot of callbacks.

Use the Console Luke!

Most of the developers use the console.log in for debugging purposes, but did you know about console.warn, console.error, and console.info? :

Screen Shot 2014-11-26 at 17.13.23

All of these support C style formatted output like:

console.log("Hello %s", "Brian");

There are also plenty of JS logging frameworks. Proper logging is essential in most programming languages, and JavaScript is no exception to this. Note that not all logging functions are standardized, and you might need to provide fallback for certain browsers. For reference, there is a more extensive article regarding logging in the real world here.

Overview of JS objects using Console.table()

Often we load data from various services and want have a nice view of it on our console –  especially when the data is represented as a list of objects. For example, if we were to load a list of beers from openbeerdatabase.com  (yes this database exists, and it is awesome). Using the HTTP GET beers http://openbeerdatabase.com/documentation/beers-get call we receive a list of objects. After receiving the list we just print it out using console.log :

Screen Shot 2014-11-26 at 17.14.35

The resulting list is difficult to navigate within the console. It’s tricky to get a clear picture of what the data represents. Even if we were to loop through the data, it would still be tedious. Same goes for any large JavaScript object or a list.

If we were to replace the console.log with console.table and make the call again  we’d get this:

Screen Shot 2014-11-26 at 17.15.31
Obviously, the data is shown in a table and it is now sortable using the attributes of the objects. This makes the navigation easier. For example, this is a simple way to visually compare two arrays :

console.table([[1,2,3], [2,3,4]]);

would result into more clear version, especially if we had more sub-arrays :

Screen Shot 2014-11-26 at 17.16.40

Getting the Call Trace

Sometimes we want to know the call trace, aka “Who called my function”. This is often visible when we get failure  – but even on success, we could get the call trace using console.trace :

Screen Shot 2014-11-26 at 17.17.27

Note that console.trace is a non-standard functionality and is not something you should have in production. It is, however, supported by major desktop browsers.

Async Call Trace

Console.trace works just fine for normal function calls. In most developer tools we get the same call trace when we stop on breakpoint. When the call is async(callback) this information is not available because the scope of the closure(callback function) is limited to the data that it holds. Fortunately, in the newer version of Chrome dev tools we have the flag async. So what previously would have been a portion of the call information…

Screen Shot 2014-11-26 at 17.18.12

 

 

 

 

 

 

 

…now becomes a full call trace containing the scope of the caller and the callback :

Screen Shot 2014-11-26 at 17.18.59

Most definitely an essential feature in today’s asynchronous world, in my opinion.  For an extensive explanation on how the asyc call trace works, I recommend this HTML5rocks article.

Who’s Changing My Object?: Objects.observe + console.trace

Sometimes objects get some of their properties changed, but we cannot figure out the cause. In this case, objects.observe comes to the rescue. Let’s say we want to check for all changes to our person object :

Screen Shot 2014-11-26 at 17.19.45

Since we have combined this with console.trace, we can also see the call trace. Awesome right?

Well not so much, since at the time of writing only Chrome supports this and it is a non-standard functionality. Fortunately, it is proposed as part of ECMAscript 7. There is also a similar internal varient for this in Gecko based browser object.watch. Then again, when it comes to debugging, anything we can get is useful. Note that Objects.observe primary function is not debugging, but it is a great side effect.

Who’s Changing My DOM/HTML Element – Aka, Who’s F***ing Up My Code ?

In complex applications, we may end up in a situation where we do not know how a certain HTML element got changed, moved, added, or had some of it’s attributes modified. One way to figure out is to attach the now deprecated mutation event listeners. The API for this is far from ideal, and there are other shortcomings. The newer browser version comes with an object called MutationObserver, which enables us to watch a certain DOM element.

Suppose we wanted to list all mutations on the entire document, where the document can also be any DOM element selected :

 Screen Shot 2014-11-26 at 17.20.25

There is also the non programmable solution we can use in Chrome called DOM breakpoints which still uses mutation events in the background.

Server Side Logging of Client Side Errors

As simple as that, just add onerror handler to the window object and you’re done with the client side. The handler can then make an AJAX request to a REST endpoint which will store the error information on your server. You might find out that a client using IE 8 has a lot of issues  this way, because IE versions predating 9 have no string.trim(). I guess string trim is just not that essential.

Anyway, this what the most basic server side logging of client side errors might look like:

Screen Shot 2014-11-26 at 17.22.16 

Of course, this is the most basic of solution you can have. There are tons of better solutons out there like http://www.stacktracejs.com/ or http://jsnlog.com/ and a more extensive article on Mozilla hacks. There is also a great Hacker News discussion on this topic, but hey, this is certainly a good start!

Use Google Or Other Analytics Tools to Store Data

I know you are way too busy to be writing any backend code. so why not just store the data in Google Analytics?

Screen Shot 2014-11-26 at 17.23.15

You can certainly do this, but note that this is a hack, and there are a lot of better commercial options out there like http://usersnap.com  if you want to be really thorough – but even a hack is better than no information, which is what most people have.

So, You Don’t Think JavaScript is “Real” Code? 

Screen Shot 2014-11-26 at 17.23.54I had been mulling on this idea for a long time, when, a few years back, I realised that I was making a huge mistake in my approach to JavaScript. You should take it just as seriously as Java, C# or Ruby .

Diseases are something you pick up, JavaScript is something you have to learn. 

Just like other programming languages, you need a book, programming exercises and multiple projects. JavaScript also needs coding style guides, testing frameworks and code analysis, and so on. Basically everything that you have for a “real code”. There are complete solutions like Yeoman and JHipster that will help you with full integration.

Unless you do this, you will always end up hating JavaScript – which is a shame considering that JavaScript is all around you! If you follow best practices, most of the time you won’t be debugging any code nor resorting to clever tricks. Unless you’re Chuck, that is.

 

 

More Resources: 

https://github.com/DeveloperToolsWG/console-object/blob/master/api.md

https://developer.chrome.com/devtools#debugging-JavaScript

https://developer.mozilla.org/en-US/docs/Tools/Debugger

http://msdn.microsoft.com/en-us/library/dd565625%28v=vs.85%29.aspx

https://developer.mozilla.org/en-US/docs/Web/JavaScript

https://developers.google.com/web/

HTML5 Cheatsheet

 

 

 

How to Not Hate Java Script: Tips from the Frontline

About The Author
- Mite Mitreski works on custom enterprise application development and consultancy with primary focus on Java and JVM-based solutions. Currently he works as an engineer in Klarna on simplifying the buying experience. In the past he was involved in activities surrounding development groups in Macedonia where he was JUG Leader. Mite has a great passion for free and open source software, open data formats, and the open web. He is involved in the JCP and various other open source initiatives. At the moment he i is a community editor at Voxxed where he helps bring awesome content.

6 Comments

  • g00glen00b
    Reply

    Interesting! I knew most of these. This article is focused on the debugging part of the application are you also going to write an article about the other features of developer tools?
    I already use network monitoring and watching resources like cookies, localStorage or IndexedDB. But I also tried a session once and the Profiles/Timelines feature of Google Chrome DevTools seem to be interesting as well, being able to profile your application, looking at the memory consumption to find out memory leaks and bottlenecks, … .

  • Brian M
    Reply

    One of the few JavaScript articles that I am glad I read!

    How to Not Hate Java Script – or I prefer Don’t hate JavaScript just those who designed it………

    But a probably a bit unfair saying JavaScript was designed!

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>