JavaScript engine guide for beginners_javascript skills

Regarding the title of this article, I don’t think the people who wrote or read this article are idiots. But sometimes a topic makes you feel like an idiot, and JavaScript engines are one of those topics, at least for me.

Sometimes writing code for a web application feels like magic because we just write a series of characters and see the effect in the browser. But understanding the technology behind the magic can help you better improve your programming skills. At least you'll feel less like an idiot when trying to explain what's going on behind the scenes in a JavaScript-powered web or mobile app.

Many years ago, when I was a graduate lecturer, I complained to a professor that I had not yet mastered those particularly difficult French grammar points that I could teach my undergraduate students. I remember what she said at the time: "Sometimes the only way to learn something is to teach it."

Try to explain to engineers how NativeScript works behind the scenes through a JavaScript engine, connecting and calling native APIs at runtime - it's easy to get lost in the weeds when faced with such a complex task. In fact, any JavaScript developer should be curious about the engine that underlies the technology we use every day. Now let’s take a closer look at what JavaScript engines actually do, why different platforms use different engines, how they have evolved over the years, and why as developers we should care.

First, some professional terms

A "JavaScript engine" is often referred to as a virtual machine. A "virtual machine" refers to a software-driven emulator of a given computer system. There are many types of virtual machines, which are classified according to how accurately they simulate or replace a real physical machine.

For example, the "System Virtual Machine" provides a complete emulation platform that can run an operating system. Parallels, which Mac users are familiar with, is a virtual machine that allows you to run Windows systems on your Mac.

On the other hand, the "process virtual machine" does not have all the functions and can run a program or process. Wine is a process virtual machine that allows you to run Windows applications on a Linux machine, but does not provide a complete Windows operating system in Linux.

The JavaScript virtual machine is a process virtual machine specifically designed to interpret and execute JavaScript code.

Note: It is important to distinguish between the layout engine, which lays out the page layout in the browser, and the underlying JavaScript engine, which interprets and executes code. A good explanation can be found here.

So, exactly, what is a JavaScript engine and what does it do?

The basic job of a JavaScript engine is to convert JavaScript code written by developers into efficient, optimized code that can be interpreted by the browser or even embedded into applications. In fact, JavaScriptCore calls itself an “optimized virtual machine.”

To be more precise, each JavaScript engine implements a version of ECMAScript, of which JavaScript is a fork. As ECMAScript continues to evolve, the JavaScript engine continues to improve. The reason there are so many different engines is because each of them is designed to run in a different web browser, headless browser, or runtime environment like Node.js.

You may be familiar with web browsers, but what is a headless browser? It is a web browser without a graphical user interface. They are useful when automating testing of web products. A great example is PhantomJS. So what does Node.js have to do with the JavaScript engine? Node.js is an asynchronous, event-driven framework that lets you use JavaScript on the server side. Since they are tools that power JavaScript, they are also powered by JavaScript engines.

According to the above definition of virtual machine, it is easy to understand that the JavaScript engine is called a process virtual machine, because its only purpose is to read and compile JavaScript code. That doesn't mean it's just a simple engine. For example, JavaScriptCore has six "building blocks" that can analyze, interpret, optimize, and garbage collect JavaScript code.

How does it work?

Of course, this depends on the engine. The two main engines that caught our attention are WebKit's JavaScriptCore and Google's V8 engine, both of which leverage NativeScript. The two engines process code in different ways.

JavaScriptCore performs a series of steps to interpret and optimize scripts:

It performs lexical analysis, which is to break down the source code into a series of symbols or strings with clear meaning.
These symbols are then analyzed using a syntax analyzer to build a syntax tree.
Then four JIT (Just-In-Time) processes begin to participate, analyzing and executing the bytecode generated by the parser.
What? Simply put, the JavaScript engine loads your source code, breaks it into strings (also called tokenization), converts these strings into bytecodes that the compiler can understand, and then executes these bytecodes.

Google's V8 engine is written in C and can also compile and execute JavaScript source code, handle memory allocation and garbage collection. It is designed to be composed of two compilers, which can directly compile source code into machine code:

Full-codegen: a fast compiler that outputs unoptimized code
Crankshaft: A slow compiler that outputs efficient, optimized code
If Crankshaft determines that the code that needs optimization is unoptimized code generated by Full-codegen, it will replace Full-codegen, a process called "crankshafting".

Once the machine code is generated during the compilation process, the engine will expose to the browser all data types, operators, objects, functions specified in the ECMA standard, or anything needed to be used at runtime, as is the case with NativeScript.

What JavaScript engines are there?

There are a dizzying array of JavaScript engines that can be used to interpret, analyze, and execute your client-side code. As each browser version is released, its JavaScript engine may be changed or optimized to keep up with changes in JavaScript code execution technology.

Before you get completely confused by the names of these browser engines, remember that a lot of marketing goes into these engines and the browsers that are based on them. In this very useful analysis of JavaScript compilation, the author sarcastically points out: "What you don't know is that compilers are about 37% marketing, and rebranding a compiler is one of the few things you can do. One of the few things, smart marketing, hence the name: SquirrelFish, Nitro, SFX..."

While keeping in mind the influence of marketing on naming and renaming these engines, it is useful to note a few significant events in the history of JavaScript engines. I made an easy-to-understand chart for you:

Browser, Headless Browser, or Runtime	JavaScript Engine
Mozilla	Spidermonkey
Chrome	V8
Safari	JavaScriptCore
IE and Edge	Chakra
PhantomJS	JavaScriptCore
HTMLUnit	Rhino
TrifleJS	V8
Node.js	V8
Io.js*	V8

*JavaScriptCore was rewritten as SquirrelFish, and the upgraded version is QuirrelFish Extreme, also called Nitro. However, the JavaScript engine that forms the basis of Webkit implementation is JavaScriptCore (like Safari).

**iOS developers should know that Safari on mobile devices uses Nitro, but UIWebView does not include JIT compilation, so the experience will be slower. However, developers can use WKWebView including Nitro in iOS8, and the experience becomes significantly faster. Developers of hybrid mobile apps should be able to breathe a sigh of relief.

*One of the reasons why io.js eventually separated from Node.js was to support the V8 version of the engine. This remains a challenge, as told here .

Why should we pay attention?

The goal of the JavaScript engine's code parsing and execution process is to compile the most optimized code in the shortest time.

Most importantly, the evolution of these engines is closely tied to our ongoing exploration of evolving web and mobile platforms to make them as performant as possible. To track this evolution, you can see how various engines perform in benchmark graphs, as summarized by arewefastyet.com. For example, it would be interesting to compare Chrome's performance with a V8 engine versus a non-Crankshafted engine.

Any web developer should realize that the code we work hard to write, debug and maintain will inevitably perform differently in different browsers. Why does a certain piece of code work slowly on one browser but much faster on another?

Similarly, mobile developers, especially hybrid mobile app developers who use webviews to display page content, or those who use runtime environments like NativeScript, want to know what engine is interpreting and executing their JavaScript code. . Mobile web developers should be aware of the limitations and possibilities of browsers on smaller devices. As a web, mobile, or application developer who wants to continue to grow, keeping an eye on changes in the JavaScript engine will pay off in spades.

Summary:

Basic data types in js undefined null boolean number string
object is a complex data type in js. It is the basic type of all objects
js, like other languages, has 9 basic control statements
Functions in js do not need to specify a return value. In fact, functions that do not specify a return value return undefined
Parameters in js can be passed at will. Pay attention to the arguments[] array. It can help you
Functions in js cannot be overloaded, but you can imitate them.