Voice of a Developer: Browser Runtime - Part Thirty Three

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.

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]

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

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.