1. Why do we need to know about browsers?
1. For front-end developers
1. Browsers are the first line of user experience. We need to understand how browsers work in order to effectively design and implement user interfaces that ensure a good user experience.
2. A good product needs to consider browser compatibility. We need to be aware of these differences to ensure that the website or app will work correctly in different browsers, as different browsers may have different levels of support and implementation details for CSS, JavaScript, etc.
3. The pursuit of good performance requires us to understand the rendering mechanism of the browser and the working principle of the JavaScript engine, as they directly affect the loading speed and running efficiency of the page.
4. Consideration of the security of user information requires us to pay attention to the browser. We need to understand the security features of browsers, such as source policies and content security policies, in order to better protect user data from attacks such as XSS and CSRF.
5. Debugging tools need to be used in the R&D process, and the developer tools provided by the browser can help us debug code, analyze performance, check network requests, etc.
2. For backend developers
1. When designing interfaces, back-end developers need to design APIs for front-end calls, and understanding how browsers work can help design more efficient and secure interfaces.
2. In a headless architecture, the backend provides server-side APIs, and the front-end calls these APIs through the browser. Back-end developers need to understand how browsers make HTTP requests, cross-origin issues, etc., to ensure the correct implementation and invocation of APIs.
3. In the process of performance monitoring, back-end developers may need to pay attention to server load problems caused by non-optimization of front-end code, such as excessive HTTP requests, large data transmission, etc., which requires certain browser knowledge to solve the problem together.
4. For back-end developers who pursue full-stack development capabilities, understanding browser-related knowledge is essential, which helps the back-end to better understand the workflow of the entire system and improve cross-domain collaboration.
2. Overview of browser development
1. Macro development
1. The browser is born
In 1990, British computer engineer Tim Berners-Lee developed the first web server and graphical web browser while working at the European Organization for Nuclear Research (CERN) in Switzerland. He called this new window into the world of the Internet "WorldWideWeb" (i.e., "World Wide Web").
A year later, Berners-Lee commissioned Nicola Pellow, a mathematics student at CERN, to write the "Command-Line Mode Browser," a browser that can be used in simple computer terminals.
2. Browser Zhuolu Zhongyuan
1. The release of Mosaic browser in 1993 marked the birth of the graphical interface web browser. It was developed by the National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign.
2. In 1994 some of Mosaic's original developers founded Netscape and launched Netscape Navigator, which quickly became the most popular browser.
3. In 1995, Microsoft launched Internet Explorer (IE) and bundled it with the Windows operating system, a strategy that greatly boosted IE's market share.
4. During the period from 1995 to 2001, the competition between Netscape Navigator and Internet Explorer was fierce. In the end, IE won the war by virtue of its bundle advantage with Windows.
5. In 2003, Apple launched its own browser, Safari.
6. In 2004, the Mozilla Foundation released the Firefox browser. It was developed from Netscape's source code and is loved by users for its open-source nature, security, and extensibility.
7. In 2008, Google released the Chrome browser, which quickly gained market share with its speed, simplicity and innovative multi-process architecture.
8. From 2004 to 2010, with the rise of Firefox and Chrome, the browser market once again entered a stage of fierce competition. IE's market share began to decline, with Chrome and Firefox becoming the main competitors.
9. In 2014, the HTML5 standard was finalized, which promoted the further development of web technology, and major browser vendors began to support this standard.
10. In 2015, Microsoft released a new browser, Edge, to replace the old Internet Explorer. Edge initially used its own EdgeHTML rendering engine, and later switched to Chromium's Blink engine.
3. To wrap things up
The development of browsers is an ongoing process, and competition between vendors is also driving technological advancement. As Internet technology continues to evolve, we can expect browsers to continue to innovate in terms of speed, security, user experience, and functionality; With the popularity of smartphones and tablets, the importance of mobile browsers is increasing, with Safari dominating on iOS devices and Chrome becoming mainstream on Android devices.
2. Micro-development
1. Single-process architecture
As the name suggests, a single-process browser means that all the functional modules of the browser run in the same process, including the network, plug-ins, JavaScript runtime, rendering engine, and pages. In fact, before 2007, browsers on the market were single-process. The architecture of a single-process browser is shown in the following figure:
With so many functional modules running in a single process, it is a major contributor to the instability, fluidity, and insecurity of single-process browsers. Here's why:
(1) Instability
In the early days, browsers needed plug-ins to implement various powerful functions such as web videos, web games, etc., but plug-ins are the most problematic modules, and they also run in the browser process, so an unexpected crash of one plug-in can cause the entire browser to crash. In addition to plugins, render engine modules are also unstable, and often some complex JavaScript code can cause render engine modules to crash. As with plugins, a crash in the rendering engine can cause the entire browser to crash.
(2) Not fluent
As you can see from the "Schematic Diagram of the Single-Process Browser Architecture" above, all page rendering modules, JavaScript execution environments, and plug-ins are running in the same thread, which means that only one module can be executed at a time.
function test() {
while(true) {
console.log('test')
}
} If you let this script run on a page in a single-process browser, it will monopolize the entire thread, so that other modules running in the thread have no chance to be executed. Because all the pages in the browser are running in this thread, none of these pages have a chance to perform the task, which will cause the entire browser to become unresponsive and become stuttering.
(3) Unsafe
Plug-ins can be written in C/C++ and other code, through which you can get any resources of the operating system, and when you run a plug-in on the page, it means that the plug-in can fully operate your computer. If it's a malicious plugin, it can release viruses, steal your account passwords, and cause security issues.
Page scripts, which can obtain system privileges through browser vulnerabilities, can also do malicious things to your computer after obtaining system privileges, which will also cause security problems.
2. Multi-process architecture
(1) Process architecture at the time of Chrome's release in 2008
(2) The current multi-process architecture
1. Browser processes. It is mainly responsible for interface display, user interaction, sub-process management, and provides storage and other functions.
2. Rendering process. The core task is to convert HTML, CSS, and JavaScript into web pages that users can interact with, and the typography engine Blink and JavaScript Engine V8 both run in this process, and by default, Chrome creates a rendering process for each tab tag. For security reasons, the rendering process runs in sandbox mode.
3. GPU process. Actually, Chrome didn't have a GPU process when it was first released. The original intention of using GPU was to achieve the effect of 3D CSS, but then the UI interface of web pages and Chrome chose to use GPU for drawing, which made GPU a common requirement for browsers. Finally, Chrome has also introduced GPU processes on top of its multi-process architecture.
4. Network Processes. Mainly responsible for the loading of web resources on the page, it used to run as a module in the browser process, and only recently did it become a separate process.
5. Plug-in process. It is mainly responsible for the operation of the plug-in, because the plug-in is easy to crash, so it needs to be isolated by the plug-in process to ensure that the crash of the plug-in process will not affect the browser and page.
3. Core components of the browser
1. Introduction to the browser interface
1. The user interface is mainly the part of the browser that is not displayed by the web page, including the address bar, bookmarks, forward and back buttons, history and other user-operable parts
2. The browser engine is used to transfer instructions between the user interface and the rendering engine or to read and write data in the client's local cache, and it is the core of the communication between the various parts
3. The rendering engine is mainly responsible for parsing DOM and CSS rules, and the browser kernel mainly refers to the rendering engine and JavaScript engine
4. The network module is responsible for sending network requests and downloading network resources
5. JavaScript engine is used to interpret and execute JavaScript code, such as V8
6. The UI backend is used to draw basic browser controls
7. Data persistent storage is called through the API provided by the browser engine
2. Summary of the rendering engines and interpreters currently used by browsers
| Browser kernel | Represents the browser |
| Trident | IE |
| Webkit | Safari、Edge |
| Blink | Chrome |
| Gecko | Firefox |
| Soon | Aupen |
| Dual-core | 360 Browser, Cheetah Browser, Sogou, Aoyou, QQ Browser, Baidu Browser, 2345 Browser |
3. Browser's interpreter
1. Rhino, managed by the Mozilla Foundation, is open source and written entirely in Java.
2. SpiderMonkey,第一款JavaScript引擎,早期用于Netscape Navigator,现时用于Mozilla Firefox。
3. JavaSV8, open source, developed by Google Denmark and part of Google Chrome.
4. criptCore, open source, for Safari.
5. Chakra (JScript引擎)，用于Internet Explorer11。
6. Chakra (JavaScript engine) for Microsoft Edge.
7. KJS, KDE's ECMAScript/JavaScript engine, originally developed by Harry Burton for use in the KDE project's Konqueror web browser.
Fourth, the current market share of each browser
1. Global market share
2. China's market share ranking
Fifth, summarize it as a whole
In this article, we will introduce the necessity of understanding browsers as a matter of development, as well as the basic situation and overall development of browsers. When considering product positioning (what kind of target product to develop), we need to have a certain understanding of the browser, and the whole article has a certain reference significance for R&D and products.
This article mainly refers to "Browser Working Principles and Practices"
If you like it, leave your comments, and you can share them with the browser in depth after leaving your likes.
Finally, everyone is welcome to exchange and learn and grow together.