This article has participated in the good article call order activity, click to see: back end, big front end double track submission, 20,000 yuan prize pool for you to challenge!

Spring breeze good matchmaker, persuade a tree pomegranates. It rained a lot, and the hut was new and broken, and I wore a hat to visit an old man next door. Follow the river bank merlin, a plum sleep full, it is green in a red through, no one at the moment, and pick it a clean hand, a bag of new wine. The fame of the world can not be mounted on the wall, they ask heaven and earth for some extra money to live on. Is calculating the old man’s old urn, how, a fast horse galloped, splash me a muddy, a look, is not the city that usurped the fame of the new enter? And spell spring breeze a sigh, not bad, recently rain much.

The main function of the browser is to send requests to the server to display web content such as HTML documents, PDFS, images, and videos in the browser window. The location of these network resources is specified by the user using a UNIFORM Resource Identifier (URI).

Perhaps in most people’s eyes, the browser looks like this:

A showcase front end, an unknown middle layer that connects the web world; Even the online world can be omitted: a monitor, a mysterious behind-the-scenes black box.

If you’re a front-end developer and you spend more time with your browser than you do with your girlfriend, think about every “not so expected” morning, every night when you’re struggling to get things done, and only your browser and editor are your faithful companions. Even the VS Code editor, which you can’t live without, has a browser connection.

The friends in front of the screen, are you familiar with the people around you, familiar with the friends who accompany you day and night? Maybe, maybe not, but would you like to take some time to get familiar with the inner world of a browser that has so much to do with you for so long?

Today, we’re going to take a look, into the middle ground where we’re most connected to the Internet. The article structure is as follows:

A brief history of the browser

The birth and development of the browser

As you may know, the first browser, the WorldWideWeb, was created in 1990. But the dawn of the modern browser was in the 1980s.

A British scientist named Tim Berners-Lee created a computer program called Inquire in the early 1980s while working for the Swiss-based European Organization for Nuclear Research (CERN, known by its French alphabet). The program aims to make it easier for the many different individuals working at CERN to share information.

The first browser was created in 1990 while Tim Berners-Lee was working at CERN. You may be wondering what exactly a Web browser is. In short, it’s a computer program whose purpose is to display and retrieve data. It can do this using the URL assigned to each data set (web page) stored on the web server. So what this means is that when you type something into the browser, you’re actually typing an address, and the browser will use that address to get the information you want to view. Another key capability of browsers is to interpret and render computer code to you in an easy-to-understand manner.

Here’s a quick look at the browser’s history through 2020:

Some of the early notable and meaningful browsers include Erwise, ViolaWWW, Mosaic, and Netscape Navigator:

You’ve heard the story of the browser since 1990:

  • NCSA Mosaic, or Mosaic for short, was the first widely used, image-displaying web browser in the history of the Internet. It was published in 1993 by the NCSA at the University of Illinois at Urbana-Champaign, and officially ended development and support on January 7, 1997, when the browser became very popular. Mosaic was one of the sparks of the later dotcom boom. Netscape Navigator hired many of the original Mosaic engineers, but didn’t use any of the code from the Mosaic web browser. The descendant of netscape’s code is Firefox.

  • Marc Andreesen and his colleague Jim Clark founded a company in 1994, when Mosaic was the most popular browser, with a plan to build a better browser than Mosaic, capture the market, make them rich, and change history. Their first browser was called Mosaic Netscape 0.9, which was later renamed Netscape. Thanks to JavaScript (which was born in 1995 and took Netscape’s Brendan Eich only ten days to design and implement). And “partial-screen loading” (the ability to start reading details on a page even if it’s not fully loaded, a new concept that greatly enriched the online experience), it quickly became the market leader, accounting for half of the browser market. At its craziest, Netscape’s market share was close to 90 percent.

On August 9, 1995, Netscape IPO, the original price is $14 a share, but later, by default, instead of $28 a share issue, on the day of closing, Netscape’s stock is $75 a share, Netscape became the world’s most valuable Internet companies, the Netscape IPO also contributing to a bubble in the growing network.

  • Netscape’s initial success proved to those who worked in computers and the Internet that times had changed forever, shocking the most powerful players in the industry at the time, a Seattle company called Microsoft, among them. Computers will run through browsers, which can run on any machine, democratizing the software industry and lowering its considerable barriers to entry, leading many to speculate that the era of the operating system is over. Netscape was a challenge for Microsoft, which had created its own browser, Internet Explorer, in the late 1990s. Internet Explorer, then as now, was often seen as a shoddy product. Because Microsoft had built an empire selling Windows, its proprietary operating system, it saw this development, led by companies such as Netscape, as a threat. Microsoft managed to turn the browser industry around quickly by investing heavily in its product and making it as good as Netscape. Windows computers were released with Internet Explorer (Microsoft’s browser) installed, which allowed them to gain a foothold in the market and grow, eventually winning in what became known as the first browser war.

The rapid decline in market share led to the sale of Netscape to AOL. Netscape dissolved in July 2003, the same day the Mozilla Foundation was formed, and Firefox, based on The Mozilla source code, debuted in 2004, ushering in the second browser war. When Netscape finally died out in 2008, the browser empire was officially gone.

By 2003, Microsoft’s Internet Explorer controlled more than 92 percent of the market, a complete reversal from 1995. But while Microsoft has managed to completely take over the browser market in less than a decade, other competition will soon emerge that will once again reshape the history of web browsers.

  • After Microsoft rose in the late 1990s and brought Netscape and others to their knees, the browser’s history seemed to have come to an end. However, as has been the case since its initial release, Internet Explorer is becoming a shoddy product. Google launched its proprietary browser, Chrome, in 2008. By the end of 2012, just four years after its launch, Google Chrome had overtaken Internet Explorer as the most popular browser, thanks to its ease of use, cross-platform capabilities, speed and special features related to tabs and bookmarks.

  • In the early 2000s, probably after Microsoft attached a browser to its operating system, Apple released Safari, a browser designed for the Mac, and it is now the second largest browser on the market.

  • Internet Explorer’s popularity waned in the late 2000s, mainly because it became slow and outdated, and Microsoft now finds itself looking at the browser world from the outside. Not wanting to continue missing out, the company set about fixing the problem, but found that a key problem was that the name “Internet Explorer” had become synonymous with bad browsers. So, in an attempt to re-enter the game, Microsoft had to rename it, and so Edge was born. Edge, the latest version of Microsoft’s browser, has received a lot of praise, but it may be too late for Microsoft.

  • Internet Explorer is a tear in the eye, and Microsoft Edge is the default browser on Windows 11. This is the first and last time in 20 years that Windows has been updated without IE. As early as the Windows 10 update, Microsoft said that it would abandon the update of IE to develop a new browser Microsoft Edge. It’s time to say goodbye to IE on the desktop. Internet Explorer will disappear from Windows 11, and it will rest in 2022.

Browser market Share

The browser market share as of early July 2021 is shown below.

Browser usage Trend change:

Browser market share:

Domestic browser market share:

If you are interested in the above browser market share data, you can check it out at the following link:

  • Domestic browser market share
    • Browser market Share
  • Global browser market share
    • Global browser market share
    • w3counter

Browser Architecture

The heart of the computer

Three-tier computer architecture: machine hardware at the bottom, operating system in the middle, and applications at the top.

When you launch an app on a computer or phone, it’s the CPU and GPU that powers the app. Typically, applications run on cpus and Gpus through mechanisms provided by the operating system.

CPU

The Central Processing Unit, or CPU for short. The CPU can be thought of as the brain of the computer. A SINGLE CPU core can solve many different tasks one by one. It can solve everything from math to art while still knowing how to respond to customer requests. In the past, cpus were mostly single-chip. With modern hardware, you often have more than one core, providing more computing power to your phone and laptop.

Four CPU cores act as office workers, sitting at their desks and doing their work:

GPU

The Graphics Processing Unit (GPU) is another part of a computer. Unlike cpus, Gpus excel at handling simple tasks across cores simultaneously. As the name suggests, it was originally developed to solve graphics. This is why “using a GPU” or “GPU support” in a graphics environment is all about fast rendering and smooth interaction. In recent years, with the popularity of GPU accelerated computing, more and more computing is possible only by GPU.

In the figure below, many GPU cores with specific spanners mean they can only handle a limited number of tasks.

Processes and Threads

A process can be described as the executor of an application. A thread is any part of a program that resides inside a process and executes its process.

A process is created when the application is started. The program may create one or more threads to help it work. The operating system provides processes with a usable “block” of memory in which all application state is stored. When the application is closed, the corresponding process disappears and the operating system frees up memory (in the figure below, bounding boxes are processes and threads swim in the process as abstract fish).

A process can ask the operating system to start another process to perform a different task. At this point, different parts of memory are allocated to the new process. If two processes need to talk, they can do so through inter-process communication (IPC) **. Many applications are designed so that if a worker process becomes unresponsive, that process can be restarted without stopping other processes running in different parts of the application.

The browser’s process/thread architecture model

Browser Process Classification

There is no standard specification for how to build a Web browser, and one browser can be built very differently from another. The process/thread architecture of different browsers generally consists of the following parts:

Chrome multi-process architecture

The architecture of Chrome, currently the “king of the browser world,” is shown below with multiple layers under the rendering process, indicating that Chrome runs multiple rendering processes for each TAB.

In the figure above, at the top is the browser process, which coordinates with the processes that handle the tasks of applying other modules. For the rendering process, multiple rendering processes are created and assigned to each TAB. Chrome assigns a process to each TAB when possible. Now it tries to assign a process to each site, including an iframe.

  • Browser process: Controls the “Chrome” part of the application, including the address bar, bookmarks, back and forward buttons, as well as handling network requests in the Web browser, file access and other privileges that are not visible;
  • Rendering process: controls the presentation of the website within the TAB page;
  • Plug-in process: Controls any plug-in used by the site, such as Flash;
  • GPU process: Processes GPU tasks that are independent of other processes. The GPU is divided into different processes because the GPU processes requests from multiple different applications and draws on the same surface.

This can be understood simply as different processes corresponding to different parts of the browser UI:

Chrome abstracts itself more as an operating system, with a web page or extension acting like a program. You can even see that Chrome does come with a task manager, which lists the current running processes and their current CPU/ memory usage.

In general, you can open Chrome Task Manager in two ways:

  • By right-clicking on the top bar of the browser (TAB bar), select Task Manager to view;
  • Click the “Options” menu (usually a three-dot logo) in the upper right corner of Chrome, select the “More Tools” submenu, and click “Task Manager” to open the Task Manager window.

As mentioned earlier, Chrome uses multiple rendering processes. What advantages does it have?

  • Stability: At its simplest, you can imagine that each TAB has its own rendering process. Suppose you have three tabs open, each with its own separate rendering process. If one of the tabs is unresponsive, you can close the TAB while the other tabs are still running and working. If all tabs are running on the same process, then when one becomes unresponsive, all tabs become unresponsive, which is obviously a bad experience. Below is a GIF comparing the multi-process/single-process architecture for your reference.

  • Security and sandboxing: Another benefit of splitting browser work into multiple processes is security and sandboxing. Because the operating system provides a way to limit process permissions, browsers can sandbox processes for certain features. For example, Chrome can restrict file access to processes that process user input, such as renderers.

Since processes have their own private memory space, they often contain copies of common infrastructure (such as the Chrome V8 engine). This means that more memory is being used, and if they are threads in the same process, they cannot share the copies (threads in the same process do not share the stack, which is necessary to ensure that threads run independently). To save memory, Chrome limits the number of processes that can be started. The limit depends on the memory and CPU capabilities available on the device, but when Chrome runs out of the limit, it starts running the same process on different tabs on the same site.

Chrome is undergoing an architectural transformation to run every module of the browser program as a service, making it easy for processes to be dismantled or aggregated. For example, when Chrome runs on powerful hardware, it splits each service into a different process to improve stability, but when Chrome runs on resource-limited devices, it aggregates services into a single process to save memory. Prior to this architectural change, a similar approach to consolidating processes to reduce memory usage had been used on Android-like platforms.

After Chrome version 67, the desktop version of Chrome has site quarantine enabled by default, and each TAB’s iframe has a separate rendering process. Enabling site isolation is the result of many years of engineering effort. Site isolation is not just about assigning different rendering processes. It fundamentally changes the way iframes communicate. Opening the developer tools on one page and having the iframe run on different processes means that the developer tools have to work behind the scenes to make it look seamless. Even running a simple Ctrl + F to find a word on a page means searching in different renderer processes. You can see why the browser engineers saw the release of site isolation as an important milestone!

Read on: Why Is Chrome multi-process instead of Multi-threaded?

Overall browser architecture

If you’re a front-end engineer, chances are you’ve been asked at an interview: What happens from URL input to page presentation? If you are not familiar with this process, I recommend reading the following two articles, which will not be repeated here:

  • What happens when you go from URL input to page presentation?
  • What happens after the browser enters the URL and press Enter (super detailed version)

One of the main tasks of a browser is to render the presentation page. The rendering process is not exactly the same between different browser cores, but the general process is the same. The following image is an image from the Firefox development document (think of it as the Rebirth of Netscape Ede).

The above image gives a glimpse of the browser’s rendering process, but in terms of the overall architecture of the browser, it is probably just the tip of the iceberg.

In general, the browser architecture looks something like this:

The user interface

This includes the address bar, forward/back buttons, bookmarks menu, etc. Every part of the display except for the page you requested in the browser’s main window belongs to the user interface.

Browser engine

A bridge between the user interface and the rendering engine, passing instructions between the user interface and the rendering engine. The browser engine provides the ability to start loading URL resources and other advanced operations such as reloading, forward and backward actions, error messages, and loading progress.

Rendering engine

Responsible for displaying the content of the request. If the requested content is HTML, it parses the HTML and CSS content and displays the parsed content on the screen.

The browser core is the most important or core part of the browser, called the Rendering Engine. Responsible for parsing web syntax, such as HTML, JavaScript, and rendering to the web page. So the browser kernel is the rendering engine that the browser uses. The rendering engine determines how the browser displays the content and formatting information of the page. Different browser kernels interpret the syntax differently, so the same web page will appear differently in different kernel browsers (browser compatibility). This is why web developers can test the display of web pages in browsers that do not require a kernel.

Extended reading: once the red core browser, the official website of its introduction is: with intelligent authentication engine, rendering engine, control engine, but also a strong “state secret communication protocol”, support unified control, remote control. On August 15, 2018, it was revealed that a large number of files with the same name as Google Chrome appeared after opening the installation directory of Redcore Browser. The original file name, Chrome.exe, was also displayed in the file properties of the installation program. The official website of Redcore browser has removed the download link of the browser. On August 16, Gao Jing, co-founder of Red Core, responded that red Core browser “contains’ Chrome ‘in it”, but it is not plagiarism, but “standing on the shoulders of giants to do innovation”.

Anyway, the browser kernel consists of three main technical branches: typography rendering engine, JavaScript engine, and others.

Typesetting engine:

  • KHTML: KHTML is one of the HTML web page typesetting engines, developed by KDE. KHTML has the advantage of being fast, but has less tolerance for error syntax than the Gecko engine used by Mozilla products. Apple adopted KHTML in 2002 for the development of the Safari browser and released the updated and past versions of the source code. Later published open source WebCore and WebKit engines, which are KHTML derivatives.
  • WebCore: WebCore is a typesetting engine developed by Apple, which is based on another typesetting engine “KHTML”. The main browser that uses WebCore is Safari.

The browser kernel engine is basically divided into four parts:

  • Trident: Internet Explorer uses Trident as its kernel engine;
  • Gecko: Firefox is based on Gecko;
  • WebKit: Born in 1998, and in 2005 by Apple company open source, Safari, Google Chrome, Aoguan 3, Cheetah browser, Baidu browser Opera browser based on WebKit development.
  • Presto: The core of Opera, but due to market choice, it is mainly used on the mobile platform –Opera Mini. (Opera announced in February 2013 that it was moving to WebKit, and in April 2013 that it was abandoning WebKit in favor of GOOGLE’s new Blink engine.)

As a minor addition, we often hear about Chromium, Webkit2, Blink engines as well.

  • Chromium: Based on WebKit, started as Chrome engine in 2008, Chromium browser is Chrome experimental version, experiment new features. It can be simply understood as: Chromium is an experimental version with many new features; Chrome is a stable version.

In detail: A deep understanding of how browsers work

  • Webkit2: comes with OS X Lion in 2010. Implementing process isolation at the WebCore level conflicts with Google’s sandbox design.
  • Blink: Based on Webkit2 branch, it is a branch of WebCore component in WebKit. In 2013, Google began to integrate It into Chromium browser as the Engine of Chrome 28. WebView for Android is also based on Webkit2 and is currently the best supported kernel for new features. It is also used in Opera (15 and later) and Yandex browsers.
  • Mobile is basically all Webkit or Blink kernel (except for Tencent’s X5 on Android), which have high support for new features, so new features can be used on mobile.

If you go back to the browser kernel, it’s not that much. Google’s Blink comes from Apple’s open source Webkit, which comes from KHTML and belongs to the KDE (K desktop environment, KDE is based on QT developed by Trolltech, a Norwegian company. Many of the contributors to KHTML actually came from Trolltech.

Diagram of each kernel:

The following is a brief introduction to WebKit to give you a better understanding of rendering engines. WebKit is made up of several important modules. You can get an overview of WebKit by looking at the following figure:

WebKit is a page rendering and logic processing engine. Front-end engineers take HTML, JavaScript and CSS as input. After processing by WebKit, the output becomes Web pages that we can see and operate. As you can see from the figure above, WebKit consists of four parts framed in the figure. The main ones are WebCore and JSCore (or any other JS engine). In addition, WebKit Embedding API is responsible for the interaction between browser UI and WebKit, while WebKit Ports make WebKit more convenient to be ported to various operating systems and platforms, and provide some interfaces for calling Native Library. For example, at the rendering level, Safari is handled by CoreGraphics on iOS, and Webkit is handled by Skia on Android.

WebKit rendering process:

Firstly, the browser locates a bunch of resource files composed of HTML, CSS and JS through THE URL, and sends the resource files to WebCore through the loader. The HTML Parser then parses the HTML into a DOM tree, and the CSS Parser parses the CSS into a CSSOM tree. Finally, the two trees were combined to generate the final required rendering tree. After the layout, the rendering tree was rendered and output to the screen through the rendering interface with specific WebKit Ports, and the final Web page was presented in front of the user.

network

For network calls, such as HTTP requests. Its interface is platform-independent and provides the underlying implementation for all platforms, responsible for network communication and security.

JavaScript interpreter

It parses and executes JavaScript code, and the results are passed to the rendering engine for presentation.

User interface back-end

Used to draw basic widgets, such as combo boxes and Windows. It exposes a common interface that is platform-independent and uses the operating system’s user interface approach underneath.

Data is stored

This is the persistence layer, where the browser needs to keep various data, such as cookies, on the hard disk. The new HTML specification (HTML5) defines the “Web database,” which is a complete and lightweight in-browser database.

Agree to disagree browser architecture

The following is a list of some of the browser architecture diagrams, perhaps some of the architecture has changed, interested in a simple reference to take a look, except IE, in general, the overall architecture of the browser is similar.

Mosaic architecture:

Firefox architecture:

Chrome architecture:

Safari architecture:

IE architecture:

Browser Fundamentals

Chrome V8

The term V8 was first used as a v-8 engine, a V8 engine used in mid-to-high end vehicles. The 8 cylinders are divided into two groups of 4 each in a V-shaped arrangement. It is the most common engine construction in high-level automotive sports, especially in the United States, where IRL, ChampCar and NASCAR all require V8 engines.

About Chrome V8, I have a note to do a more detailed introduction, the full text of the context is as follows, interested in reading.

V8 grew out of Chrome, but not just the browser kernel. Up to now V8 has been used in many scenarios, such as the popular NodeJS, WEEX, Fast application, early RN. V8 went through a major architecture overhaul, with the main change being “from bytecode to fragrance”.

The early architecture of V8

The mission of the V8 engine was to revolutionize speed and memory collection. The architecture of JavaScriptCore is to generate bytecode and then execute it. Google decided that the JavaScriptCore architecture wasn’t working, that generating bytecode was a waste of time, and that it was faster to generate machine code directly. So V8 was very radical in its early architectural design, using direct compilation into machine code. Later practice showed that Google’s architecture improved speed, but it also caused memory consumption problems.

Earlier V8s had full-CodeGen and Crankshaft compilers. V8 first compiles all the code once using full-CodeGen to generate the corresponding machine code. During execution, the V8 built-in Profiler screened the hotspot functions and recorded the feedback type of the parameters, which were then handed to the Crankshaft for optimization. So full-CodeGen will essentially generate the unoptimized machine code, and Crankshaft will generate the optimized machine code.

As the web became more complex, V8 gradually revealed its architectural flaws:

  • Full-codegen compilation generates machine code directly, resulting in high memory usage.
  • Full-codegen compilation generates machine code directly, which leads to long compilation time and slow startup.
  • Crankshaft could not optimize code blocks for try, catch, and finally keywords.
  • Crankshaft added new syntax support, which required coding for different Cpu architectures.

Existing architecture for V8

To address these shortcomings, V8 borrows from JavaScriptCore’s architecture to generate bytecode. After V8 adopts the bytecode generation method, the overall process is as follows:

V8 today is a very complex project, with over a million lines of C++ code. It is made up of many submodules, of which these four are the most important:

  • Parser: Convert JavaScript source to Abstract Syntax Tree (AST)

    To be exact, before “Parser” converts JavaScript source code into an AST, there is a process called “Scanner”, which follows:

  • Ignition: Interpreter: Converts the AST into a Bytecode, interprets and executes the Bytecode; Collect the information TurboFan needs to optimize compilation, such as the types of function parameters; There are four main modules in the interpreter execution: byte code in memory, register, stack and heap. The original motivation for Ignition is to reduce memory consumption on mobile devices. Before Ignition, V8’s full-CodeGen baseline compiler typically generated nearly a third of Chrome’s overall JavaScript heap. This leaves less space for the actual data of the Web application. Ignition’s bytecode can be generated directly from TurboFan to optimize the machine code, rather than having to be recompiled from the source code as with Crankshaft. Ignition’s bytecode provides a clearer and less error-prone baseline execution model in V8, simplifying de-optimization, a key feature of V8 adaptive optimization. Finally, because generating bytecode is faster than generating full-CodeGen’s baselines compiled code, activating Ignition typically improves script startup times, which in turn improves web page loading.

  • TurboFan: Compiler, which uses the type information gathered in Ignition to convert Bytecode into optimized assembly code; The TurboFan project was originally launched in late 2013 to address Crankshaft’s shortcomings. Crankshaft can only optimize a subset of the JavaScript language. For example, it is not designed to optimize JavaScript code with structured exception handling, that is, blocks of code divided by JavaScript’s try, catch, and finally keywords. It was difficult to add support for new language features in Crankshaft because those features almost always required writing architecture-specific code for the nine supported platforms.

  • Orinoco: Garbage Collector, a garbage collection module responsible for reclaiming memory space that is no longer needed by the program.

The new Ignition+TurboFan architecture reduces memory by more than half as much as the full-CodeGen +Crankshaft architecture and delivers web speed improvements of about 70%.

Before running C, C++, Java and other programs, you need to compile, can not directly execute the source code; For JavaScript, however, you can execute the source code directly (for example, Node test.js) by compiling it at runtime. This is called just-in-time compilation, or JIT. Therefore, V8 is also a JIT compiler.

JavaScriptCore

Before V8, the early mainstream JavaScript engine was the JavaScriptCore engine. JavaScriptCore (JSCore) mainly serves the Webkit browser kernel, which was developed by Apple and is open source. JSCore is the default JS engine embedded in WebKit. The reason for this is that many browser engines based on WebKit branches have developed their own JS engines, the most famous of which is the aforementioned Chrome V8. The mission of these JS engines is to interpret and execute JS scripts. In the rendering process, there is a correlation between JS and DOM tree, because the main function of JS script in browser is to operate and interact with DOM tree. Here’s how it works:

The main module of JavaScriptCore is Lexer, which can decompose the script source code into a series of tokens. Parser processes tokens and generates corresponding syntax trees. LLInt a low-level interpreter that executes binaries generated by Parser; The Baseline JIT is just in time. DFG low latency optimized JIT; FTL High throughput optimization JIT.

As you can see, interpreted languages have a much simpler process than statically compiled languages that generate syntax trees and then have to link, load, and generate executables. The parts in the frame on the right of this flow chart are the components of the JSCore: the Lexer, Parser, LLInt, and JIT sections (the JIT section is in orange because not all JScores have JIT sections).

  • Lexical analysis is easy to understand. It is the process of breaking a piece of source code we write into Token sequences. This process is also called segmentation. At JSCore, lexical analysis is done by the Lexer (some compilers or interpreters call word segmentation Scanner, such as Chrome V8).
  • Like human language, when we speak, we actually follow conventions, communication habits that follow a certain grammar when we say one word after another. The analogy is computer language, the computer has to understand a computer language, also has to understand the syntax of a statement. Parser analyzes the token sequence generated by the Lexer analysis and generates an abstract syntax tree (AST). The ByteCodeGenerator then generates the ByteCodeGenerator for the JSCore based on the AST, completing the syntax parsing step.
  • JS source code after the lexical analysis and syntax analysis of these two steps, into the bytecode, in fact, is through any programming language necessary steps – compilation. However, unlike when we compile and run OC code, JS does not generate object code or executable files stored in memory or hard disk after compilation. The generated instruction bytecode is immediately interpreted line by line by line by the JSCore virtual machine. Running instruction ByteCode (ByteCode) is a very core part of JS engine, the optimization of each JS engine is mainly focused on this.

PS: Strictly speaking, there is no compiled or interpreted type of language itself, because the language is just some abstract definitions and constraints, do not require specific implementation, execution mode. Here, JS is an “interpreted language”, but JS is generally dynamically interpreted by the JS engine, and not a property of the language itself.

If you are interested in more details about JavaScriptCore, I suggest you read the following blog posts:

  • In-depth understanding of JSCore
  • Dig deep into JavaScriptCore
  • JavaScriptCore fully parses
  • JavaScriptCore

Browsers and JavaScript

In this summary, Chrome V8 is used as an example to briefly illustrate the relationship between the browser and JavaScript.

Prior to V8, all JavaScript virtual machines had interpreted execution, which was a major cause of slow JavaScript execution. V8 pioneered the introduction of just-in-time (JIT), a two-wheel drive design (mixing compiler and interpreter techniques), a tradeoff strategy that mixes compilation execution with interpreted execution, which greatly improves JavaScript execution speed. After the advent of V8, the major vendors also introduced JIT mechanism in their JavaScript virtual machines, so the current market JavaScript virtual machines have a similar architecture. In addition, V8 also introduced lazy compilation, inline caching, hidden classes and other mechanisms earlier than other virtual machines, further optimizing the compilation and execution efficiency of JavaScript code.

V8 executes a JavaScript process

V8 executes a JavaScript process as shown in the figure below:

Combining with the Chrome V8 architecture described above and focusing on JavaScript, the browser can get JavaScript source code, Parser, Ignition and TurboFan can compile JS source code into assembly code. The flowchart is as follows:

Simply put, Parser converts JS source Code to AST, Ignition converts AST to Bytecode, and TurboFan converts Bytecode to optimized Machine Code(actually assembly Code).

  • If the function is not called, V8 does not compile it.
  • If the function is called only once, Ignition compiles it and Bytecode interprets it. TurboFan doesn’t do optimizations because it requires Ignition to collect the type information when the function is executed. This requires that the function be executed at least once before TurboFan can optimize the compilation.
  • TurboFan will eventually compile Bytecode into Optimized Machine Code if the function is called multiple times and the type information collected in Ignition proves that it can be Optimized. To improve the performance of code execution.

The red dotted line in the image is inverted, that is, Optimized Machine Code will be restored to Bytecode. This process is called Deoptimization. This is because Ignition may be collecting the wrong information, such as the add function whose arguments were integers and then became strings. The generated Optimized Machine Code already assumes that the parameters of the add function are integers, which is of course incorrect, so you need to deoptimize.

function add(x, y) {
  return x + y;
}

add(1.2);
add('1'.'2');
Copy the code

V8 is essentially a virtual machine, and since computers can only recognize binary instructions, there are usually two ways to get a computer to execute a high-level language:

  • The first is to convert high-level code into binary code and have the computer execute it.
  • Another way is to install an interpreter on the computer and let the interpreter interpret and execute.
  • Interpreted execution and compiled execution have their own advantages and disadvantages. Interpreted execution is fast to start but slow to execute, while compiled execution is slow to start but fast to execute. Explained in order to make full use of advantages of executed and compilation, avoid its shortcomings, V8 adopted a trade-off strategy, adopting the tactics of interpretation in the process of start, but if one piece of code execution frequency exceeds a value, the V8 will optimize the compiler to compile it into execution efficiency more efficient machine code.

To summarize, the main processes V8 goes through to execute a piece of JavaScript code include:

  • Initialize the base environment;
  • Parsing source code to generate AST and scope;
  • Generate bytecode based on AST and scope;
  • Interpret and execute bytecode;
  • Listen for hotspot code;
  • Optimize hot spot code for binary machine code;
  • Deoptimize the generated binary machine code.

Chrome V8’s event mechanism

For asynchronous programming and message queues, the UI thread provides a message queue and adds events to the message queue to be executed. The UI thread then retrieves and executes events from the message queue in a loop. The general UI thread macro architecture is shown below:

Different forms of browsers

WebView

A WebView is an embedded browser that native applications can use to present web content. WebView is just a visual component/control/widget etc. So we can use it as a visual part of our native app. When you’re using a native app, the WebView might just be hidden in the normal native UI elements, and you won’t even notice it.

If you think of the browser as two parts, one part is the UI (address bar, navigation bar buttons, etc.), and the other part is the engine that translates markup and code into our visible and interactive views. The WebView is the browser engine part, you can insert the WebView into your native application like an iframe, and programmatically tell it what web content to load.

JavaScript running in your WebView has the ability to call native system apis. This means you don’t have to be bound by the traditional browser security sandbox that Web code usually has to abide by. The following diagram illustrates the architectural difference with this technique:

By default, any Web code running in a WebView or Web browser is isolated from the rest of the application. This is done for security reasons, primarily to reduce the damage caused to the system by malicious JavaScript code. This level of security makes sense for any Web content, because you can never fully trust loaded Web content. This is not the case with webViews, where developers often have complete control over what is loaded. The likelihood of malicious code getting in and causing chaos on the device is very low.

This is why, with WebView, developers can use a variety of supported ways to override the default security behavior and have Web code and native application code communicate with each other. This communication is often called a bridge. You can see the bridge visualized as part of the Native Bridge and JavaScript Bridge in the image above.

Webviews are great, and while they may seem completely special and unique, remember that they’re just a browser with a location and size set in the application without any fancy UI, and that’s what it’s all about. In most cases, you don’t have to specifically test your Web application in WebView unless you call the native API. In addition, what you see in a WebView is the same as what you see in a browser, especially if you use the same rendering engine:

  • On iOS, the Web rendering engine is always WebKit, the same as Safari and Chrome. Yes, you read that right. Chrome on iOS actually uses WebKit.
  • The rendering engine on Android is usually Blink, the same as Chrome.
  • On Windows, Linux, and macOS, because these are looser desktop platforms, there is a lot of flexibility in choosing the WebView style and rendering engine. The popular rendering engines you will see will be Blink (Chrome) and Trident (Internet Explorer), but there is no one to rely on. It all depends on the application and the WebView engine it is using.

WebView application:

  • One of the most common uses of a WebView is to display linked content;
  • Advertising is still one of the most popular ways to make money for native apps, most of which are delivered through Web content provided by WebViews;
  • Hybrid Apps are popular for several reasons, the biggest one is to increase developer productivity. If you have a responsive Web application that runs in a browser, getting the same application to run with a hybrid application on a variety of devices is fairly simple; When you make an update to a Web application, all the devices that use it can use the change immediately because the content comes from a centralized server, whereas with a pure native application, you have to go through a build, review and review process for each platform when deploying and updating it;
  • Native application extensions, such as Web-based extensions like Wikipedia in Microsoft Office, are implemented through a WebView.

If you are interested in WebView, you can read the following articles:

  • 7.5.1 Basic Usage of WebView
  • Android: A comprehensive and detailed guide to using the Webview

Headless browser

A headless browser is a Web browser that is not configured with a graphical user interface (GUI), usually executed through command line or network communication. It is primarily used by software test engineers, and browsers without guIs perform faster because they don’t have to draw visual content. One of the biggest benefits of headless browsers is their ability to run on servers without GUI support.

Headless browsers are particularly useful for testing web pages because they can render and understand HYPERtext Markup Language (HTML) just like a browser, including style elements such as page layout, color, font selection, and JavaScript and AJAX execution that are not normally available when using other testing methods.

The Headless browser has two main deliverables:

  • A headless library that allows embedded applications to control the browser and interact with web pages.
  • A headless shell, which is a sample application for performing various functions of the headless API.

Puppeteer is a Node library that provides a set of apis for manipulating Chrome, commonly known as a Headless Chrome browser (although you can also configure it to have a UI, the default is none). Since it is a browser, Puppeteer is capable of doing all the things we can do manually on the browser. In addition, Puppeteer means “puppet” in Chinese, so you can know from the name, it is very convenient to manipulate, you can easily manipulate her to achieve:

  1. Generate screenshots or PDFS of web pages
  2. Advanced crawler, can crawl a large number of asynchronously rendered content of web pages
  3. Realize UI automation test, simulate keyboard input, form automatic submission, click, login page, etc
  4. Capture the timeline of your site to track your site and help analyze performance issues
  5. Simulate different devices
  6. .

The main difference between Puppeteer and WebDriver and PhantomJS is that Puppeteer is designed from the user’s perspective. Webdriver and PhantomJS were originally designed for automated testing, so Puppeteer is designed from the machine’s perspective. So they use different design philosophies.

  • Headless Chrome architecture
  • puppeteer
  • An introduction to Puppeteer
  • Let’s talk about Puppeteer in terms of the project

Electron

Electron (formerly Atom Shell) is an open source framework developed at GitHub. It uses Node.js (as the back end) and Chromium’s rendering engine (as the front end) to develop cross-platform desktop GUI applications. It has been used for front-end and back-end development of several open source Web applications, notably GitHub’s Atom and Microsoft’s Visual Studio Code.

The Electron Architecture consists of multiple Render processes and a Main Process. The Main Process starts the Render Process, and the Communication between them is via IPC [Inter Process Communication], as shown in the following figure.

Our common IDE VSCode is developed based on Electron (formerly known as Atom Shell). (Click on the Switch Developer tools under VSCode Help to open the following panel).

The other major components of VS Code are:

  • Shell: Monaco Editor
  • Kernel: Language Server Protocol (a code editor)
  • Debug Adapter Protocol
  • Xterm.js

Read on: Electron | Build cross – platform desktop apps with JavaScript, HTML, and CSS

Browser code compatibility testing

  • caniuse
  • browseemall
  • html5test

read

  • A Brief history of browsers
  • Some concepts associated with Web browsers
  • How browsers work: Behind the scenes of the new Web browser
  • From browser multi-process to JS single thread, JS running mechanism is the most comprehensive comb
  • 🤔 Mobile JS engine which strong? For Silicon Valley, visit……
  • Interview Tips you didn’t know from a V8 perspective
  • High-performance JavaScript engine V8 – garbage collection
  • Inside Look at Modern Web Browser

The resources

  • Inside look at modern web browser
  • How browsers work: Chrome V8 makes you more JavaScript savvy
  • In-depth understanding of JSCore
  • The Story of the Web: A History Of Internet Browsers
  • PPT – Browser Architecture
  • Overview of JavaScript engine V8 execution process
  • Understanding WebViews
  • Quantum Up Close: What is a browser engine?

This article was first published on my personal blog.