🧠 Web vs Native Mental Models

No DOM, No Browser, No CSS

Here's the biggest mental shift you need to make: React Native doesn't run in a browser. There's no DOM. There's no window object. There's no document. The entire web platform you've been building on? It doesn't exist here.

Think of it like this: as a web developer, you've been building houses using a specific construction method — wood framing, drywall, the works. React Native is asking you to build houses using a completely different method — maybe steel and concrete. The end result is still a house, but the materials and techniques are different.

Wait, Then How Do We Style Things?

Instead of CSS, React Native uses JavaScript objects that look CSS-ish but follow different rules. Here's a taste:

// ❌ This is NOT how React Native works
import './styles.css';

function Card() {
  return <div className="card">Hello</div>;
}


// ✅ This IS how React Native works
import { View, Text, StyleSheet } from 'react-native';

function Card() {
  return (
    <View style={styles.card}>
      <Text>Hello</Text>
    </View>
  );
}

const styles = StyleSheet.create({
  card: {
    backgroundColor: '#fff',      // camelCase, not kebab-case
    padding: 16,                  // numbers, not '16px'
    borderRadius: 8,
    shadowColor: '#000',          // shadows work differently
    shadowOffset: { width: 0, height: 2 },
    shadowOpacity: 0.1,
    shadowRadius: 4,
    elevation: 3,                 // Android-specific shadow
  },
});

Notice the differences? Properties are camelCase (backgroundColor not background-color). Values are numbers, not strings with units. And there's no CSS cascade — styles don't flow down to children the way they do on the web.

The Architecture Difference

Web React runs in a browser with DOM; React Native runs directly on the device with native UI

Native Components vs HTML Elements

In React for web, you use HTML elements: <div>, <span>, <p>, <img>, <input>. In React Native, you use native components that map to real platform widgets.

Think of it like language translation. "Hello" in English becomes "Hola" in Spanish — same meaning, different expression. <div> in web becomes <View> in React Native — same concept (a container), different implementation.

The Translation Table

The Cardinal Rule: Text Must Be in Text

This trips up every web developer at first. In HTML, you can put text anywhere:

<!-- ✅ Web: This is fine -->
<div>Hello World</div>
<span>Some text</span>

In React Native, all text must be wrapped in a Text component:

// ❌ React Native: This will CRASH
<View>Hello World</View>

// ✅ React Native: This is correct
<View>
  <Text>Hello World</Text>
</View>

A Side-by-Side Example

Let's build a simple card component in both React (web) and React Native:

// 🌐 React for Web
function ProfileCard({ name, role, avatar }) {
  return (
    <div className="card">
      <img src={avatar} alt={name} className="avatar" />
      <div className="info">
        <h2>{name}</h2>
        <p>{role}</p>
      </div>
      <button onClick={() => alert('Followed!')}>
        Follow
      </button>
    </div>
  );
}

// 📱 React Native
import { View, Text, Image, Pressable, StyleSheet } from 'react-native';

function ProfileCard({ name, role, avatar }) {
  return (
    <View style={styles.card}>
      <Image source={{ uri: avatar }} style={styles.avatar} />
      <View style={styles.info}>
        <Text style={styles.name}>{name}</Text>
        <Text style={styles.role}>{role}</Text>
      </View>
      <Pressable 
        style={styles.button}
        onPress={() => Alert.alert('Followed!')}
      >
        <Text style={styles.buttonText}>Follow</Text>
      </Pressable>
    </View>
  );
}

const styles = StyleSheet.create({
  card: { flexDirection: 'row', padding: 16, backgroundColor: '#fff' },
  avatar: { width: 60, height: 60, borderRadius: 30 },
  info: { flex: 1, marginLeft: 12 },
  name: { fontSize: 18, fontWeight: 'bold' },
  role: { fontSize: 14, color: '#666' },
  button: { backgroundColor: '#3b82f6', padding: 8, borderRadius: 4 },
  buttonText: { color: '#fff', fontWeight: '600' },
});

See the pattern? The structure is similar, but the building blocks are different. And notice how every piece of text is wrapped in <Text>, including the button label.

The Bridge Architecture

Here's something important to understand: your JavaScript code and the native UI run in separate worlds. They communicate through what's called the "bridge."

Imagine you're in a restaurant kitchen (JavaScript) and need to serve food to customers in the dining room (native UI). You can't walk out there yourself — you have to put plates on a conveyor belt (the bridge) that carries them to the other side. The waiter (native side) picks them up and serves them.

flowchart LR
    subgraph JS["JavaScript Thread"]
        A[Your React Code] --> B[React Native Runtime]
    end
    
    subgraph Bridge["Bridge"]
        C[JSON Messages]
    end
    
    subgraph Native["Native Thread"]
        D[Native Modules]
        E[UI Manager]
    end
    
    B <--> C
    C <--> D
    C <--> E
    
    E --> F[("📱 Screen")]
    
    style JS fill:#fff3e0,stroke:#ff9800
    style Bridge fill:#e3f2fd,stroke:#1976d2
    style Native fill:#e8f5e9,stroke:#388e3c
                

The classic bridge architecture (being replaced by the New Architecture)

Why This Matters to You

In practice, you rarely think about the bridge directly. But understanding it explains a few things:

• Animations can feel janky if they go through the bridge on every frame (60 times per second!). That's why React Native has special animation APIs that run on the native side.
• Gestures need special handling — you can't just use mouse events. Touch gestures are native, so there are dedicated gesture libraries.
• Some operations are async when you'd expect them to be sync. Reading dimensions, for example, requires a round-trip through the bridge.

What Runs Where?

flowchart TB
    subgraph JSThread["JavaScript Thread"]
        A["Your Components"]
        B["Business Logic"]
        C["State Management"]
        D["API Calls"]
    end
    
    subgraph UIThread["UI/Main Thread"]
        E["Layout Calculation"]
        F["Rendering"]
        G["Touch Handling"]
        H["Animations*"]
    end
    
    subgraph BGThreads["Background Threads"]
        I["Image Decoding"]
        J["Network Requests"]
        K["Native Modules"]
    end
    
    JSThread <--> UIThread
    UIThread <--> BGThreads
    
    style JSThread fill:#fff3e0,stroke:#ff9800
    style UIThread fill:#e8f5e9,stroke:#388e3c
    style BGThreads fill:#e3f2fd,stroke:#1976d2
                

*With Reanimated, animations run entirely on the UI thread for smooth 60fps

Platform Differences: iOS vs Android

React Native gives you one codebase, but it doesn't give you one platform. iOS and Android are different operating systems with different design languages, different capabilities, and different user expectations.

Think of it like writing a book that will be translated into French and Japanese. The story is the same, but some phrases need to be adapted for cultural context. Similarly, your app logic stays the same, but some UI details need platform-specific treatment.

iOS and Android have distinct design languages and user expectations

How React Native Handles Platform Differences

React Native gives you several tools for platform-specific code:

import { Platform, StyleSheet } from 'react-native';

// 1. Platform.OS - simple checks
if (Platform.OS === 'ios') {
  // iOS-specific code
}

// 2. Platform.select - inline conditional
const styles = StyleSheet.create({
  container: {
    ...Platform.select({
      ios: {
        shadowColor: '#000',
        shadowOffset: { width: 0, height: 2 },
        shadowOpacity: 0.1,
        shadowRadius: 4,
      },
      android: {
        elevation: 4,
      },
    }),
  },
});

// 3. Platform-specific files
// MyComponent.ios.js   ← Used on iOS
// MyComponent.android.js ← Used on Android
// Import just says: import MyComponent from './MyComponent';

Key Differences to Know

Performance Expectations and Realities

Let's address the elephant in the room: Is React Native fast enough?

The short answer: Yes, for the vast majority of apps.

The longer answer: React Native performance has improved dramatically, especially with the New Architecture. For standard app features — lists, forms, navigation, API calls, images — React Native is indistinguishable from native. Users cannot tell the difference.

Where Performance Matters

flowchart LR
    subgraph Excellent["Excellent Performance"]
        A["Forms & Inputs"]
        B["Navigation"]
        C["API Integration"]
        D["Standard Lists"]
    end
    
    subgraph Good["Good Performance (with optimization)"]
        E["Complex Lists"]
        F["Animations"]
        G["Image-Heavy Screens"]
        H["Real-time Updates"]
    end
    
    subgraph Challenging["Challenging"]
        I["3D Graphics"]
        J["Video Editing"]
        K["AR/VR"]
        L["Audio Processing"]
    end
    
    style Excellent fill:#e8f5e9,stroke:#388e3c
    style Good fill:#fff3e0,stroke:#ff9800
    style Challenging fill:#ffebee,stroke:#c62828
                

Performance characteristics by feature type

Common Performance Myths

Realistic Expectations

The key insight: performance problems in React Native are almost always solvable. There's usually a right way to do things (memoization, virtualized lists, native-driver animations) that brings performance to native levels. This course will teach you those patterns.

Summary

🚀 What's Next?

Now that you understand what's different between web and native, let's flip the script and look at what stays the same. In the next lesson, we'll explore everything that transfers directly from your React knowledge — and it's a lot more than you might think!