Browser & Framework Internals

Mission

Create a systems-construction track for becoming deeply competent in:

  • Chromium source code
  • Blink
  • V8 integration
  • rendering-engine internals
  • browser architecture
  • browser debugging
  • browser contribution
  • frontend framework internals
  • state-management internals
  • compilers/bundlers
  • browser automation
  • source-code archaeology

The objective is to remove abstraction boundaries.

The learner should eventually understand:

Application
↓
Framework
↓
DOM / Web APIs
↓
Blink
↓
Style
↓
Layout
↓
Paint
↓
Compositor
↓
GPU
↓
Pixels

and be able to move both directions through the stack.

Always verify current Chromium directory names, contribution requirements, build commands, build executors, testing procedures, and framework source organization against upstream documentation before relying on them.

1. Browser Engine Engineering: From Web Page to Pixels

The learner must eventually be able to:

  • clone and build Chromium locally,
  • navigate the Chromium source tree,
  • debug Chromium and Blink,
  • trace browser behavior from Web API to implementation,
  • understand renderer/browser/GPU/network boundaries,
  • read and modify Blink code,
  • write browser-engine tests,
  • investigate Chromium bugs,
  • prepare Chromium patches,
  • work with Chromium reviewers/OWNERS,
  • and make meaningful upstream contributions.

Treat source-code competence as a first-class engineering skill.

2. Chromium Architecture Map

Build a mental model before reading files.

Conceptual architecture:

Chromium
│
├── Browser Process
├── Renderer Processes
│   └── Blink
│       ├── HTML
│       ├── DOM
│       ├── CSS
│       ├── Style
│       ├── Layout
│       ├── Paint
│       └── Web APIs
│
├── V8
│   └── JavaScript / WebAssembly
│
├── Compositor
├── GPU Process
├── Network Service
├── Storage
├── Accessibility
├── DevTools
└── Platform / UI

Map these concepts to the current Chromium tree.

Likely important areas include:

//content
//third_party/blink
//v8
//cc
//gpu
//net
//services
//components
//ui
//base

For each:

  • responsibility
  • process
  • callers
  • callees
  • security boundary
  • thread/task runner
  • tests
  • ownership
  • dependency-direction rules

3. Build Chromium From Source

Hands-on lab:

  1. configure local Chromium environment,
  2. obtain source,
  3. understand depot_tools,
  4. understand gclient,
  5. understand dependencies,
  6. understand GN,
  7. understand the current platform build executor,
  8. configure build args,
  9. build Chromium,
  10. launch local browser,
  11. build smaller targets,
  12. modify source,
  13. rebuild incrementally,
  14. attach debugger,
  15. run tests.

Explain:

  • debug vs optimized builds
  • component builds
  • assertions
  • symbols
  • incremental compilation
  • target graphs
  • generated sources
  • build configurations
  • why Chromium builds are large
  • iteration-time reduction

Never freeze commands permanently; consult current upstream docs.

4. Chromium C++ for Frontend Engineers

Teach only the modern C++ needed to read and contribute to Chromium:

  • RAII
  • ownership
  • smart pointers
  • references
  • move semantics
  • templates
  • callbacks
  • lambdas
  • enums
  • optionals
  • spans
  • Chromium containers/utilities
  • task runners
  • sequences
  • threading
  • weak pointers
  • reference counting
  • IPC interfaces
  • generated code
  • Blink GC types

For every concept, locate real Chromium examples.

5. Complete Rendering Pipeline

Teach:

Network Bytes
↓
Character Decoding
↓
HTML Tokenization
↓
HTML Tree Construction
↓
DOM
↓
CSS Parsing
↓
Style Data
↓
Selector Matching
↓
Cascade
↓
Computed Style
↓
Layout Tree
↓
Layout
↓
Fragments
↓
Pre-Paint
↓
Paint
↓
Display Items
↓
Paint Chunks
↓
Property Trees
↓
Compositing
↓
Rasterization
↓
GPU
↓
Pixels

For every transition answer:

  • subsystem
  • major input structure
  • major output structure
  • source classes/files
  • invalidation rules
  • caching
  • incremental behavior
  • thread/process
  • performance pathologies
  • DevTools visibility

6. HTML Parser Internals

Cover:

  • input streams
  • character decoding
  • tokenizer
  • tokens
  • tree builder
  • insertion modes
  • malformed-markup recovery
  • parser-blocking scripts
  • speculative/preload parsing
  • document.write
  • script execution
  • DOM node creation
  • custom elements
  • scheduling

Source-reading lab:

<html>
  <body>
    <table>
      hello
      <div>world</div>
    </table>
  </body>
</html>

Predict the DOM.

Then:

  1. verify in browser,
  2. identify spec rules,
  3. trace Blink implementation,
  4. locate tests.

7. Build a Mini HTML Parser

Implement:

Stage 1

Tokenizer.

Stage 2

DOM-like tree.

Stage 3

Basic error recovery.

Stage 4

Conceptual script interruption.

Stage 5

Compare with Blink.

The goal is architectural understanding, not standards completeness.

8. DOM Internals

Study:

  • Node
  • Element
  • Document
  • Text
  • attributes
  • tree mutation
  • shadow trees
  • custom elements
  • mutation observers
  • lifecycle
  • event targets
  • ownership
  • GC
  • bindings

Trace:

document.createElement("div")
element.setAttribute("class", "foo")
parent.appendChild(element)
element.remove()

through:

JavaScript
↓
Binding
↓
Blink
↓
DOM Mutation
↓
Invalidation
↓
Style/Layout/Paint consequences

9. JavaScript ↔ Browser Binding Layer

Trace APIs such as:

document.querySelector(...)

Cover:

  • Web IDL
  • generated bindings
  • V8
  • JS wrappers
  • native DOM objects
  • exceptions
  • promises
  • callbacks
  • GC interaction
  • execution contexts
  • realms
  • security boundaries

10. CSS Engine Internals

Study:

  • tokenization
  • parsing
  • selectors
  • selector matching
  • specificity
  • cascade
  • inheritance
  • custom properties
  • computed values
  • style sharing
  • invalidation
  • pseudo-elements
  • pseudo-classes
  • media queries
  • container queries

Investigate:

  • what happens after classList.add
  • how invalidation scope is determined
  • why every DOM change does not trigger global recomputation
  • selector-complexity implications

11. Build a Mini CSS Engine

Support:

div {}
.foo {}
#header {}
.parent .child {}

Implement:

  1. parser
  2. selector representation
  3. selector matching
  4. specificity
  5. cascade
  6. inheritance
  7. computed style
  8. style tree

Then intentionally use global recomputation and optimize toward invalidation.

12. Layout Engine Internals

Cover:

  • containing blocks
  • box model
  • intrinsic sizing
  • block layout
  • inline layout
  • line breaking
  • flexbox
  • grid
  • fragmentation
  • percentage resolution
  • min/max sizing
  • replaced elements
  • writing modes
  • RTL
  • scroll containers

Mental model:

DOM Tree
↓
Style
↓
Layout Objects
↓
Fragments
↓
Geometry

13. Build a Mini Layout Engine

Stages:

  1. block flow
  2. margins/padding
  3. nested boxes
  4. inline text
  5. basic flex
  6. intrinsic sizing
  7. dirty-layout tracking

Input:

DOM + Computed Style

Output:

Layout Tree + Geometry

Compare every stage to Blink.

14. Paint Internals

Study:

  • paint invalidation
  • display items
  • paint chunks
  • property trees
  • transforms
  • clipping
  • effects
  • stacking contexts
  • paint order
  • hit testing

Trace CSS properties through the paint/compositor pipeline.

15. Compositor and GPU Pipeline

Cover:

  • compositor architecture
  • compositor threads
  • layers
  • property trees
  • raster
  • tiles
  • GPU process
  • surfaces
  • scrolling
  • animations
  • frame production
  • vsync
  • dropped frames

Relate to:

60 Hz ≈ 16.7 ms/frame
120 Hz ≈ 8.3 ms/frame

Explain why the app does not own the full budget.

16. Browser Scheduling

Study:

  • event loop
  • tasks
  • microtasks
  • rendering opportunities
  • animation frames
  • idle work
  • input
  • timers
  • network callbacks
  • compositor interaction

Trace:

setTimeout(...)
Promise.resolve().then(...)
requestAnimationFrame(...)
queueMicrotask(...)

17. V8 Integration

Cover enough V8 to understand browser execution:

  • JS parsing
  • AST
  • bytecode
  • interpreter
  • optimizing compiler
  • shapes/hidden classes
  • inline caches
  • GC
  • deoptimization
  • WebAssembly
  • isolates
  • contexts

Clearly distinguish:

  • V8
  • Blink
  • Chromium/content

18. Multiprocess Browser Architecture

Study:

Browser Process
│
├── Renderer A
├── Renderer B
├── GPU
├── Network Service
└── Utility Processes

Cover:

  • process isolation
  • frames
  • renderer processes
  • site isolation
  • sandboxing
  • IPC
  • Mojo
  • privileges
  • compromised-renderer model
  • browser-process trust boundary

Design exercise:

A Web API requires privileged OS access. Decide what belongs in Blink, renderer, Mojo interface, and browser process.

19. Browser Security Architecture

Connect frontend security to browser enforcement:

  • same-origin policy
  • CORS
  • CSP
  • iframe isolation
  • sandbox
  • cookies
  • permissions
  • navigation
  • site isolation
  • Trusted Types

For each:

  1. web abstraction
  2. enforcement boundary
  3. compromised-renderer implications

20. Chromium Debugging

Teach:

  • native debugger
  • breakpoints
  • conditional breakpoints
  • stack inspection
  • logs
  • DCHECK/assertions
  • tracing
  • crash dumps
  • browser-process debugging
  • renderer-process debugging
  • GPU debugging
  • Blink debugging

Lab:

Set breakpoints around DOM creation, style recalculation, layout, and paint.

21. Chromium Tracing

Teach:

  • trace events
  • task execution
  • main-thread activity
  • compositor activity
  • frame production
  • renderer/browser interaction

Progress:

Chrome DevTools Performance
↓
Chromium-level tracing
↓
source-code correlation

22. Chromium Test Architecture

Learn:

  • unit tests
  • browser tests
  • Blink web tests
  • Web Platform Tests
  • regression tests
  • pixel/reference tests where appropriate
  • integration tests

Bug-fix workflow:

Reproduce
↓
identify correct layer
↓
minimal failing test
↓
fix
↓
verify
↓
run surrounding tests

23. Web Platform Tests

Understand:

  • interoperability
  • browser-neutral behavior
  • specification conformance
  • cross-browser testing
  • harnesses
  • reference tests

Exercise:

  1. pick a behavior,
  2. read spec,
  3. locate WPT,
  4. run test,
  5. locate Blink implementation,
  6. deliberately break behavior,
  7. observe failure,
  8. restore/fix.

24. Chromium Contribution Workflow

Teach current upstream process, including concepts such as:

  • contributor requirements
  • CLA
  • AUTHORS
  • issue tracking
  • Gerrit
  • CLs
  • OWNERS
  • reviewers
  • presubmit
  • formatting
  • try jobs
  • commit queue
  • patchsets
  • review feedback

Always verify against current official Chromium docs.

Contribution ladder:

Contribution 0

Build Chromium.

Contribution 1

Docs/test-only improvement.

Contribution 2

Small isolated correctness fix.

Contribution 3

Blink behavior bug + regression test.

Contribution 4

Small rendering/style/layout improvement.

Contribution 5

Cross-component architectural change.

Maintain for each:

  • bug
  • reproduction
  • spec
  • suspected subsystem
  • source path
  • call path
  • test
  • proposed fix
  • reviewer feedback
  • architectural lesson

25. Chromium Source Archaeology

Missions:

  • document.createElement
  • classList.add
  • getBoundingClientRect
  • requestAnimationFrame
  • Fetch
  • CSS Grid
  • click/input handling
  • accessibility representation

For each map:

Public Web API
→ Binding
→ Blink
→ Chromium subsystem
→ Process/thread
→ downstream effect

26. Build a Browser Engine From Scratch

Project:

mini-browser/

Pipeline:

HTTP
↓
HTML Parser
↓
DOM
↓
CSS Parser
↓
Style
↓
Layout
↓
Display List
↓
Paint
↓
Pixels

Milestones:

  1. hard-coded boxes
  2. HTML parser
  3. DOM
  4. CSS parser
  5. selector matching
  6. cascade
  7. layout tree
  8. block layout
  9. text
  10. display list
  11. raster
  12. events
  13. incremental invalidation
  14. minimal JS integration
  15. profiling/optimization

At every stage compare:

Our implementation
vs.
Production browser requirements
vs.
Blink architecture

27. Build a React-Like Runtime

Project:

mini-react/

Stages:

  1. element representation
  2. DOM renderer
  3. reconciliation
  4. keyed children
  5. function components
  6. state
  7. effects
  8. batching
  9. scheduling
  10. interruptible work
  11. priorities
  12. context
  13. error boundaries
  14. SSR
  15. hydration
  16. concurrency experiments

Derive why Fiber-like data structures become useful rather than copying them mechanically.

28. React Source-Code Apprenticeship

After building the mini runtime, study current React source.

Investigate:

  • element creation
  • reconciliation
  • Fiber
  • work loop
  • scheduler
  • hooks
  • DOM renderer
  • events
  • commit
  • hydration
  • server rendering

For every reading:

  1. what problem is solved?
  2. what invariant is maintained?
  3. what complexity did our implementation avoid?
  4. what failure occurs without this?
  5. essential architecture or production complexity?

29. Build a Vue-Like Reactive Runtime

Project:

mini-vue/

Implement:

reactive()
effect()
ref()
computed()
watch()

Conceptual dependency graph:

Reactive Object
↓
Property
↓
Dependencies
↓
Effects

Add:

  • Proxy interception
  • dependency tracking
  • triggering
  • cleanup
  • nested effects
  • computed caching
  • watchers
  • scheduling
  • batching

Create failure labs:

  • dependency leaks
  • infinite loops
  • stale dependencies

30. Build a Vue-Like Renderer

Architecture:

VNode
↓
Renderer
↓
Patch
↓
DOM

Implement:

  • elements
  • attributes
  • events
  • components
  • keyed children
  • lifecycle
  • reactive updates

Compare React-style rerendering with dependency-tracking architectures.

Ask:

What work can each architecture avoid, and how does it know?

31. Build a Template Compiler

Pipeline:

Template
↓
Tokenizer
↓
Parser
↓
AST
↓
Transform
↓
Code Generation
↓
Render Function

Implement:

  • interpolation
  • attributes
  • events
  • conditionals
  • loops

Study:

  • static analysis
  • static hoisting
  • dynamic-node detection
  • compile-time hints

32. Vue Source-Code Apprenticeship

Study current Vue areas corresponding to:

  • reactivity
  • runtime core
  • DOM runtime
  • compiler core
  • DOM compiler

Compare against the mini implementation.

33. Build a Redux-Like Store

Project:

mini-redux/

Core API:

const store = createStore(reducer)

store.getState()
store.dispatch(action)
store.subscribe(listener)

Implement:

  • reducers
  • reducer composition
  • middleware
  • enhancers
  • selectors
  • action/state recording
  • time travel
  • persistence

Middleware examples:

  • logger
  • timing
  • error handling
  • async

Then compare against Redux source.

34. Build a Client-Side Router

Project:

mini-router/

Implement:

  • URL parsing
  • History API
  • navigation
  • route matching
  • parameters
  • nested routes
  • redirects
  • loaders
  • error routes
  • back/forward
  • scroll restoration

Study:

  • aborted navigation
  • concurrent navigation
  • stale loaders
  • authentication
  • unsaved changes
  • hashes

35. Build a Server-State Query Cache

Project:

mini-query/

Architecture:

Query Key
↓
Cache
↓
Fetch
↓
Subscribers

Add:

  • deduplication
  • stale/fresh state
  • retries
  • cancellation
  • invalidation
  • background refetch
  • optimistic updates
  • rollback
  • GC
  • pagination
  • dependent queries

Create race-condition labs.

36. Build a Signals Library

Project:

mini-signals/

Implement:

  • signal
  • computed
  • effect
  • dependency graph
  • batching
  • cleanup

Compare:

React-style rerendering
Vue dependency tracking
Signals
Redux explicit updates

Focus on computational models, not syntax.

37. Build a Virtualized List Engine

Project:

mini-virtual-list/

Render 100,000 logical rows with a small DOM window.

Implement:

  • viewport calculation
  • overscan
  • fixed heights
  • dynamic heights
  • measurement
  • scrolling
  • anchor preservation

Investigate:

  • layout cost
  • DOM size
  • GC
  • scroll jank

38. Build a Minimal Bundler

Project:

mini-bundler/

Pipeline:

Entry
↓
Parse imports
↓
Dependency graph
↓
Transform
↓
Bundle

Add:

  • code splitting
  • dynamic imports
  • tree-shaking concepts
  • source maps
  • caching
  • incremental rebuild
  • HMR concepts

39. Build a JSX / Template Compiler

Implement:

Source
↓
Lexer
↓
Parser
↓
AST
↓
Transform
↓
Code Generation

Use this to understand:

  • JSX
  • template compilation
  • static analysis
  • source transforms
  • compiler errors
  • source locations

40. Build a Testing Library

Project:

mini-testing-library/

Build user-centric queries corresponding to:

  • role
  • accessible name
  • label
  • visible text

Connect:

DOM
↓
Accessibility Tree
↓
Testing
↓
User Semantics

41. Build a Browser Automation Layer

Build a small layer over browser automation.

Understand:

  • navigation
  • selectors
  • DOM queries
  • events
  • screenshots
  • network interception
  • console events
  • tracing
  • frames
  • browser contexts

Then connect it to Playwright-style E2E testing.

42. Build a Mini DevTools

Project:

mini-devtools/

Instrument an app to display:

  • component tree
  • render count
  • state changes
  • network requests
  • performance events

Later study Chrome DevTools architecture and Chrome DevTools Protocol.

Optional: custom DevTools panel.

43. Cross-Layer Trace Labs

Trace:

User clicks button
↓
Operating-system input
↓
Browser input handling
↓
DOM event
↓
Framework handler
↓
State update
↓
Framework scheduler
↓
Reconciliation / reactive effect
↓
DOM mutation
↓
Style invalidation
↓
Layout
↓
Paint
↓
Compositor
↓
GPU
↓
Frame displayed

Repeat for:

  • React update
  • Vue update
  • Redux dispatch
  • CSS class change
  • DOM insertion
  • scroll
  • animation
  • network-driven UI update

44. Source-Code Reading Ladder

Level 1

Small libraries, such as Redux-sized systems.

Goal: understand an entire production library.

Level 2

Focused framework subsystem, such as Vue reactivity.

Goal: understand one subsystem completely.

Level 3

Framework runtime.

Goal: follow complex scheduling and state structures.

Level 4

Browser subsystem.

Goal: understand production C++ architecture.

Level 5

Cross-process feature.

Goal: trace Blink + Chromium/content + Mojo.

Level 6

Contribution.

Goal: modify production source.

A source-reading exercise is not complete until you can explain:

Why this code exists
What invariant it maintains
What calls it
What it calls
What happens if removed
How it is tested
Where ownership lies

45. Reimplementation Rule

For important abstractions:

Use It
↓
Break It
↓
Build a Tiny Version
↓
Read Production Source
↓
Compare Designs
↓
Modify Production Source
↓
Explain Trade-offs

Do not begin with production source.

First derive a simple design.

Then use production source to discover the constraints that forced additional complexity.

46. "Why Does This Complexity Exist?" Notebook

For difficult production code record:

Observed Complexity:
...

My simpler design:
...

What requirement breaks my design?
...

Production constraint:
...

Resulting architecture:
...

Apply to:

  • Fiber
  • Vue scheduler
  • HTML parser states
  • layout fragmentation
  • Chromium multiprocess IPC
  • browser security boundaries
  • concurrent rendering
  • hydration
  • event delegation

The key skill is identifying which constraint caused the complexity.

47. Implementation Comparison Matrix

Compare:

  • mini React
  • React
  • mini Vue
  • Vue
  • browser behavior

Across:

  • change detection
  • scheduling
  • memory
  • consistency
  • debuggability
  • incremental work
  • failure modes
  • extensibility
  • compile-time knowledge
  • runtime knowledge

Never reduce comparisons to "which is faster?"

48. Framework Design Challenges

Examples:

Challenge A

Design a UI framework without a virtual DOM.

Challenge B

Move dependency analysis to compile time.

Challenge C

Target Canvas instead of DOM.

Challenge D

Support asynchronous rendering.

Challenge E

Design SSR + hydration.

Challenge F

Design partial hydration.

Challenge G

Design offline-first state.

For each, identify constraints, invariants, and failure modes.

49. OSS Contribution Portfolio

Progression:

Small JS Library
↓
Framework Ecosystem
↓
Developer Tooling
↓
Web Platform Test
↓
Chromium/Blink

For every contribution retain:

  • issue
  • investigation
  • code change
  • tests
  • review discussion
  • rejected alternatives
  • result
  • lessons

50. Browser/Framework Expert Capstone

From Component to Pixel

Build an application using custom implementations:

Custom JSX
↓
Custom Component Runtime
↓
Custom Reactive Store
↓
Custom Router
↓
DOM
↓
Chromium/Blink
↓
Style
↓
Layout
↓
Paint
↓
Compositor
↓
GPU
↓
Pixels

Instrument every layer that can reasonably be observed.

Explain exactly what happens after:

setCount(count + 1)

including:

  • framework scheduling
  • state update
  • reconciliation/reactivity
  • DOM operations
  • Blink invalidation
  • style
  • layout if required
  • paint if required
  • compositing if required
  • frame presentation

Also explain which stages can be skipped and why.

51. Mastery Criteria

The browser/framework track is complete only when the learner can independently:

Browser architecture

Draw Chromium's major processes and explain trust boundaries.

Source navigation

Given a browser behavior, locate the likely subsystem and implementation.

Rendering

Explain HTML → DOM → style → layout → paint → compositing in implementation-level terms.

Performance

Determine whether a change triggers style, layout, paint, or compositor work.

JS integration

Trace a Web API from JavaScript through browser bindings.

Debugging

Set native breakpoints and follow meaningful execution.

Tests

Locate, run, and modify relevant browser-engine tests.

Specifications

Connect implementation behavior to standards.

Chromium contribution

Produce at least one meaningful upstream-quality Chromium/Blink change.

Framework internals

Implement simplified working versions of:

  • React-like runtime
  • Vue-like reactive/runtime/compiler system
  • Redux-like store

Infrastructure

Implement simplified versions of:

  • router
  • query cache
  • signals
  • virtualized list
  • bundler/compiler

Architectural judgment

Explain not only how these systems work, but why their complexity exists.

52. Final Mental Model

PRODUCT
│
▼
APPLICATION
│
▼
COMPONENT FRAMEWORK
│
├── Scheduler
├── Reactivity
├── Reconciliation
└── State
│
▼
WEB APIs / DOM
│
▼
BLINK
│
├── HTML Parser
├── DOM
├── CSS
├── Style
├── Layout
├── Paint
└── Events
│
▼
CHROMIUM
│
├── Content
├── IPC
├── Network
├── Security
└── Browser Process
│
▼
COMPOSITOR
│
▼
GPU
│
▼
PIXELS

At Principal/Distinguished level, continuously move both directions:

Product requirement
↓
architecture
↓
framework
↓
browser

and:

browser constraint
↓
framework behavior
↓
application architecture
↓
user experience

The goal is to understand the frontend as one interconnected system rather than a collection of isolated libraries and abstractions.