What is a JS engine

JS scripts are just plain old text, but they are written according to a set of established rules.

function main() {}Copy the code

JS is a high-level language, written in a way that humans can understand. Machines can only recognize machine code, which is a string of zeros and ones. JS written code that the machine cannot understand. This requires translation, and the JS engine acts as a translator: it translates JS language into machine language. There are many types of JS engines. Mozilla (JaegerMonkey), Google (V8), Opera (Chakra), and MicroSoft (Carakan) all have their own JS engines. Mozilla, Google, Opera and MicroSoft all have their own browsers: Firefox(Mozilla), Chrome (Google), Opera (Opera) and Edge (MicroSoft). All four have their own JS engines, and all four have their own browsers. What is the relationship between browser and JS engine?

JS runtime environment

Many times I heard a word: JS runtime environment. For a long time I didn’t listen until the interviewer asked me. The JS runtime environment is where JS scripts run. Where can JS scripts run? Browsers! There seems to be something called NodeJS. What is NodeJS? NodeJS is not a programming language, but a JS runtime environment. Many years ago, JS scripts could only run in a browser, and then it exploded, and there was something called V8 engine, and with V8, JS scripts could run on NodeJS. There are a variety of browser engines, and every browser has at least one dedicated engine, but NodeJS has only one engine, V8.

Rendering engine

Speaking of THE JS engine, also said to the browser, can not say rendering engine. Because there is a saying.

Browser kernel = JS engine + rendering engineCopy the code

Rendering engine, full name page rendering engine. It is also known by an older, more appropriate name, typography engine. A page is made up of DOM elements. How big are they, where are they placed, and in what order? The typography engine is responsible. Each browser has its own JS engine, rendering engine is also different, each browser has its own typesetting engine. For example, Mozilla has Gecko, IE has Blink, Safari has WebKit, and Chrome has Blink.

How do the JS engine and rendering engine work together

  • The JS engine is responsible for JS interpretation and execution. JS can call web apis, such as DOM, modify page elements, and query page elements.
  • The rendering engine is responsible for composing and rasterizing the rendering tree (DOM tree + style tree) of the elements in the page into visual elements.
  • The execution of the JS engine and the execution of the rendering engine block each other, and while the JS engine is executing, the rendering engine can’t do anything. The rendering engine responds when you click a button on the page or type something into an input box, and when the rendering engine blocks, the user senses that the page is stuck. The reason is that the JS engine is still working and has not released control of the process.

From the JS engine is responsible for and rendering engine is the basis of blocking execution, if the JS engine is executed for a long time, the page will be stuck. Therefore, JS is not suitable for computationally intensive tasks.

JS and single thread

If JS is multithreaded, then there is the problem of competing access that all concurrent models have. Dealing with competition is a tricky business. Also, JS doesn’t have to be multithreaded, because JS is designed to handle web elements, and most scenarios deal with I/O, not large scale computing. Therefore, JS chooses a single thread. The single-threaded runtime environment chosen (browser and NodeJS) has only one call stack.

The call stack

The execution of a function is a process of pushing and pushing. For example, the following code

function c() {}
function b() {
	c();
}
function a() {
	b();
}
a();
Copy the code

The execution process is as follows

  • A stack
  • B into the stack
  • C stack
  • C a stack
  • B the stack
  • Out of a stack

The picture can be imagined. The process can be found here

What is a task queue

  • When the user clicks a button, there is an event handler that does not immediately stack execution.
  • When a user sends an HTTP request, the handler that receives the response does not immediately stack execution.
  • When a setTimeout timer expires, the timer handler does not execute immediately.

These operations, whether they are onClick events, HTTP requests, setTimeout timers, they have nothing to do with the JS engine, they are not in the JS engine, the JS engine has no sense of them happening, they are all WebAPIs.

When there are a large number of HTTP requests on a page, which callback function is executed first and which callback function is executed later? What are the rules? Event callbacks are executed first and last. So we have queues. Event callbacks are tasks, and the data structures that hold these tasks are task queues.

Macro and micro tasks

The task queue mentioned above is just a general term. Tasks can be divided into macro tasks and micro tasks according to their priorities. Macro tasks are placed in the macro task queue, and microtasks are placed in the microtask queue. The microtasks placed in the microtask queue are the microtasks in the process of running a macro task. The order of execution is

  • Select A macro task A from the macro task queue and push it into the stack for execution. In the process of execution, micro task A1, micro task A2 and micro task A3 are encountered, and the micro task is added to the micro task queue for execution.
  • After macro task A is complete, the microtasks A1, A2, and A3 encountered during macro task A are executed. Queue cleared.
  • Select the next macro task from the macro task queue and push it onto the call stack for execution.

As for which Webapis are macro tasks and which are micro tasks, macro tasks and micro tasks

What is an event loop

With the previous conceptual setup, it’s time to talk about the cycle of events. Events are a general term for events and event handlers that WebAPI provides. A loop is a user operation that triggers an event, registers an event handler, and adds the event handler to the task queue when the timer is triggered. The browser is constantly adding tasks from the task queue to the JS call stack for the JS engine to parse and execute, and this process is always running. As long as there are tasks in the task queue, when the call stack is idle, the tasks in the task queue are added to the call stack for execution. The result is as follows