Introduction

React and React Native are two of the most widely adopted frameworks in modern software development, yet they are frequently misunderstood as interchangeable. While both share the same foundational philosophy — component-based architecture, unidirectional data flow, and a declarative programming model — they operate in fundamentally different environments and solve distinct rendering challenges.

React was built to render interactive user interfaces inside a web browser, working alongside the browser’s built-in Document Object Model (DOM). React Native, on the other hand, was designed to build genuine mobile applications for iOS and Android, where there is no DOM — only native platform views managed by the operating system.

This article breaks down exactly how each framework is architected under the hood, how their rendering pipelines work, and what that means for developers choosing between them.

What React and React Native Share

Before exploring their differences, it is worth understanding the common foundation both frameworks are built on:

• The React library itself — the same reconciler, component lifecycle, and hooks (useState, useEffect, useContext, etc.) work identically in both.
• JSX syntax — component templates are written in the same declarative JSX format.
• Unidirectional data flow — state flows down through props, and events bubble up, keeping UIs predictable.
• The component model — UI is composed of small, reusable, isolated components that manage their own state.

 

This shared foundation means that knowledge transfers well between web and mobile development. However, the rendering layer — the part that actually draws pixels on the screen — is completely different.

 

1. How React (Web) Works

React’s web architecture is built around the concept of a single-threaded JavaScript environment that communicates with the browser’s Document Object Model (DOM). Direct DOM manipulation is computationally expensive — querying or updating individual DOM nodes triggers browser layout recalculations and repaints. React solves this with a clever indirection layer called the Virtual DOM.

Key Components

Virtual DOM (VDOM)

The Virtual DOM is a lightweight, in-memory JavaScript representation of the real browser DOM. Instead of touching the actual DOM on every state change, React first computes what the updated UI should look like in this virtual tree — an operation that is orders of magnitude cheaper than real DOM operations.

Reconciler (Fiber)

The Fiber reconciler is React’s core diffing algorithm. When state changes, React creates a new Virtual DOM tree and runs a diffing process against the previous tree. Fiber compares the two trees node by node and computes the minimal set of changes required. Critically, Fiber supports concurrent rendering — it can pause, prioritise, and resume work, ensuring that high-priority updates (like user input) are never blocked by expensive background renders.

Renderer (React DOM)

React DOM is the platform-specific renderer for the web. It receives the computed change list from the Fiber reconciler and applies those changes to the real browser DOM in a single, batched commit — minimising reflows and repaints.

The React Web Rendering Flow

The rendering pipeline follows four distinct stages:

• State Change — A user interaction or asynchronous event triggers a state update via setState or a hook.
• Render Phase — React invokes the affected component functions, generating a new Virtual DOM tree. No DOM changes occur at this stage.
• Diffing — The Fiber reconciler compares the new VDOM tree with the previous one, computing the minimal list of required DOM mutations.
• Commit Phase — React DOM batches all computed mutations and flushes them to the real browser DOM in a single pass, triggering a browser repaint.

 

2. How React Native (Mobile) Works

Mobile platforms have no concept of a DOM. iOS and Android render their UIs through native view hierarchies — UIView and CALayer on iOS, and android.view.View on Android. React Native’s job is to allow JavaScript to drive these native views without compromising on performance or the native look and feel.

React Native has undergone a significant architectural evolution. The original “Bridge” architecture — which serialised all JavaScript-to-native communication into asynchronous JSON messages — introduced noticeable latency and was the root cause of many performance issues (dropped frames during heavy scrolling, delayed touch responses, and layout jank). The modern architecture replaces the Bridge entirely.

The Modern Architecture (New Architecture)

The New Architecture, which is now the default in React Native 0.74+, is built around a single foundational concept: JavaScript and native code can communicate directly and synchronously through a shared C++ layer, without serialising data to JSON.

Hermes — The JavaScript Engine

Hermes is a lightweight JavaScript engine built by Meta specifically for React Native. Unlike general-purpose engines like V8 or SpiderMonkey, Hermes is optimised for mobile constraints. Its most impactful feature is Ahead-of-Time (AOT) bytecode compilation: JavaScript is compiled to bytecode at build time rather than at runtime, which dramatically reduces time-to-interactive and lowers memory consumption on lower-end devices.

JSI — JavaScript Interface

JSI (JavaScript Interface) is a lightweight C++ abstraction layer that serves as the backbone of the New Architecture. It exposes C++ host objects directly to the JavaScript runtime, allowing JavaScript to hold real references to native objects and invoke native methods synchronously — exactly as if calling any regular JavaScript function. This eliminates the serialisation overhead of the old Bridge and enables a new class of performance-sensitive interactions.

Fabric — The New Rendering Engine

Fabric is React Native’s modern rendering system. It replaces the old UIManager and connects the React reconciler directly to the native view hierarchy via JSI. Fabric supports concurrent rendering (consistent with React 18’s model) and enables synchronous UI measurement — permanently resolving the layout jank and “blank flash” issues that plagued the Bridge architecture during complex scroll interactions.

TurboModules — Lazy-Loaded Native APIs

TurboModules replace the old NativeModules system. Previously, every native capability (camera, Bluetooth, file storage, etc.) was initialised at app startup regardless of whether it was needed. TurboModules are lazily loaded — they are instantiated on demand, the first time JavaScript actually requests them. This alone can reduce app cold-start time significantly, particularly for large applications with many native dependencies.

Yoga — The Layout Engine

Yoga is a cross-platform C++ layout engine developed by Meta that implements a subset of CSS Flexbox. Because mobile platforms do not have a CSS engine, Yoga acts as the bridge between React Native’s style props and the native constraint-based layout systems of iOS and Android. Yoga calculates the position and dimensions of every view and passes those values to the native rendering layer.

The React Native Rendering Flow

The modern rendering pipeline works as follows:

• State Change — A state update is triggered in a React Native component.
• React Reconciliation — The Fiber reconciler computes what the updated component tree should look like, producing a list of UI mutations (identical to the web).
• Fabric Shadow Tree — Fabric creates an immutable C++ “shadow tree” representing the updated view hierarchy.
• Yoga Layout — Yoga calculates the exact position and size of every view in the shadow tree.
• Native Commit — Fabric sends the computed layout directly to the native platform via JSI, commanding iOS/Android to create, update, or destroy native views.
• Platform Rendering — The mobile OS renders native UIViews (iOS) or Android Views — real, first-class platform UI components, indistinguishable from those in apps built with Swift or Kotlin.

 

Side-by-Side Comparison

The table below summarises the key architectural differences between the two frameworks:

 

Feature	React (Web)	React Native (Mobile)
Runtime Environment	Browser JS engine (V8, JavaScriptCore, SpiderMonkey)	Hermes — AOT-compiled, mobile-optimised JS engine
Target Output	HTML & CSS rendered in the browser DOM	Native platform views (UIView on iOS, android.view on Android)
UI Rendering Engine	React DOM — manipulates the browser DOM	Fabric — directly commands native OS views via JSI
Communication Layer	Direct JS execution on browser main thread	JSI — synchronous C++ bridge between JS and native
Layout Engine	Browser CSS Flexbox engine	Yoga — C++ Flexbox implementation
Virtual DOM	In-memory VDOM diffed against real DOM	Shadow tree (C++) diffed against native view tree
Native Module Access	Browser Web APIs (fetch, localStorage, etc.)	TurboModules — lazily loaded native capability modules
Styling	Full CSS (including animations, media queries, grid)	Flexbox subset via StyleSheet API — no CSS cascade
Concurrent Rendering	Yes (React 18+ with React DOM)	Yes (React 18+ with Fabric)

 

When to Use Each

Choosing between React and React Native is not a question of which is superior — it is entirely determined by your target platform.

Choose React (Web) when:

• Your primary target is a web browser, across desktop and mobile browsers.
• You need access to the full web platform (SEO, URLs, browser history, CSS animations, Web APIs).
• You are building a Progressive Web App (PWA) or a server-rendered application with Next.js.
• Your team has strong CSS and web development expertise.

Choose React Native when:

• You need a true native mobile app for iOS and/or Android — not a web view.
• You want access to native device capabilities: camera, biometrics, Bluetooth, push notifications, sensors.
• App performance and a native user experience are critical requirements.
• You want to share business logic (API calls, state management, validation) across both platforms while keeping platform-specific UIs.

 

Summary

React and React Native are best understood not as competing frameworks, but as the same core idea — declarative, component-based UI — applied to two completely different rendering substrates.

React Web runs your JavaScript in the browser, produces Virtual DOM diffs, and asks the browser’s own rendering engine to update HTML and CSS. The browser handles all the hard work of painting pixels.

React Native runs your JavaScript on an isolated, AOT-compiled engine (Hermes), uses a C++ Flexbox engine (Yoga) to calculate layouts, and commands the mobile operating system — via a direct C++ interface (JSI) — to create and update genuine native views. The result is an application that looks and performs like one written in Swift or Kotlin, while sharing the same React component model you already know.

Understanding this distinction is the foundation for making informed architectural decisions, diagnosing performance issues, and writing code that leverages the strengths of each platform effectively.