From Code to Pixels
Ever wonder what happens when you load a webpage? It's not magic, but a highly orchestrated process involving multiple components. This guide interactively explores the journey of your code, from a file on a server to a living, breathing page on your screen.
The Big Picture: Browser Architecture
Modern browsers aren't single applications; they're like mini-operating systems. To keep you safe and ensure stability, they use a multi-process architecture. This means different parts of the browser run in isolated, sandboxed processes. Hover over the components below to see how they work together.
š§ Browser Process
The "brain" coordinating everything.
šØ Renderer Process
Renders web content in a tab.
š¼ļø GPU Process
Handles graphics tasks.
š Network Process
Manages all internet traffic.
Hover over a process to learn more.
The Twin Engines of a Web Page
Inside each Renderer Process, two specialized engines work together. The **Rendering Engine** builds the page's structure and appearance, while the **JavaScript Engine** executes its logic and interactivity. They are separate but constantly communicating.
Blink: The Rendering Engine
Blink's job is to turn HTML and CSS into pixels on the screen. It follows a clear pipeline:
- ā Parse HTML/CSS: Builds the Document Object Model (DOM) from HTML and the CSS Object Model (CSSOM) from styles.
- ā Render Tree: Combines the DOM and CSSOM to figure out what needs to be displayed.
- ā Layout: Calculates the exact size and position of every element.
- ā Paint: Draws the pixels for each element onto the screen.
V8: The JavaScript Engine
V8's job is to execute JavaScript code as fast as possible. It uses a technique called Just-In-Time (JIT) compilation. Click the steps below to see how it works.
Click a step to see its description.
The Bridge: How JavaScript Commands the DOM
If the engines are separate, how does JavaScript change the page? They don't share memory. Instead, the browser provides a bridge: the **Web APIs**. JavaScript doesn't touch the DOM directly; it sends commands through this official API layer.
JavaScript Code
Your script calls a function like `document.getElementById()`.
Web API (The Bridge)
The browser translates this call into a command for the Rendering Engine.
DOM Manipulation
The Rendering Engine modifies the DOM, and schedules a repaint to show the change.
A Tale of Two Heaps
This separation extends to memory. JavaScript objects and DOM elements live in different memory "heaps," managed by separate but coordinated Garbage Collectors.
V8 Heap (JavaScript)
Managed by the **Orinoco** GC. Stores JS objects, arrays, functions, etc. References to DOM nodes are just lightweight "wrapper" objects here.
Blink Heap (Native C++)
Managed by the **Oilpan** GC. Stores the actual DOM nodes. This is where the real structure of the page lives.
The Execution Flow
JavaScript is single-threaded, meaning it can only do one thing at a time. To prevent the UI from freezing, browsers use an **Event Loop** to handle asynchronous tasks like timers or network requests. TypeScript adds a safety layer on top of this, but it's all plain JavaScript by the time it runs.
The Event Loop Explained
The TypeScript Layer
TypeScript doesn't change how browsers work. It's a development tool that adds type safety. Your `.ts` files are **transpiled** into standard `.js` files, with all type information erased, before the browser ever sees them. It's a pre-flight check, not a new runtime.
Your Code (`.ts`)
const name: string = "World";
Browser-Ready Code (`.js`)
const name = "World";
Detailed View: The Full Article
For those who want to dive deeper, the complete text from the original report is included below. Click on any section title to expand it.