Facebook open-sourced React Native this week, and the pitch is bold: write native mobile apps using JavaScript and React. Not hybrid apps like PhoneGap—actual native apps with native performance and native UI components.
This is ambitious. The question is whether JavaScript's "write once, run anywhere" promise finally delivers or disappoints again.
What React Native Actually Is
React Native isn't a webview wrapper. Your JavaScript code runs in a separate thread, communicating with native UI via a bridge:
import { View, Text, StyleSheet } from 'react-native';
const MyComponent = () => (
<View style={styles.container}>
<Text>This is a real iOS UILabel</Text>
</View>
);The <View> becomes UIView. The <Text> becomes UILabel. These are real native components, not DOM elements pretending to be native.
The JavaScript thread handles application logic. The native thread handles UI. They communicate asynchronously through a serializable message bus.
The Performance Claim
React Native claims native performance because it uses native components. Your JavaScript logic runs at JavaScript speed, but the UI is genuine native rendering.
Compare to hybrid apps where everything runs in a webview. Those are limited by browser rendering performance and can't match native smoothness.
The asynchronous bridge is the potential bottleneck. If your app frequently passes data between JavaScript and native, serialization overhead could hurt performance. But for typical apps, the bridge isn't the constraint.
The real test is production apps at scale. Facebook uses React Native in production (Groups app, Ads Manager). That's promising but not proof it works for everyone.
The "Learn Once, Write Anywhere" Philosophy
React Native doesn't promise "write once, run anywhere." It's "learn once, write anywhere"—same React concepts, platform-specific implementations:
// iOS
<ScrollView>
</ScrollView>
// Future Android (when supported)
<ScrollView>
</ScrollView>The component is the same, but behavior might differ per platform. You write platform-specific code when needed, but share logic and patterns.
This is more honest than hybrid frameworks that promise identical UIs on all platforms. Users expect platform conventions. React Native lets you respect those while reusing code.
The Developer Experience Bet
React Native's big innovation might be developer experience, not performance. Hot reloading, instant refresh, debugging with Chrome DevTools—these make mobile development feel like web development.
Native iOS development's compile-wait-run cycle is slow. React Native's instant feedback loop is addictive. This velocity might matter more than minor performance differences.
The Xcode dependence remains—you still need a Mac, still deal with provisioning profiles, still debug native code occasionally. But most development happens in JavaScript, which is more accessible.
The Ecosystem Question
React Native is days old. The ecosystem is minimal. Need a custom native module? You're writing Objective-C bridges. Need a third-party component? It probably doesn't exist yet.
This will improve if React Native gains adoption. But right now, you're pioneering. That's exciting for some, risky for others.
The React web ecosystem helps—concepts transfer, patterns work similarly. But mobile-specific components need building from scratch.
The Android Question
React Native currently supports only iOS. Android support is "coming soon." Without Android, it's incomplete for most companies.
The architecture should support Android—same bridge pattern, different native components. But "should work" and "does work" are different. Android's fragmentation might create complications iOS doesn't have.
Until Android ships, React Native is interesting but not practical for cross-platform needs.
When It Makes Sense
React Native might work well for:
- Teams with strong React/JavaScript skills, weak iOS skills
- Apps that are mostly standard UI components
- Rapid prototyping and iteration
- Companies willing to bet on early technology
It's risky for:
- Apps requiring custom native UI or performance
- Teams without JavaScript expertise
- Production apps that can't tolerate instability
- Companies requiring Android support now
The Comparison to Hybrid
PhoneGap/Cordova let you build mobile apps with web tech, but users can tell—performance lags, UI feels wrong. React Native promises to fix this with native components.
If React Native delivers native performance and platform-appropriate UI while keeping JavaScript development speed, it's a genuine alternative to native development.
If it doesn't—if the bridge creates lag, if platform differences create friction, if the ecosystem doesn't mature—it's another hybrid framework that promises too much.
Looking Forward
React Native represents Facebook's bet that JavaScript can be a serious application platform, not just a scripting language. React for web, React Native for mobile, potentially React for other platforms.
This vision—one component model, multiple targets—is compelling. Whether execution matches vision depends on adoption, ecosystem development, and discovering edge cases at scale.
For now, React Native is promising but unproven. Worth experimenting with, not betting the company on. If it succeeds, it changes mobile development significantly. If it fails, it's an interesting experiment.
The next year will tell which.
Resources:
- React Native – Official documentation
- React Native GitHub – Source code
- React Conf Videos – Introduction talks
