JavaScript engine guide for white _javascript tips

As for the title of this article, I don't think anyone involved in writing or reading this article is an idiot. But sometimes a topic can make you feel like an idiot, and the JavaScript engine is one of those topics, at least for me.

Sometimes the code that writes a WEB application feels magical, because we just write a series of characters and we can see the effect in the browser. But understanding the techniques behind magic can help you improve your programming skills better. At least when you try to explain what's going on behind the scenes of JavaScript-driven web or mobile apps, you feel less stupid.

Many years ago, I was a graduate lecturer who complained to a professor that he had not mastered some of the particularly difficult French grammar points that could be taught to 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 the engineers how Nativescript is working behind the scenes through the JavaScript engine, calling the native apis--at run time. It's easy to get lost in a weed with such a complicated job. In fact, any JavaScript developer should be curious about the engine that we use every day for this technology base. Now let's take a closer look at what the JavaScript engine does, why different platforms use different engines, how they have evolved over the years, and why we need to focus on this as a developer.

First, some professional terminology

The JavaScript engine is often referred to as a virtual machine. "Virtual machine" refers to a software-driven simulator for a given computer system. There are many types of virtual machines that are categorized according to the extent to which they are accurately simulating or replacing real physical machines.

For example, the system virtual machine provides a complete emulation platform to run the operating system. The parallels that Mac users are familiar with is a virtual machine that allows you to run Windows systems on a Mac.

On the other hand, the process virtual machine does not have the full functionality to 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.

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

Note: It is important to distinguish between the layout engine that is the layout of the page in the browser and the underlying JavaScript engine that interprets and executes the code. Here you can find a good explanation.

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

The basic job of the JavaScript engine is to translate the JavaScript code written by developers into efficient, optimized code that can be interpreted and even embedded into the application through a browser. In fact, JavaScriptCore calls itself "Optimizing virtual machines."

More accurately, each JavaScript engine implements a version of Ecmascript,javascript that is one of its branches. As the ECMAScript continues to evolve, JavaScript engines are constantly improving. There are so many different engines because each of them is designed to run in different Web browsers, headless browsers, or in a run-time environment like Node.js.

You may be familiar with web browsers, so what is the headless browser? It is a Web browser without a graphical user interface. They are useful for automating testing of web products. A great example of this is PHANTOMJS. What does that node.js have to do with the JavaScript engine? Node.js is an asynchronous, event-driven framework that allows you to use JavaScript on the server side. Since they are the tools that drive JavaScript, they are also driven by JavaScript engines.

As described above, the JavaScript engine is known as 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 reclaim JavaScript code.

How does it work?

Of course, it depends on the engine. The two main engines that drew our attention were nativescript, which were WebKit's JavaScriptCore and Google's V8 engine. The two engines work with code in different ways.

JavaScriptCore performs a series of steps to interpret and optimize the script:

It does lexical analysis by breaking the source code into a series of symbols or strings with explicit meanings.
The symbols are then parsed using a parser and constructed into a syntax tree.
Then four JIT (Just-In-Time) processes begin to participate in parsing and executing the bytecode generated by the parser.
What the? In simple terms, the JavaScript engine loads your source code, breaks it down into strings (also called participle), converts the strings into bytecode that the compiler can understand, and then executes the byte codes.

Google's V8 engine is written in C + +, and it can compile and execute JavaScript source code, process memory allocations, and garbage collection. It is designed to consist of two compilers that can compile the source code directly into machine code:

Full-codegen: Fast compiler for output not optimized code
Crankshaft: Slow compiler for efficient, optimized code output
If crankshaft determines that the code that needs to be optimized is Full-codegen generated by the code, it replaces Full-codegen, a process called "crankshafting".

Once the machine code is generated during the compilation, the engine exposes all data types, operators, objects, functions specified in the ECMA standard, or anything that needs to be used at run time to the browser, Nativescript.

What JavaScript engines are there?

There's a whole bunch of dazzling JavaScript engines that you can use to interpret, analyze, and execute your client code. When each browser version is released, its JavaScript engine may change or be optimized to keep up with the state of the JavaScript code execution technology.

Before you get completely confused by the names of these browser engines, remember that many marketing elements are added to these engines and browsers that are based on them. In an analysis that is useful for JavaScript compilation, the author ironically points out: "What you don't know is that about 37% of compilers are made up of marketing, and branding the compiler is one of the few things you can do, smart marketing, Therefore has a series of names: Squirrelfish, Nitro, SFX ...

While keeping in mind the impact of marketing on naming and renaming these engines, it is useful to note several significant events in the history of JavaScript engine development. I made you an easy to understand chart:

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 is rewritten as squirrelfish, and the upgraded version is Quirrelfish Extreme, also known as Nitro. However, the JavaScript engine that forms the basis of Webkit implementation is javascriptcore (such as Safari).

**ios developers should know that Safari uses Nitro for mobile devices, but UIWebView does not include JIT compilation, so the experience will be slower. However, developers can use Wkwebview containing Nitro in IOS8, and the experience is significantly faster. Developers of mixed mobile applications should be relieved.

* One of the reasons for the eventual io.js from Node.js is to support the V8 version of the engine. This is still a challenge, as is described here.

Why should we be concerned?

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

Most importantly, the evolution of these engines is closely related to our ongoing search for the development of web and mobile platforms, making them as high-performance as possible and complementary. To track this evolution, you can see how the various engines behave in the benchmark, as arewefastyet.com sums it up. For example, it's interesting to compare the performance of Chrome when it comes to carrying V8 engines and non-crankshafted engines.

Any web developer should be aware that the code we are trying to write, debug, and maintain will have a different effect in the browser. Why does a piece of code work very slowly on one browser but much faster on the other?

Similarly, mobile developers, especially hybrid mobile application developers who use WebView to display page content, or developers who use a run-time environment like Nativescript, want to know what the engine is doing to interpret their JavaScript code. Mobile Web developers should be aware of the limitations and possibilities of browsers on small devices. As a web, mobile, or application developer who wants to continue to evolve, it's always worth paying attention to the changes in the JavaScript engine.

Summarize:

Base data type in JS undefined null boolean number string
A complex data type object in JS It is the underlying type of all objects
JS has 9 basic control statements as well as other languages
A function in JS does not need to specify a return value, and a function that does not actually specify a return value returns the undefined
The parameters in JS can be randomly passed attention to arguments[] array it can help you
The functions in JS are not overloaded, but you can imitate them.