Understanding The Hood

The JavaScript runtime environment( The Browser)

As a software engineer there comes a point in time after learning and buildings a bunch of stuff you feel the need to get a deeper understanding of your tools, how things work under the hood or behind the scenes(whichever flavor). From what I have gathered from senior colleagues, It is not uncommon for JavaScript developers to get quite far in their careers without having a solid understanding of some of the core concepts in JavaScript. Indeed, it’s quite possible to be a successful JavaScript developer who writes solid, commercially viable applications without ever fully grasping how things really work under the hood.

So why do I need to learn and understand about the inner workings of JavaScript when I can be fairly successful in my career without it? Here is why, imagine testing a co-worker’s code and you can’t understand why a page seems to take so long to load, why it becomes unresponsive during a certain operation, or why the application takes up excessive system resources. These kind of performance issues don’t necessarily break an application, and they may not even be noticeable to every user. But they do affect the software’s usability and the user experience, which has reverse effects on things such as SEO, page ranking, time complexity, memory usage on the client’s machine and so on. Understanding what’s going on under the hood can help you write better code and debug code faster, making your life as a developer easier, providing smooth user experience on your application.

Enough said, let’s jump into a cody example of why you should learn and understand ... In this post I would not be discussing or taking us through the nitty-gritty of JS runtime because more experienced software engineers have done that, one of which is Jamie Uttariello. you can read his wonderful post on runtime to get a better understanding.

Let’s say you have a page where your user would click on a button to request a particular information which resides either on your server or an external resource, or you code up a piece of solution that performs complex computation that takes a considerable amount of time to finish. For a better user-experience you would want to keep the user informed about the state of the request and finally when the result is ready rather than just having them stare at a blank screen. To do that you’d do something like this:

Your Initial solution

At first glance, this should do the trick but I am sorry to disappoint you that running this code will only output this:

Your not-so-expected-result

What could have gone wrong? the possible thing that could have gone wrong is that when we update the DOM by doing something such as setting the innerText property of a DOM node, the DOM tree itself is updated, and then the browser repaints the render tree to the browser window ONLY after the call stack is empty. So let’s run through what happened, when we call showStatus() for the first time, the DOM is updated, but the browser doesn't redraw the page yet. Then, doWeirdCalculation() is called, and the execution thread is blocked until the calculation has finished. The showStatus() function is called a second time with the Your result is herestring, and at this point, the browser repaints the render tree with the Your result is here string that we passed to the second call of showStatus().

To get the desired output or experience that we want our users to see, we can simply wrap the doWeirdCalculation() and the second showStatus(). inside a setTimeout()with a delay of 0. What this does is to empty the call stack after the first showStatus() is called which allows for a repaint of the browser. The setTimeout() function is placed inside the browser/web API and after the delay which is just 0, the functions in the setTimeout() is released back to the message queue and they re-enter into the call stack and are executed accordingly.

using setTimeout() to achieve the expected result

With this, you get the desired result of having a text display to the user while the calculation is running and another one after the calculation is done.

This seemingly simple hack comes from you understanding the inner workings of the runtime you are working with be it the browser or Node.

Thank you for reading up to this point, the demo code can be found here. Feel free to play with it and if you have other amazing ways of solving dilemma that comes with the runtime do share and finally, if you found this article beneficial you can clap 😉