Debugging JavaScript 101

I am “newish” to web development in the modern era. By modern era I mean, that I was writing webpages before “getting on the web” was cool. Before the movie “You Got Mail” came out, when AOL, dialup and Netscape were all still “the thing.” So, I know web development back then, probably up through 2007’ish. And I have done very little serious web development until 2 years ago when I really started delving into OfficeJS. So here are some things I have learned and would like to admit I did not know… I mean, pass along to you:

  1. Node. This heralds back to my previous post on Yo Office. In this post, I call out that NodeJS/BrowserSync is a powerful feature. I can safely say, as I have been working with it more and more, it has changed my life for the better. wlEmoticon-openmouthedsmile.png I have also been using Node and VS Code in an effort to understand this newer way of development. I have had a number of colleagues convince me to keep on keeping on with it – it will grow on me, they swear. Ok… So, what I like is when I hit save in VS Code and go back to the browser and click my add-in button (for a function-file), or open my taskpane again – it is current. I DO NOT have to refresh the browser. Browser-Sync takes care of all this for me.
  2. Chrome. If you are debugging outside of Visual Studio, I have found Chrome to be the best browser with which to debug. Here is why:
    • It’s Incognito mode is the best option for making sure you always have the most recent files and things are not cached. Edge and IE have private modes, but there is the next issue…
    • Edge and IE are tied into Windows and when you try to log into your developer tenant from them, it automatically grabs your credentials from Windows and takes you to your company email. Ugh!
    • Incognito still lets you (with warnings) load certain extensions and you also get form fill, so it makes getting into your tenant mailbox super quick and easy.
    • F12, developer tools. Edge and IE also have, but look at Chrome’s: Enough said there.
  3. console.log(). This is a bit of a no brainer, but I have found that sprinkling my code with this helps me get a good idea of my code flow, especially with Async() hell that you can get into with OfficeJS.
  4. debugger; – this has saved my life. I know, I am a “noob,” but I had no idea how to set a breakpoint in my code and get the browser to stop there, right there… no not there, RIGHT THERE!!! There is a window in my office with easy access to the pavement 4 stories below. One day, the day when I found this (after much frustration with my inability to write coherent JavaScript – a common problem I have), I was about to see if I could bounce. So, what you do is place this one word in your code, and if you have the developer tools open… viola! OMG:


  5. try/catch – In C#, especially with the debugger attached, I sometimes worried about error handling after the fact. Partially because I was not sure all the exception types I would want to catch or just use a general exception handler. But to say unexpected things happen in JavaScript and OfficeJS all the time is an understatement. Especially if you pretend to be a JavaScript developer like me. wlEmoticon-winkingsmile.png
    • I use the console to always output errors.
    • And, I know this is coming, TypeScript makes things so much easier in this area. As a matter of fact, I know one colleague that will be telling me “of course you do not bounce,” and my problems would be so much less had I used TypeScript in the first place. For the record, TypeScript makes a horribly disastrous JavaScript developer like me into an only moderately bad one. wlEmoticon-hotsmile.png But, unfortunately, all my clients are writing code in JavaScript, so here I must suffer.
  6. And shrimp sandwich… that’s… uh… that’s about itwlEmoticon-surprisedsmile.png

As I learn new things, I will come add them to this list. But if you have some great tips on debugging, please comment below.

Leave a Reply