JavaScript is becoming increasingly popular, and teams use it at different levels of their stack — front-end, back-end, hybrid, embedded devices, and more.

This post is intended to take a deeper look at JavaScript and its work: knowing the building blocks of JavaScript and how they interact with each other, you can write code better. In future articles, we will also share some of the practical rules that we use when developing SessionStack, a lightweight JavaScript application that needs to be reliable and high-performance in order to remain competitive.

As you can see from the GitHub statistics, JavaScript is at the top in terms of active repositories and Total Pushes in GitHub. He is not much behind in other categories.

( Check up-to-date language statistics on GitHub ).

As projects rely more and more on JavaScript, developers need to have a good understanding of the internal structure and capabilities of the ecosystem to create good software.

As it turned out, many developers use JavaScript daily, but they don’t know what is happening under the hood.

Overview

Almost everyone has heard of the V8 Engine as a concept, and most people know that JavaScript is single-threaded or uses a callback queue.

In this post, we will take a detailed look at all of these concepts and explain how JavaScript actually works. Knowing these details, you can write the best non-blocking applications that properly use the provided APIs.

If you are new to JavaScript, this post will help you understand why JavaScript is so “weird” compared to other languages.

If you’re an experienced JavaScript developer, here you will find the latest information on how the JavaScript Runtime actually works, which you use every day.

JavaScript engine

A popular example of the JavaScript engine is the Google V8 engine. For example, V8 is used inside Chrome and Node.js. Here is a very simplified view of how it looks:

The mechanism consists of two main components:

• Memory Heap – memory is allocated here;
• Call Stack – this is where the stack frames are located when executing the code.

The runtime

Almost every JavaScript developer uses browser-based APIs (for example, “setTimeout”). However, these APIs are not provided by the engine.

So where are they from?

It turns out that reality is a little more complicated.

So, we have an engine, but actually a lot more – things like web APIs provided by browsers: DOM, AJAX, setTimeout and many others.

And also, we have a popular event loop and callback queue.

Call stack

JavaScript is a single-threaded programming language, which means that it has one call stack. Therefore, he can do one thing at a time.

The call stack is a data structure that basically records where we are in the program. If we go into a function, we put it on top of the stack. If we return from the function, we will pop out of the top of the stack. That is all the stack can do.

Here is an example. Take a look at the following code:

function multiply(x, y) { return x * y; }

When the engine starts executing this code, the call stack will be empty. After that, the steps will be as follows:

Each entry in the call stack is called a Stack Frame.

And this is exactly how the trace stack is built when an exception is thrown – basically, this is the state of the call stack at the moment it happened. Take a look at the following code:

function foo() { throw new Error('SessionStack will help you resolve crashes :)'); }

If this code is executed in Chrome (provided that this code is in a file named foo.js), the following stack trace will be displayed:

“Blowing the stack” – occurs when you reach the maximum size of the call stack. This can happen quite easily, for example, when using recursion without thoroughly testing the code. Take a look at an example:

function foo() { foo(); }

The engine starts executing the code by calling the “foo” function. However, this function is recursive and starts calling itself without any termination conditions. Thus, at each stage of execution, the same function is added to the call stack over and over again. It looks something like this:

At some point, the number of function calls in the call stack exceeds the actual size of the call stack, and the browser decides to take action, giving an error that might look something like this:

Executing code in a single thread can be quite simple, since you do not need to deal with complex scripts that arise in multi-threaded environments, such as deadlocks.

But working with a single thread is also quite limited. Since JavaScript has one call stack, what happens when we run slow tasks?

Concurrency and Event Loop

What happens when you have function calls in the call stack that take a huge amount of time to process? For example, imagine that you want to perform complex image conversion using JavaScript in a browser.

Why is this a problem? The problem is that, despite the fact that the call stack has functions to execute, the browser cannot actually do anything else – it is blocked — the browser cannot render, cannot execute any other code.

It just hung and this is a problem for the UI, and not the only one. Once your browser begins to process many tasks in the call stack, it may stop responding for quite some time. Most browsers throw an error asking you if you want to close the web page.

This is not the best UX right now, is it?

So, how do you execute heavy code without blocking the user interface and without causing the browser to hang? The solution is asynchronous callbacks.

This is described in more detail in the second part: “Inside the V8 + 5 tips on how to write optimized code”

If you find it difficult to reproduce and understand problems in your JavaScript applications, take a look at SessionStack. SessionStack records everything in your web applications: all DOM changes, user interactions, JavaScript exceptions, stack traces, failed network requests, and debugging messages.

The post How JavaScript Works: An Overview of Engine, Runtime, and Stack appeared first on Creador.