Why Developers Must Master Browsers: History, Architecture & Market Share

Why We Need to Understand Browsers

1. For Frontend Developers

Browsers are the first line of user experience; knowing how they work helps design and implement effective UIs.

Product quality depends on browser compatibility; understanding differences ensures sites work across browsers.

Performance requires knowledge of rendering mechanisms and JavaScript engine internals.

Security features such as same‑origin policy and CSP are essential to protect user data.

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

2. For Backend Developers

Designing APIs that frontends call benefits from understanding browser request handling and security.

In a front‑end/back‑end split, backend engineers must know HTTP, CORS, and how browsers load resources.

Backend performance monitoring may need to consider inefficient front‑end code that increases server load.

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

2. Overview of Browser Development

Macro Evolution

1990 – Tim Berners‑Lee created the first web server and graphical browser (WorldWideWeb) at CERN.

1991 – A command‑line browser was written for simple terminals.

1993 – Mosaic introduced graphical web browsing.

1994 – Netscape Navigator launched, quickly becoming popular.

1995 – Microsoft released Internet Explorer and bundled it with Windows, gaining market share.

1995‑2001 – A fierce “browser war” ended with IE dominant due to OS integration.

2003 – Apple released Safari.

2004 – Mozilla Firefox appeared, built on the open‑source Netscape code.

2008 – Google Chrome entered the market with a fast, multi‑process architecture.

2014 – HTML5 became a standard, driving further innovation.

2015 – Microsoft Edge replaced IE, initially using EdgeHTML then switching to Chromium’s Blink.

Micro Evolution

Single‑Process Architecture

In early browsers all modules (network, plugins, JavaScript engine, rendering engine, pages) ran in one process, leading to instability, poor performance, and security risks.

Problems of a single‑process model:

Instability : Plugins and the rendering engine run in the same process; a crash in either can bring down the whole browser.

Unsmoothness : All tasks share one thread, so a long‑running script blocks rendering and other modules.

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

Security : Native plugins can access the operating system, and malicious plugins or vulnerable scripts can compromise the user.

Multi‑Process Architecture

2008 – Chrome introduced a multi‑process model separating browser UI, rendering, GPU, network, and plugin tasks.

Current browsers typically use the following processes:

Browser process – UI, user interaction, and process management.

Renderer process – Runs Blink (or WebKit) and V8; each tab gets its own sandboxed renderer.

GPU process – Handles GPU‑accelerated drawing and 3D CSS effects.

Network process – Dedicated to loading network resources.

Plugin process – Isolates plugins to prevent crashes from affecting the main browser.

3. Core Browser Components

1. Browser UI

Address bar, bookmarks, navigation buttons, history, etc.

2. Browser Engine

Coordinates communication between UI and rendering engine, and handles local storage.

3. Rendering Engine

Parses HTML/CSS and renders the page; 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, SpiderMonkey, Chakra).

6. UI Backend

Draws basic browser controls.

7. Data Persistence

Provides APIs for local storage, cookies, IndexedDB, etc.

Rendering Engines and Their Representative Browsers

Trident – Internet Explorer

WebKit – Safari, legacy Edge

Blink – Chrome

Gecko – Firefox

Presto – Opera (historical)

Dual‑core (Chinese browsers) – 360, Sogou, QQ, Baidu, 2345, etc.

JavaScript Interpreters

Rhino – Java‑based, maintained by Mozilla.

SpiderMonkey – First JS engine, used in Firefox.

V8 – Open‑source, developed by Google for Chrome.

JavaScriptCore – Used by Safari.

Chakra – Used by IE 11 and the new Edge.

KJS – KDE’s engine for Konqueror.

4. Market Share of Major Browsers

Global market share (latest data):

China market share ranking:

5. Overall Summary

This article highlights the necessity for developers to understand browsers, reviews their historical development, explains modern multi‑process architectures, lists core components, rendering engines, and JavaScript interpreters, and provides current market‑share information, offering valuable reference for both product and engineering decisions.