What Is React Native? — Drawing With React, but Not on the Web
React Native is not a hybrid app wrapped in a WebView. Starting from the idea that React's way of thinking stays put while only the 'what to draw' changes, we map out what React Native actually is — and where the web ends.
In the「React Fundamentals」series we learned to declare a screen as a function of state, and to assemble that screen out of components. Once that feeling settles into your hands, one question follows naturally: “So what about apps?”
React Native is the answer to that question. But the name buys it a lot of misunderstanding. “Isn’t it just the web dressed up as an app?” “Isn’t there a WebView in there somewhere?” — that talk is still circulating, and older write-ups still say exactly that. So this first post isn’t about how to build something. It’s about pinning down what React Native actually is.
React doesn’t know how to draw a screen
That sounds odd, but it’s true: React itself knows nothing about the DOM.
In Part 1 we said the JSX a component returns isn’t a screen — it’s a blueprint of what the screen should look like. Taking that blueprint and turning it into an actual screen is the job of something else entirely: a renderer. On the web, that job belonged to react-dom, the package we always installed alongside React.
// Web: react-dom turns the blueprint into real DOM nodes
import { createRoot } from 'react-dom/client';Which invites an idea. If the side that makes the blueprint (React) is separate from the side that draws it (the renderer), couldn’t we just swap out the drawing side? Build a renderer that paints native iOS and Android UI instead of the DOM, and the screens you declared in React become the screens of a mobile app.
That’s React Native. It is not a React-flavored imitation of React — it is the same React with a different renderer plugged in. That sentence is the premise of this entire series. Every component, prop, piece of state, useEffect, and Context you already know carries over intact.
It is not a WebView hybrid
Let’s cut off the most common misunderstanding right away. React Native does not render your screen inside a WebView.
The confusion exists because a genuinely different approach does exist under similar branding. Cordova and Ionic-style tools open a browser view inside an app shell and render HTML in it. That’s what “hybrid app” means, and that’s why the “it’s really just the web inside” complaint attaches to them.
React Native is not that. When you write <View>, it becomes a real native view object — a UIView on iOS, an android.view.ViewGroup on Android. <Text> becomes the platform’s actual text view; scrolling is handled by the scroll view that platform has always used. The button on screen isn’t a browser’s imitation of a button. It’s the one the OS drew.
Which is why a React Native app has no div, no span, no HTML, and no CSS file. Web technology wasn’t smuggled inside the app. Only React’s way of thinking made the trip; the materials are all native.
So how do JavaScript and native talk to each other?
Our component code is JavaScript. The thing actually drawing the screen is native. Something has to connect them.
Older React Native called that connection the Bridge. The JavaScript side and the native side couldn’t call each other directly; they serialized messages into JSON, put them on a queue, and passed them across asynchronously. It was closer to dropping a letter in a mailbox and waiting for a reply — and when the messages piled up, the screen answered a beat late. When you see an old article saying “React Native communicates over a bridge,” you’re reading a relic of that era.
Not anymore. The structure was replaced by what’s called the New Architecture, and it has been the default since version 0.76. Three names are enough:
- JSI (JavaScript Interface) — the layer that lets JavaScript call native objects directly. Less mailing a letter, more picking up the phone. This is the space where the mailbox used to sit.
- Fabric — the new rendering system. Layout calculation and screen updates are far more tightly coupled than before, which removes a class of timing problems like flicker during scrolling.
- TurboModules — native capability modules (camera, location, and friends) are loaded when needed rather than all hoisted at app startup. The app opens faster.
You don’t need the internals of any of the three right now. What you do need is to drop the stale impression that “JavaScript reaches native slowly, by detour.” In practice, the performance problems you’ll actually hit come not from this channel but from drawing lists badly — which is what post 5 is for.
What stays, what changes
For someone who already knows React, the most useful map is the one that shows which ground is already familiar.
Unchanged — assembling screens out of components, JSX syntax, passing values down through props, holding state with useState and triggering re-renders, useEffect, useRef, Context, and the npm ecosystem. Nothing you learned in Part 1 goes to waste.
What changes is precisely the material the screen is made of.
| Web | React Native |
|---|---|
div, span, p | View, Text |
| CSS files, classes | StyleSheet (a JavaScript object) |
| URLs and routers | Navigation (a screen stack) |
onClick | onPress |
| Browser APIs | Native APIs + permission requests |
Two tripwires are worth naming in advance, because nearly everyone catches a foot on them. First, every piece of text must live inside a <Text>. Writing <View>some words</View>, web-style, is an error. Second, styles don’t cascade, and Flexbox’s default axis is vertical, not horizontal. Bring your web habits over unchanged and the layout will almost certainly come out wrong. Posts 3 and 4 take these on properly.
The honest trade-off
“One codebase, two platforms” is true. It does not mean “you never have to know anything about native.”
Build an app for a while and the differences between iOS and Android come find you. Permission flows differ. A hardware back button exists on one and not the other. Dodging the notch at the top and the home indicator at the bottom works differently. React Native doesn’t erase those differences — it hands you a handle for dealing with them. And now and then, no library exists for what you need, and you’ll be wiring up a native module yourself.
Even so, it’s often the right call. You write most of your screens and business logic once, you reuse the React knowledge your team already has, and you get a development loop where an edit shows up in the app almost immediately. But if you’re building something driven by heavy graphics, or you need each platform’s newest capabilities the day they ship, native may still be the honest answer. A tool isn’t universal; it just has places where it fits.
Where we’re going
Three sentences, then. React’s way of thinking carries over untouched. The screen is drawn with real native views, not a WebView. But the DOM and CSS as materials are left behind, and new ones take their place.
Next time we’ll set up a development environment with Expo and get a first screen running on a real device. After that: native components, StyleSheet and Flexbox, lists and touch, navigation, platform APIs, and shipping to the stores. You learned React with a screen in front of you — this time, let’s draw the one that lives in your pocket.