Debugging JavaScript applications

Developers often have a love hate relationship with JavaScript. There are those developers will often try to avoid using JavaScript at all, some developers that use languages such as TypeScript or CoffeeScript to write code and transpile to JavaScript, other developers who regard JavaScript as a necessary evil of their job and begrudgingly use it because they have too and then there are those developers that will try to use JavaScript for almost anything!

My journey with JavaScript I have traveled the entire spectrum although I am still reluctant to use it for everything but I have on occasions had to do so! I have gradually come to enjoy using and improving my JavaScript skills over the years!

Taking time to read JavaScript the Good Parts and several other JavaScript books really helped me to start to appreciate and understand the language.

One of the important aspects of this enjoying JavaScript has been improving my knowledge of the debugging experience!

Debugging is an important aspect of software development. I don't have any exact data to back this up and can only go by my own but it is safe to say that I probably spend at least 60% of my time Debugging or stepping through code.

I find the best way to learn and understand what a particular section of code does is step through it and inspecting the value of variables etc. Often I find this is most important when trying to explore approaches to optimize or improve code.

There are a number of options available to debug JavaScript code, I will aim to cover my three preferred approaches. I accept others will have their own alternatives.

using the console

Using good old console.log() is probably the number one choice of most developers when they get started with JavaScript. Especially those that start to develop their applications using a simple text editor.

It all starts with those innocuous first foray in the JavaScript tutorials:

Developers see the power they can write values of variables out to the console! This is usually in the opening chapter of the book and typically real debugging tips only start to emerge in Chapter 12 or so, but who has ever read a whole text book on any software development subject.

Nobodies got time to go through 11 chapters, especially when the intervening chapters are so dull and boring and want to explain in excruciating detail why strings are immutable and how to rewrite that BubbleSort algorithm,

We wanna solve the worlds problems and if console.log() will help me to see what I need to see then that is all we need!

Developers start fiddling about with the console API and discover we can do all sorts of cool things with it! If we use console.table() we can display our results in a tabular format

Developers start going crazy with this new found power and pretty soon the code base becomes populated with console.log() statements.

The trouble is developers for the most part become quite lazy and forget to remove some console.log() statements and tend to ship code out to production with console.log() statements still in the code!

These statements become easier for other developers to find using my next favourite tool!

Browser based Developer Tools!

The Mozilla and Chrome revolutionised the JavaScript developer experience by introducing Developer tools into the browser. My first experience of this was using and extension called Firebug back in 2006, when this Web Development thing really started to become a big deal!

Firebug became the go to tool to read all your console.log() in the browser! It truly was that awesome!

Gradually browser incorporated tools started becoming more advanced and you could start doing a whole lot more! Even enabling you to step through code intercept requests, check performance and whole lot more!

Pretty soon every major browser implemented some kind of Developer Tool! Probably the most popular amongst the Developer community became Chrome Dev Tools!

I certainly became a big fan of Browser Based Developer Tools, particularly because most Development IDE had such poor integration with JavaScript. Some would work OK but required you to use a particular browser, others required a tremendous amount of integration work that always seemed to kind of work but just never get there!

The problem always seem to emerge that a bug only manifested itself within a particular browser on a particular platform with a define resolution! So there always a need to use a tool like BrowserStack to emulate a specific browser and platform to be able to use developer tools to help debug it.

The developer tools not only enable developers to step through the code but they can also see and manipulate variable values to help detect and fix issues. This really reduces the need for the Console.log statements in code,

Another great benefit of Browser Based Developer tools is that they have enabled JavaScript Framework Developers to create their own Framework specific plugins to help developers making use of the framework.

For instance, I have been doing a lot of of Vue.JS based development work lately and have found the Vue.js Devtools plugin to be really helpful for Vue Specific Functionality.

In my opinion these tools and developments have completely revolutionised the JavaScript development experience, they even make using plain old JavaScript - although more ES6 based JavaScript - a joy to work with!

Which brings me on to my absolute favourite approach to JavaScript development

Integrated Development Environment Debugging

I have been a big fan of IDE's and for the most part prefer to use them. I know there are developers out there who would undoubtedly swear by making use of Vim for almost everything! However, I just don't like the experience, I really did try become a Vimmer but we never really clicked!

When it comes to IDE's I have to say I am a big fan of Jetbrains tools and for JavaScript based development work I will mostly only use WebStorm - The smartest JavaScript IDE , for my JavaScript development.

This is a preference I have developed over the years is to basically use a purpose built IDE for a specific language and task. So for instance for front end and JavaScript tasks I will only use WebStorm, then when it comes to back end work I will use an IDE for that language, so PHP I will use PHPStorm, .net core I will use Rider, for python I will use pyCharm and for Java I will run a mile and head for the hills!

I appreciate you could use either PHPStorm, Pycharm and Rider or any other Text editor like Visual Studio Code or sublime etc to do the JavaScript tasks as they all do support it, but I actually find enforcing a clear separation strategy and not mixing layers forces one mentally to focus on the defined layer.

In my experience, it also ensures you don't get the bleeding of layers problem in your application.

Human beings in general are completely rubbish at multi tasking and it is my belief that is a complete fallacy and recipe for disaster to think that a Full Stack Developer can think about the Full Software Development Stack all at the same time!

I like to divide my work up into defined periods of time where I will be thinking of one layer to the problem at a time. That way you concentrate wholly on one dimension at a time.

I'm an All Products Pack Subscriber which I find provides me with the best value and I literally have no restrictions on product selection and choice.

Using Webstorm it is pretty easy to set up your project to enable debugging and stepping through of the code within your IDE.

Jetbrains have already quite extensively documented the process of Working with Vue.js in WebStorm so I won't repeat or duplicate them here.

Once you have it all configured and running you get a very rich debugging experience!

Which you can obviously use to write Unit Tests and debug Unit Tests etc.

This is definitely my preferred way of debugging JavaScript applications and it makes working with JavaScript just the same as any other software development language!

Summary

Developers spend a lot more time debugging code than they do actually writing new code! So why not make that experience a lot more pleasurable and ensure you have an extensive tool set at your disposal!

f you enjoyed this article and would like to be notified when the follow up this is published or even would like to know when I publish more tutorials why not subscribe to my newsletter.

Alternatively use the comments below to let me know of any omissions or queries or even just to send me some hate mail!