Firefox browser console: Hint when there is an error thrown by JS

I rarely use Firefox when working on front-end, but since I read one of an article from MDN, I learned that Firefox browser console will give me a hint when there is an error thrown by JavaScript. See the screenshot below, on the left is Firefox version 58 and on the right side is Chrome version 64.


I think this nice, and in the future, I will suggesting my mentee to consider to use Firefox in their learning session instead of Chrome, because if there is an error thrown by JavaScript they might be able to figure it out faster.


Shorter path to open up DevTools Console

Working as a front-end developer I frequently using DevTools Console to do almost anything inside the console (e.g. interacting with the HTML document using DOM API).

I usually open up DevTools Console with the following steps:

  1. Pressing this combination of keyboard shortcuts: Ctrl + Shift + I.
  2. Click the Console panel.



Slightly longer path to open up DevTools Console


but, there is a shorter path, just press Ctrl + Shift + J.

Thanks for the universe for pushing me to get better at something, and this article Tools for Web Developers: Using the Console.

Using jsinspect to detect duplicate codes

As a JavaScript software developer, we occasionally find ourselves writing duplicate codes and keep moving forward without even considering to clean up the code. We may also find ourselves working in a codebase without knowing how much of duplicate codes have been written to and not sure where to start the cleanup.

There are tools built specifically to help for this purpose, jsinspect. I found this gem when I watched a talk by Elijah Manor: Eliminate JavaScript Code Smells.

Curious enough to give it a try, I installed jsinspect to see how it goes. I ran the tool to inspect several of my JavaScript files and here is the jsinspect returned in my console:

It’s cool, isn’t it? Imagine if we can tap this tool into build process to keep the codebase as clean as possible. But, if you guys also curious enough about jsinspect like myself, try to use it in your daily workflow, see how the tool can help you find the duplicate code easily.

Something I need to keep in mind about window.onload event

I skimmed the window object references and interested to know more details about the window.onload event. Something that I frequently used in many other ways, but I notice something that I didn’t know. The things that I didn’t know about this event is when is the window.onload will be called, it’s:

  • called after all resources loaded (e.g. css, js, images, scripts, etc.)
  • called after the DOM are fully loaded

More reading:

DOM is just an API and not a part of the JavaScript language

These are the quote that I and every other developer who just take their first step into front-end development should keep in mind when talking about DOM.

Although the DOM is often accessed using JavaScript, it is not a part of the JavaScript language. It can also be accessed by other languages.

Document Object Model (DOM)

If you need a brief conceptual introduction to the DOM head over to MDN.

DOM is just an API while another DOM might refer to someone at The Fast and the Furious movie.

Running Daily Scrum with Google Hangout

Working with the distributed team is interesting and required different way to run a daily scrum. With that conditions we cannot communicate with each others face to face.  Thank god we have Google Hangout which allow us to communicate easily with video chat. Based on my experiences so far Google Hangout are more realiable than Skype.

Another good thing is we can create an event in Google Calendar and add video call to the event which is handy so everytime the calendar notification popped up we can right away open the video call.

Quote: The most important characteristic of promises

The most important characteristic of promises is that it normalizes into predictable form how we handle the success or failure of any function call, especially if that call may be asynchronous in nature.

And in that normalization, it leaves our program in a position to control and trust how it will proceed, rather than handing that control (via a callback continuation) off to an untrustable third-party.