Why Developers Should Understand Browsers and Their Evolution

1. Why Should We Understand Browsers?

1. For Frontend Developers

Browsers are the first line of user experience; understanding their operation helps design and implement effective UI.

Product compatibility across browsers requires knowledge of CSS, JavaScript support differences.

Performance optimization depends on the rendering mechanism and JavaScript engine.

Security features such as same‑origin policy and CSP are essential to protect user data from XSS, CSRF, etc.

Developer tools in browsers aid debugging, performance analysis, and network inspection.

2. For Backend Developers

Designing APIs that front‑ends call benefits from understanding browser request handling and security.

In front‑end/back‑end separation, backend must know HTTP methods, CORS, and other browser‑related issues.

Backend performance monitoring may need awareness of front‑end inefficiencies that increase server load.

Full‑stack developers gain better system insight by learning browser fundamentals.

2. Overview of Browser Development

Macro Development

1. Birth of Browsers

In 1990, Tim Berners‑Lee at CERN created the first web server and a graphical web browser called "WorldWideWeb".

One year later, Nicola Pellow wrote a command‑line browser for simple terminals.

Early Milestones

1993: Mosaic introduced graphical web browsing (developed by NCSA).

1994: Netscape Navigator launched, quickly becoming popular.

1995: Microsoft released Internet Explorer (IE) and bundled it with Windows, gaining market dominance.

2003: Apple introduced Safari.

2004: Mozilla Foundation released Firefox, derived from Netscape code.

2008: Google launched Chrome with a multi‑process architecture.

2014: HTML5 standard finalized, driving further web innovation.

2015: Microsoft released Edge, initially using EdgeHTML and later switching to Chromium's Blink engine.

Summary

Browser development is a continuous process driven by competition, leading to advances in speed, security, user experience, and functionality; mobile browsers now dominate on smartphones and tablets.

2. Micro Development

Single‑Process Architecture

In a single‑process browser, all modules (network, plugins, JavaScript engine, rendering engine, UI) run in the same OS process, which makes the browser unstable, sluggish, and insecure.

(1) Instability

Plugins and the rendering engine can crash, taking down the entire browser.

(2) Lack of Smoothness

All tasks share one thread, so only one module can execute at a time, causing UI freezes.

function test() {
while(true) {
console.log('test')
}
}

Running such a script in a single‑process browser monopolizes the thread, preventing other modules from executing and making the browser unresponsive.

(3) Security Risks

Plugins written in native code can access the operating system, potentially executing malicious actions; page scripts can exploit browser vulnerabilities to gain system privileges.

Multi‑Process Architecture

(1) Chrome’s Original Multi‑Process Design (2008)

(2) Modern Multi‑Process Design

Key processes:

Browser process – handles UI, user interaction, child‑process management, and storage.

Renderer process – parses HTML/CSS/JS, runs Blink and V8; each tab gets its own renderer sandboxed for security.

GPU process – offloads graphics rendering, enabling 3D CSS and UI compositing.

Network process – dedicated to loading network resources.

Plugin process – isolates plugins to prevent crashes from affecting the whole browser.

3. Core Browser Components

1. Browser UI

Components include address bar, bookmarks, navigation buttons, history, etc.

2. Browser Engine

Acts as a bridge between the UI and the rendering engine, handling communication and local data caching.

3. Rendering Engine

Parses DOM and CSS, responsible for layout and painting; together with the JavaScript engine it forms the browser core.

4. Network Module

Manages HTTP requests and resource downloading.

5. JavaScript Engine

Executes JavaScript code (e.g., V8 in Chrome).

6. UI Backend

Draws basic browser controls.

7. Persistent Storage

Provides APIs for data storage (cookies, IndexedDB, etc.).

Current Rendering Engines and Their Browsers

Engine

Representative Browsers

Trident

Internet Explorer

WebKit

Safari, early Edge

Blink

Chrome

Gecko

Firefox

Presto

Opera (legacy)

Dual‑core (360, Sogou, etc.)

Various Chinese browsers

JavaScript Interpreters

Rhino – Java‑based, maintained by Mozilla.

SpiderMonkey – original Netscape engine, now used in Firefox.

V8 – open‑source, developed by Google, used in Chrome.

JavaScriptCore – used by Safari.

Chakra – used in IE11 and legacy Edge.

KJS – KDE’s ECMAScript engine for Konqueror.

4. Market Share of Major Browsers

Global Share

China Market Ranking

5. Overall Summary

This article highlights why understanding browsers is essential for developers and product teams, reviews the historical evolution from single‑process to multi‑process designs, and outlines core components, rendering engines, and market trends, providing a solid reference for both R&D and product planning.

Reference: "Browser Working Principles and Practice".