Introduction
Before moving further let us look at the previous articles of the series
- Voice of a Developer: JavaScript Data Types - Part One
- Voice of a Developer: JavaScript Objects - Part Two
- Voice of a Developer: JavaScript Engines - Part Three
- Voice of a Developer: JavaScript Common Mistakes - Part Four
- Voice of a Developer: Editors - Part Five
- Voice of a Developer: VSCode - Part Six
- Voice of a Developer: Debugging Capabilities of VSCode - Part Seven
- Voice of a Developer: JavaScript OOP - Part Eight
- Voice of a Developer: JavaScript Useful Reserved Keywords - Part Nine
- Voice of a Developer: JavaScript Functions - Part Ten
- Voice of a Developer: JavaScript Functions Invocations - Part Eleven
- Voice of a Developer: JavaScript Anonymous Functions - Part Twelve
- Voice of a Developer: JavaScript Pure And Impure Function - Part Thirteen
- Voice of a Developer: JavaScript Closures - Part Fourteen
- Voice of a Developer: JavaScript Currying - Part Fifteen
- Voice of a Developer: JavaScript Chaining - Part Sixteen
- Voice of a Developer: JavaScript Array Methods - Part Seventeen
- Voice of a Developer: JavaScript ECMAScript 6 - Part Eighteen
- Voice of a Developer: JavaScript ECMAScript 6 Features v1 - Part Nineteen
- Voice of a Developer: JavaScript ECMAScript 6 Features v2 - Part Twenty
- Voice of a Developer: JavaScript Web Workers - Part Twenty One
- Voice of a Developer: JavaScript JSLint v1 - Part Twenty-Two
- Voice of a Developer: JavaScript JSLint v2 - Part Twenty Three
- Voice of a Developer: XMLHttpRequest API - Part Twenty Four
- Voice of a Developer: Web Storage API - Part Twenty-Five
- Voice of a Developer: Application Cache API - Part Twenty-Six
- Voice of a Developer: Javascript WebSocket - Part Twenty-Seven
- Voice of a Developer: Parse JSON - Part Twenty-Eight
- Voice of a Developer: Save Coding Time With Lodash.js - Part Twenty Nine
- Voice of a Developer: ChakraCore JavaScript Engine by Microsoft - Part Thirty
- Voice of a Developer: JavaScript Web App Performance Best Practices - Part 31
- Voice of a Developer: ECMAScript Promises - Part 32
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.
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:
Users submit a form and click a button.
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.
Any of the web APIs pushes the callback on to the event queue when it is done. It is also called a task queue.
The event loop looks at the call stack and task queue and decides which callback to push onto the 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.
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,
Browser Runtime

User Interface
Web APIs
Event Queue
Event loop
Call Stack
Q: How shall we solve this problem of blocking?
- 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?
Step 1

Interpreter
Calculate Size of Stack
Goto console of your browser and run below script
- var size = 0;
- function inc()
- {
- size++;
- inc();
- }
- inc();



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.



Execution JavaScript Runtime
- var firstFunc = function()
- {
- console.log("I'm first!");
- };
- var secondFunc = function()
- {
- setTimeout(firstFunc, 3000);
- console.log("I'm second!");
- };
- 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.

- 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.

- 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.
OutputI'm second!
I'm first!
Debasis SahaPosted Jun 7, 2016, 12:59 AM
Nice share..
Kuppurasu NagarajPosted Jun 6, 2016, 11:57 AM
Nice Sharing..
Sonu ChaudharyPosted Jun 6, 2016, 9:39 AM
good one...
Guest UserPosted May 30, 2016, 9:57 PM
Thanks guys for reading & feedback
Vignesh ManiPosted May 30, 2016, 9:36 AM
Good one
RajaPosted May 30, 2016, 3:20 AM
Great Work...
Debasis SahaPosted May 30, 2016, 1:33 AM
Nice share..
Bhuvanesh MohankumarPosted May 29, 2016, 12:45 PM
Good one
Pradeep SahooPosted May 29, 2016, 5:53 AM
Nice series .... Thanks for sharing
Guest UserPosted May 29, 2016, 2:09 AM
Thanks Anupam Singh! On 19th June there is a workshop in Noida C-SharpCorner office. Please register
Anupam SinghPosted May 29, 2016, 1:37 AM
An awesome series on JavaScript. @sumit when are you going to deliver your session on JavaScript :).
Munesh SharmaPosted May 28, 2016, 3:11 PM
nice
Gowtham RajamanickamPosted May 28, 2016, 1:36 PM
good one...