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:

configure local Chromium environment,
obtain source,
understand depot_tools,
understand gclient,
understand dependencies,
understand GN,
understand the current platform build executor,
configure build args,
build Chromium,
launch local browser,
build smaller targets,
modify source,
rebuild incrementally,
attach debugger,
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:

verify in browser,
identify spec rules,
trace Blink implementation,
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:

parser
selector representation
selector matching
specificity
cascade
inheritance
computed style
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:

block flow
margins/padding
nested boxes
inline text
basic flex
intrinsic sizing
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:

web abstraction
enforcement boundary
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:

pick a behavior,
read spec,
locate WPT,
run test,
locate Blink implementation,
deliberately break behavior,
observe failure,
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:

hard-coded boxes
HTML parser
DOM
CSS parser
selector matching
cascade
layout tree
block layout
text
display list
raster
events
incremental invalidation
minimal JS integration
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:

element representation
DOM renderer
reconciliation
keyed children
function components
state
effects
batching
scheduling
interruptible work
priorities
context
error boundaries
SSR
hydration
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:

what problem is solved?
what invariant is maintained?
what complexity did our implementation avoid?
what failure occurs without this?
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.

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.

Frontend Principal Engineer — Browser Internals, Framework Runtimes & Web Platform Architecture