React Native Rendering: Series Guide
This is the reading guide for the React Native Rendering series: a ground-up tour of how React Native turns JSX into pixels on a native screen. If you have ever wondered why React Native has its own layout engine, why reading a view's size used to be asynchronous, or why an animation stutters when the JavaScript thread is busy, this series answers all of it — by rebuilding the pipeline piece by piece.
Who This Series Is For
- Web developers who know React and want to understand what changes (and what doesn't) on native.
- React Native developers who can ship apps but want the mental model underneath — why the pieces are shaped the way they are.
- Anyone who read the browser series and wants to see the same problem solved in a very different world.
You should be comfortable with React (components, props, state, hooks). No C++ or native-platform experience is required — every low-level idea is motivated before it is named.
The Premise
In the browser, one engine gives you everything for free: a DOM to manipulate, a CSS engine to lay out, and a compositor to paint. On a phone there is no DOM, no CSS engine, and no browser — only the operating system's native views. So React Native had to build its own pipeline: its own host tree, its own layout engine, its own way of getting pixels on screen. That is the whole series.
The Route
Read it in order — each article builds on the one before. Seven parts, one connected path.
Part 1 — Why React Native Can't Just Reuse the Browser. React is a framework; a renderer connects it to a host platform. No DOM on a phone means RN had to build its own pipeline. This article sets the map for everything that follows.
Part 2 — The Bridge and Three Threads. The legacy architecture: JS, shadow, and UI threads joined by an asynchronous, serialized Bridge — and why layout was asynchronous.
Part 3 — JSI: Removing the Bridge. A small, engine-agnostic C++ layer lets JavaScript hold a live reference to a C++ object and call it directly. The foundation of the New Architecture.
Part 4 — The Shadow Tree. React Native's DOM: an immutable C++ host tree with structural sharing — and why immutability is what makes a concurrent renderer possible.
Part 5 — Yoga: Flexbox Without a Browser. A phone has no CSS engine, so RN built one: a C++ Flexbox engine. How styles become geometry, and why RN's Flexbox differs from CSS.
Part 6 — The Fabric Render Pipeline. The centerpiece: Render → Commit → Mount, across three threads over immutable revisions — the browser's style/layout/paint/composite, rebuilt.
Part 7 — Concurrency and Animation. The payoff: priorities, interruptible renders, synchronous layout reads, and moving per-frame animation off the JS thread — so updates feel instant.
The Mental Map
Two pictures are worth carrying the whole way through.
The three trees. Between your JSX and the screen there are three trees, and the renderer's job is to move information between them:
React Element Tree (JS, ephemeral)
│ commit (via JSI)
▼
Shadow Tree (C++, immutable, structurally shared)
│ layout (Yoga), then mount
▼
Host View Tree (real UIView / Android View)The browser ↔ React Native map. Every gift the browser gave you for free, RN had to build:
| Browser (for free) | React Native (built itself) |
|---|---|
| DOM | Shadow Tree (C++) |
| CSS + CSSOM | styles object + Yoga |
| layout engine | Yoga |
| paint + composite | mounting + the OS compositor |
| one main thread | three threads |
| synchronous DOM access | the Bridge — then JSI |
How to Read It
- Linear (recommended). Parts 1 → 7. The dependency chain is real: you cannot appreciate Fabric (Part 6) without the Shadow Tree (Part 4), Yoga (Part 5), and JSI (Part 3).
- In a hurry? Parts 4, 5, and 6 are the technical core; Parts 1–3 are the necessary setup.
- Coming from the browser series? You will recognize the shape of the argument everywhere. The two pipelines rhyme.
If you have not read the browser side yet, these two are the best companions:
Keywords: React Native, rendering, New Architecture, JSI, Fabric, Shadow Tree, Yoga, Flexbox, concurrency, animation, performance
