Voice of a Developer: Browser Runtime - Part Thirty Three


Before moving further let us look at the previous articles of the series
JavaScript is a language of the Web. This series of articles will talk about my observations learned during my decade of software development experience with JavaScript.

Browser Runtime

When we think of Browser, generally we think of DOM elements, Events, Images, JavaScript executing at a client-side. Technically, it is more than that. A browser constitutes of various components, please refer diagram from Philip Robert: 
I will explain each component in detail now:

User Interface

Users submit a form and click a button. 

Web APIs

This is a multi-threaded area of browser that allows many events to trigger at once. JavaScript can access these via WINDOW object on page load. Other examples are DOM document, XMLHttpRequest, setTimeout().
setTimeout is an API provided to us by the browser, it doesn't live in the V8 source. It is not a guaranteed time of execution. It is the minimum time of execution.

Event Queue

Any of the web APIs pushes the callback on to the event queue when it is done. It is also called a task queue.

Event loop

The event loop looks at the call stack and task queue and decides which callback to push onto the call stack.

Call Stack

JavaScript is a single-threaded runtime, it has a single call stack and can execute only one piece of code at a time. If there is a piece of code taking a long time to execute then it blocks UI. This problem is known as blocking. Every function invocation including event callbacks creates a new stack frame. These stack frames are pushed and popped from the top of the call stack (LIFO concept, last in first out). It executes topmost stack frame and returns that the stack frame is popped out. The call stack is part of JavaScript runtime.
Blocking- means code is slow and therefore preventing the execution of statements after it. For example, there is a complex FOR loop, looping around 10,000 times. Until the FOR loop is over, the next statements will not be executed. The browser cannot render anything until there is some process in the call stack. If you remember, I shared in article 31 (http://www.c-sharpcorner.com/article/voice-of-a-developer-javascript-webapp-performance-best-pra/) that Yahoo YSlow proposed script tag shall be placed at the bottom of the webpage.

Q: How shall we solve this problem of blocking?

Ans: The solution is asynchronous callbacks. We know that most browsers use a single thread for UI and JavaScript, which is blocked by synchronous calls. We know we can run asynchronous requests using XMLHttpRequestAPI too to solve this problem.
There are other various components inside Call Stack, these are,
  • Parser- It is the process of analyzing a string of symbols, like part of speech. This takes a program and constructs an abstract syntax tree.
  • Heap- we know heap is a part of the memory system. In most programming languages, generally, there are two types of memory allocation i.e., stack and heap.
Stack Heap
It is used for static memory allocation It is used for dynamic memory allocation
Stack size is limited dependent on various factors like browser type, version Heap is dependent on size of Virtual memory
Fast to access Slow to access than a stack
There is no separation of memory into stack/heap in Javascript.
You can also find out Heap size available using Memory management API. Example- performance.memory in Chrome console [only available with Chrome as of now] 


It translates high-level instructions into a form where it can execute. However, a compiler translates directly to machine language.
We know how to calculate the size of variables (refer article 1 http://www.c-sharpcorner.com/article/voice-of-a-developer-javascript-data-types/), but is there a way to calculate the size of call stack available?

Calculate Size of Stack

Step 1
Goto console of your browser and run below script
  1. var size = 0;    
  3. function inc()     
  4. {    
  5.     size++;    
  6.     inc();    
  7. }    
  8. inc();   
Output from Chrome
Output from Firefox
Output from IE
Step 2
Now you have seen that each browser is complaining about call stack size limit crossed. It’s time to know the unknown limit by printing variable ‘size’ in each browser and we can use navigator objects to determine details of the browser too.
Below output, “Stack size” will depend upon your browser and its version.
console.log ("Stack size: "+ size + " Browser: "+ navigator.appVersion)
Output from Chrome
Output from Firefox
Output from IE

Execution JavaScript Runtime

We talked above about call stack and now we can see how a program is executed internally. The example below script executes as following, 
  1. var firstFunc = function()    
  2. {    
  3.     console.log("I'm first!");    
  4. };    
  5. var secondFunc = function()     
  6. {    
  7.     setTimeout(firstFunc, 3000);    
  8.     console.log("I'm second!");    
  9. };    
  10. secondFunc();  

Sequence of execution 

  • Initially call stack is empty.
  • Then it pushes two lines of code in the call stack.
  • setTimeout moves to Web API area of browser and has a callback function firstFunc() which will be executed after 3 seconds.
    Web API
  • In the meantime secondFunc() statement gets into processing at Call Stack,
  • The next piece of code is console.log(“I’m second!”) to pop out from the stack and in the meantime firstFunc() moved into the event queue. 
    Web API
  • Event loop picks firstFunc() from task queue and pushes into Call Stack for execution. 
  • firstFunc() has console.log("I'm first!") which will then pushed into stack & executed.
    I'm second!
    I'm first!


I hope you enjoyed reading this article. Please don’t forget to submit your feedback.