OverView

I stumbled across a series of blogs called “How JS Works” (How JavaScript Works — SessionStack Blog) by a guy called “SessionStack”. Founders and employees of products that monitor front-end application data, behavior, anomalies, etc., so you can optimize your application. The blog is very good and has two parts. The first part has 19 chapters and was updated in 2017-2018. This part has been translated into Chinese. Github-troland /how-javascript-works: Knowledge about How javascript Works, Event Loop, Service Worker,etc.) the second part has 15 chapters and was updated this year. There is no domestic translation yet.

Why do a whole series

Because when learning some niche frameworks or plug-ins, you have to read English documents and rely on guessing to cope. Foreign language documents are also written by technical geeks, and the writing is difficult to smooth, coupled with some computer jargon, not so easy to read. Therefore, I plan to translate some articles by myself to improve my document reading ability. For the first 19 chapters, I will translate by myself + refer to the Chinese translation of the leaders, add some notes and delete. The last 15 chapters will be translated independently.

If the reader has no idea of the run-time call stack, he or she may want to do some homework. Recommended index of this chapter: 4 (out of 5)

This is the first chapter of how JavaScript works. This chapter provides an overview of the language engine, runtime, and call stack.

An overview of the

The little Red Book defines JS as: JS = ES+DOM+BOM. This definition specifies the scope of the JS mechanism, including the JS engine, HTML structure, CSS principles, ES, etc.

Let’s start with V8. Almost everyone has heard of the V8 engine concept, and many know that JavaScript is single-threaded or uses callback queues.

This chapter will explain these concepts and how JS works in detail, understanding these details will help you jump to the golden stage and write smoother code.

JavaScript engine

Chrome has a kernel called Chromium. There’s a big module in Chromium called the rendering engine. The rendering engine is responsible for parsing HTML, computing CSS, and executing JS. The part that executes JS is the V8 engine.

There are two common host environments for V8 engines, Node and chromium-based browsers such as Chrome.

The engine consists of two main components:

  • Dynamic memory management – Allocates memory here
  • Call stack – where code execution is your stack structure

The runtime

Almost every JavaScript developer has used some browser API(such as setTimeout) that is not provided by the engine.

So where do they come from? Let’s take a look at the diagram below, which shows part of the browser architecture

As you can see, there’s more to it than just the engine. There are things called Web apis that are provided by browsers, such as DOM,AJAX,setTimeout, and so on. And popular event loops and callback queues.

The call stack

JavaScript is a single-threaded programming language, which means that it is only a Call stack (/ what is the Call stack (the Call stack (the Call stack) – glossary | MDN (mozilla.org))). So it can only do one thing at a time.

A call stack is a stack structure that keeps track of where we are in the program.

When the execution enters a function, the call stack places it at the top of the stack. If the function call ends, the function is removed from the top of the stack. Here’s an example. Check out the following code:

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

function printSquare(x) {
  var s = multiply(x, x);
  console.log(s);
}

printSquare(5);
Copy the code

When the engine starts executing this code, the call stack will be cleared first, resulting in the following steps:

Each entry in the call stack is called a StackFrame.

This is exactly how the stack trace is constructed when the browser throws an exception – the stack trace is the state of the call stack when an exception occurs. The following code:

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

function bar() {
  foo();
}

function start() {
  bar();
}

start();
Copy the code

If executed in Chrome (assuming the code is in a foo.js file), this will result in the following stack trace:

“Stack overflow “- This occurs when the stack runs out of space and functions are being added to it. This usually happens with problematic recursion or an infinite loop. Check out the following code:

function foo() {
  foo();
}

foo();
Copy the code

When the engine starts executing this code, it starts calling foo. But this function calls itself recursively, without any end conditions. So at each step, the call stack adds the same function over and over again. The execution process is as follows:

Finally, the number of function calls in the call stack exceeds the actual size of the call stack, and the browser reports an error like this:

The advantage of single-threading is that you don’t have to deal with deadlocks and concurrency headaches, but you also have to worry about what happens if your current code is running slowly and your browser freezes up.

Concurrency and event loops

Let’s say you want to perform some complex image transformations in JavaScript in your browser.

The converted function is placed on the call stack, at which point the browser can’t really do anything else – it’s blocked. Browsers cannot render while executing JS, i.e. they cannot update the UI. If the conversion function takes too long, the browser page gets stuck.

Once the browser starts performing this task in the call stack, the browser stops interacting for quite some time. Most browsers will throw an error asking you if you want to close the page.

So how do you execute slow code without blocking the UI and making the browser stop responding? Use asynchronous callbacks.

This will be explained in more detail in Chapter 2 of “How JavaScript Works” : “5 Tips for Writing Best Code in a V8 Engine.”

Word list
embedded devices Embedded device
utilize using
ecosystem The ecological system
internals Inner, interior
allocation Allocation (usually memory allocation)
recursion recursive
scenarios scenario
concurrency concurrent