Front-end development history

The Early Days (1990-)

Page by JSP, PHP and other engineers in the server generated, browser is responsible for display

The advantage of this model is that it is simple and quick, suitable for small projects. However, businesses always get complicated, and this is what happens when:

• JSP and other code maintainability is getting worse.

JSPS are very powerful and can embed Java code. This power makes the responsibilities of the front and back ends unclear, and JSPS become a gray area. Often in order to catch up on projects, for a variety of urgent needs, will be mixed in JSP a large number of business code. At a certain stage of accumulation, there are often significant maintenance costs.Copy the code

So, in order to improve the maintainability of the code. In order to make the division of labor at the front and back end more reasonable and efficient. MVC came up.

Back end dominated MVC era

In order to reduce complexity, there are architecture upgrades of the Web Server layer, such as Structs, Spring MVC, etc. This is the era of back-end MVC.

In the era of back-end MVC, the server returned HTML pages and rendered them back to the user. Most back-end servers do one thing: receive a request from a user and return a response.

Working principle:

• M refers to database files, etc.; V stands for HTML template; C is HTTP request route search engine data analysis file service.
• The user does something in the browser and sends a request to the back end.
• The Controller gets the data from the Model, gets the HTML content, fills the data in the HTML, generates the view, and returns it to the user.

This is talking about the back-end MVC pattern, and there’s an MVC in the front.

This model still has its drawbacks, and the responsibilities at the front and back end are still entangled.

From the birth of the Web to 2005, it has been in the state of backend heavy front-end light. At this point, the front-end page needs to refresh the whole page to obtain background data, resulting in poor user experience.

AJAX brings SPA Era (2005)

But looking back, it’s not that different from the JSP era. The complexity has moved from JSPS on the server side to JavaScript on the browser side, where it becomes very complex. Like Spring MVC, this era began to see the emergence of browser-side layered architectures:

There are several important challenges for SPA applications:

• Conventions of the front and back interfaces.
• Complexity control for front-end development. SPA applications are mostly functionally interactive, with more than 100,000 lines of JavaScript code common. Organizing a lot of JS code, binding to the View layer, etc., are not easy things.

Front-end Oriented MVVM Era (2010)

MVVM is short for model-view-viewModel. Model-view-viewmodel.

Model refers to the data passed by the back end. [View] refers to the page you see. [Viewmodel] Bridge between view and model. View and Model cannot be connected directly.

When the view is updated, that is, when the user manipulates the view, the viewModel can listen for changes to the view through DOM event listeners and notify the Model to make changes.

When the Model is updated, the viewModel can listen for changes to the data and then notify the View to make the update.

Benefits:

• The front and back end responsibilities are clear. The front end works on the browser side and the back end works on the server side. Clear division of labor, can make development parallel, test data simulation is not difficult, front-end can be developed locally. The back end can focus on the processing of business logic
• The complexity of front-end development is manageable. The front end code is heavy, but layered properly so that the front end code does its job.

Disadvantages:

• Code cannot be reused. For example, the back end still needs to do a variety of data verification, verification logic can not reuse the browser side of the code. If reusable, data validation on the back end can be relatively simple.
• All asynchronous, bad for SEO. Often the server is also required to do a synchronous rendering degradation scheme.
• Performance is not optimal, especially in the mobile Internet environment.

Node Full Stack Era (2009)

In this mode of development, the responsibilities of the front and back end are clear. For the front end, there are two UI layers that do their job:

1. Front-end UI Layer handles presentation logic for the browser layer. CSS rendering styles, JavaScript interaction, and HTML generation can also be placed in this layer, depending on the application scenario.

2. Back-end UI Layer handles routing, templates, data acquisition, cookies, etc. Through routing, the front end can finally control URL Design, so that no matter it is a single page application or multi-page application, the front end can control freely. The back end can finally move away from a strong focus on presentation and focus on the business logic layer.

Front-end timeline

• In 1990, Tim was appointedThe hypertext language HTMLHe created the original Web browser on the NeXT computer.
• In November 1994, Netscape corporation was formed and launchedMosaic Netscape 1.0 Beta browser“Was renamed Navigator.
• 1994 W3C was born.
• Netscape introduced JavaScript in 1995.
• In 1996, Microsoft released JScript and built it into IE3. JavaScript is different from JScript. As a result, web pages developed by programmers cannot be compatible with both IE and Navigator browsers. IE began to steal market share from Navigator, leading to the first Browser wars.
• In November 1996, Netscape submitted JavaScript to ECMA for international standardization.
• In June 1997, ECMAScript1.0 was launched.
• 1998.6 ECMAScript 2 specification released.
• The ECMAScript 3 specification was released in December 1999. For the next 10 years, there was little change. ECMAScript 3 becomes the most widely used and implemented language specification foundation for today’s major browsers.
• In May 2005, the W3C released a draft CSS 3.0 specification
• November 2004. Firefox was born. The second browser war begins. (The first browser wars ended with IE winning the browser market and not following W3C standards.)
• AJAX was born in 2005. Partially refresh the page.
• In the second browser war, as the W3C group led by Firefox and Opera intensified their fight against Internet Explorer, the fragmentation of browsers became more and more serious. Different browsers implemented different standards, which was a nightmare for developers.
• In order to solve the browser compatibility problem, Dojo, jQuery, YUI, ExtJS, MooTools and other front-end frameworks have been born. The front-end developer uses these frameworks to send frequent AJAX requests to the background and update the DOM tree when the data is available.
• JQuery is the standard on almost every website.
• 2008, HTML5 draft released.
• Chrome was born with the JavaScript engine V8 (V8 was designed to improve the performance of JavaScript execution within web browsers).
• 2009.12 ECMAScript 5.0 specification released.
• 2009 Node.js was born.
• Since 2010, the Angular, Vue, React MVVM frameworks have been born.
• In June 2015, ECMAScript 6.0 was released.

Engine V8 with JavaScript

Code concepts

• High-level language code. High-level language is mainly relative to assembly language, it is close to the programming of natural language and mathematical formula, basically separated from the hardware system of the machine, with people easier to understand the way to write programs. Programs written are called source programs. Java, C, C ++, C# and so on are all high-level languages.
• Assembly language. Assembly language, as a low-level language, corresponds to computers or other programmable hardware. It is strongly tied to the computer architecture and machine instructions. Different assembly language code corresponds to specific hardware.
• Bytecode. Bytecode is not strictly a programming language, but intermediate code created by high-level programming languages for various needs (portability, transportability, precompilation, etc.).
• Machine code. Machine code is a set of instructions that can be executed directly by the CPU. Each instruction represents a specific task, be it loading, jumping, calculating, etc. The lowest level of language.

Classification of high-level languages

• Compiled languages. A runnable program that compiles all the source code into binary code. You can then run the program directly. Efficient execution, but compiler dependent. Representative languages: C, C++.

• Interpretive language. Translate a sentence from the finished source program, and then execute a sentence until the end. Representative language: JavaScript.

Note here: 1- Interpreted language source code is not directly translated into machine language, but is first translated into intermediate code, which is then interpreted and run by the interpreter. Source code >> Intermediate code >> Machine language. 2- Interpreted language programs are translated into machine language only at runtime, each time they are executed.

Describe compilation and interpretation in one sentence. Compile: The translation of the entire program source code into another code, and then wait to be executed, before running, the product is another code. Interpret: To Interpret a program’s source code line by line and then execute it at runtime.

How can a high-level language be translated into a language that a computer can understand?

• If the high-level language is compiled. The compiler translates the source code directly into binary machine language that the computer can run directly, and the CPU can then execute the instructions directly.
• If the high-level language is interpreted. Taking JavaScript as an example, although it is an interpreted language, it has compilation features, such as the promotion declaration of variables and functions, and then the interpretation of each item.

Editor/compiler/interpreter /IDE differences.

• Editor. An application that writes text or code. Like notepad.
• The compiler. A program that translates one language (usually a high-level language) into another (low-level language). The general goal of this transformation process is to produce an executable program.
• The interpreter. An interpreter is a computer program that executes code written in a programming or scripting language without precompiling the source code into machine code. Think of the interpreter as a black box; we type in source code and it returns results in real time. The black box is built differently for different types of interpreters, and some will integrate the compiler and cache the compiled results to improve execution (Chrome V8 does the same for example). The interpreter usually works “at run time,” and for the source code we enter, line by line is interpreted, executed, and the result returned.
• IDE. Integrated development environment. Integrated editor, compiler, linker and other functions. VSCode, Eclipse, etc.

Why V8 appeared

With the development of Web-related technologies, JavaScript takes on more and more work, so a more powerful JS engine is needed to quickly parse and execute JavaScript scripts. So v8 came along.

A brief introduction to the V8 engine to interpret JavaScript process

• The V8 engine compiles JavaScript to native machine code and uses methods such as inline caching to improve performance. (JavaScript, while an interpreted high-level language, is compilable)
• Other JavaScript engines take the approach of converting to bytecode or interpreting execution.

Working process (compile phase + run phase)

• The source code is converted by the parser into an abstract syntax tree (AST)
• Native executable code is generated directly from the AST using the JIT compiler’s full code generator.

V8’s garbage collection mechanism

• Cause of occurrence. Memory leak refers to the fact that the dynamically allocated heap memory in the program is not released or cannot be released due to some reason, resulting in the waste of system memory, slowing down the running speed of the program and even system crash. Closures cause memory leaks.
• The recycle method (reference counting), as the name suggests, lets all object implementations keep track of how many “programs” refer to them, so that each object knows its “popularity”.

var a = new Object(); / / this time'This object'Var b = a; // The reference count for 'this object' is 2 (a,b) a = null; // reference_count = 1 b = null; Reference_count = 0 reference_count = 0 reference_count = 0Copy the code

Browser kernel, rendering engine, JS engine

• The browser kernel is divided into two parts: rendering engine, JS engine.
• As JS engines become more independent, the browser kernel tends to refer solely to the rendering engine.

A rendering engine is a tool that parses AN HTML document and displays it on a page. (In plain English, is according to the HTML code in the interface to draw a variety of control graphics)

• Common engine
  • Rendering engine
    • Firefox uses the Gecko engine
    • IE uses the Trident engine
    • In 2015, Microsoft launched its own new browser, originally called Sparta, renamed Edge, using the Edge engine
    • Chrome safari Opera uses webKit
    • Chrome and Opera started using Blink engine in 2003
  • JS engine
    • Older versions of IE use the Jscript engine
    • Use Chakra engine after IE9
    • Edge browser still uses Chakra engine
    • Firefox uses the Monkey family of engines
    • The SquirrelFish family of engines for Safari
    • Opera uses the Carakan engine
    • Chrome uses the V8 engine. NodeJs essentially encapsulates the V8 engine

Processes and threads in the browser

Threads and processes

A process is a running instance of a program. When a program is started, the operating system creates a block of memory for the program, which is used to store code, running data and a main thread to perform tasks. We call such a running environment a process.

Thread is attached to process, and using multi-thread parallel processing in process can improve computing efficiency. Multithreading can process tasks in parallel, but threads cannot exist alone. They are started and managed by processes.

Process and thread relationship:

• The failure of any thread in the process will cause the entire process to crash.
• Threads share data in a process.
• When a process is shut down, the operating system reclaims the memory occupied by the process.
• The contents of the processes are isolated from each other. (the sandbox)

Why 4 processes with only 1 page open?

Since opening a page requires at least one Browser main process, one GPU process and one rendering process, plus one plug-in process if the page is running a plug-in.

• Browser main processRole.
  • Responsible for browser interface display and user interaction, such as forward, backward, etc
  • Responsible for page management, creating and destroying other processes
  • Draw the memory Bitmap of the Rendered process to the user interface
  • Network resource management, download
• Plug-in process.
  • Each type of plug-in corresponds to a process that is created only when the plug-in is used.
• GPU process.
  • One at most, used for 3D drawing, etc.
• Rendering process.
  • Page rendering, script execution, event handling, etc

Multi-process advantages of browsers

• Avoid a single page crash affecting the entire browser
• Avoid third-party plug-in crash affecting the entire browser
• It is convenient to use sandbox model to isolate processes such as plug-ins and improve browser stability
• In a single process, if one of the pages crashes, the entire browser will be affected.

The browser’s rendering process

As you can see from the above, when the browser opens a page. At least four processes will be created (browser main, GUP, plugin, renderer)

For common front-end operations, the most important rendering processes: page rendering, JS execution, event looping, etc., are performed within this process.

Browsers are multithreaded, and browsers render processes are multithreaded.

GUI rendering thread

• Responsible for rendering browser interfaces, parsing HTML,CSS, building DOM trees and RenderObject trees, layout and drawing, etc.
• This thread executes when the interface needs to be redrawn or when some operation causes backflow.
• Note that the GUI rendering thread and the JS engine thread are mutually exclusive, the GUI thread is suspended (frozen) while the JS engine is executing, and GUI updates are stored in a queue until the JS engine is idle.

JS engine thread

• Also known as the JS kernel, it handles JavaScript scripts. (V8 engine, for example).
• The JS engine thread is responsible for parsing JavaScript scripts and running code.
• The JS engine waits for tasks to arrive in the task queue and then processes them. There is only one JS thread running the JS program at any given time in the render process of a Tab page. JavaScript is single-threaded.
• Also note that the GUI rendering thread and the JS engine thread are mutually exclusive, so if the JS execution takes too long, the page rendering will be incoherent and the page rendering load will block.

GUI rendering thread details operation

• Parsing the HTML generates a DOM tree
• Parsing CSS generates a CSSOM rule tree
• Combine the DOM tree with the CSSOM rule tree to generate the render tree
• Traverse the render tree to start the layout, calculating the location size information for each node
• Draws each node of the render tree to the screen

Repaint with Reflow

• Redraw. Part of the screen is redrawn without affecting the overall layout. For example, the background color of a CSS changes, but the geometry and position of the elements remain the same.
• Backflow. This means that the geometry of the component has changed and we need to revalidate and evaluate the render tree.

Other Frequently Asked Questions

• GUI threads and JS engine threads are mutually exclusive. Why mutual exclusion? Because the JS engine manipulates the DOM, if it is not mutually exclusive, the DOM node will be removed while building the DOM tree.
• JS blocks page loading. So the JavaScript code should be placed at the bottom of the page and executed last. Otherwise, the screen will be blank if parsing JavaScript takes a long time.
• Will the CSS introduced in the header be executed first? Header incoming CSS is asynchronously downloaded by a separate thread, so if the header hits the incoming CSS, it is queued until the DOM tree has been parsed.

Enter the URL to the browser to complete the rendering process (detailed version)

• Enter the address in the browser address bar. (www.xx.com)

• If not, the browser will complete your protocol number and port for you.

• The browser then analyzes the protocol number, domain name, and port of the address. Against the domain names in the cache.

• If they are the same, get the IP address directly.

• If no, go to the local DNS server. Others get an IP address.

• If not, go directly to the root DNS server. At this point, the root DNS server either gives the IP address or indicates which DNS server to look for. Until we find an IP address. This process is called DNS resolution.

• Once you have the IP address, you need to communicate with it. Therefore, the TCP connection is established through the three-way handshake.

  • The client sends a packet to the server indicating that I want to request a connection.
  • When the server receives the request, it sends a packet back to the client indicating that I have received your request.
  • The client sends another packet to indicate that the handshake ends.

• The client sent a request packet. Procedure

• The server processes request packets and sends response packets.

• The browser receives the response message and the rendering process starts rendering the page.

  • Parsing the HTML generates a DOM tree.
  • Parsing CSS generates a CSSOM tree.
  • Combine the DOM and CSSOM trees to generate a render tree.
  • Traverse the render tree to start the layout, calculating the location and size of each node and other information.
  • Draws each node of the render tree to the screen.

• The browser renders and closes the connection with four waves.

  • The browser sends a packet requesting disconnection.
  • The server sends a packet to the client indicating that I have received your request.
  • The server sends the packet to the client again, indicating that I also want to disconnect.
  • The client sends a packet to the server indicating that I have received your shutdown request. The connection is then closed and the communication ends.

Refer to the article

• Overview of front-end history evolution
• A brief history of front-end development
• About compilers and interpreters
• Browser kernel, rendering engine, JS engine introduction
• Browser threads and processes
• Browser rendering mechanism
• Principles and processes of the browser rendering mechanism