Voice of a Developer: Browser Runtime - Part Thirty Three

Sumit Jolly
8y
6.8k
0
2

Article

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:

diagram

I will explain each component in detail now:

User Interface

User submit a form and clicks a button.

Web APIs

This is 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 task queue.

Event loop

The event loop looks at call stack and task queue and decide which callback to push onto 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 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 top most stack frame and return that stack frame is popped out. The call stack is part of JavaScript runtime.

Blocking- means code is slow and therefore preventing execution of statements after it. For example, there is complex FOR loop, looping around 10,000 times. Until FOR loop is over, 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 webpage.

Q: How shall we solve this problem of blocking?

Ans: The solution is asynchronous callbacks. We know that most browsers use 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 abstract syntax tree.

Heap - we know heap is a part of memory system. In most programming languages, generally there are two type of memories 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 various factors like browser type, version	Heap is dependent on size of Virtual memory
Fast to access	Slow to access than 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]

Memory

Interpreter

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 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 size of call stack available?

Calculate Size of Stack

Step 1 - Goto console of your browser and run below script

var size = 0;
function inc()
{
size++;
inc();
}
inc();

Output from Chrome

Output from Firefox

Output from IE

Output

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 object to determine details of the browser too.

Note

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. Example below script executes as following,

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 push two lines of code in 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,
Next piece of code is console.log(“I’m second!”) to pop out from stack and in meantime firstFunc() moved into the event queue.
Event loop picks firstFunc() from task queue and push into Call Stack for execution.
firstFunc() has console.log("I'm first!") which will then pushed into stack & executed.

Output

I'm second!
I'm first!