TL;DR
- React Native lets you build native apps with JavaScript and React without using WebViews and without a compilation step.
- Not “write once run anywhere” but “learn once, write anywhere”. If you know React, you can now build native apps, but not with the exact same code for all platforms.
- Same development experience as for web apps: no compilation step, changes appear instantly.
- To be released soon; already in production use in Facebook Groups on iOS
Introduction
The big news of last week’s React.js Conf was the announcement of React Native, Facebook’s soon-to-be-released open-source solution for building native iOS and Android apps with React. In this post, I will give a brief overview of what we know so far about React Native and the promises it offers.
Here’s Tom Occhino‘s original keynote from React.js Conf 2015 announcing React Native:
Traditional Hybrid Mobile Applications
React Native is a new solution for writing hybrid web apps – with a twist. There are two kinds of traditional hybrid apps:
1. WebView app
The first kind wraps your app’s HTML, CSS, and JavaScript code in a native app container that runs a WebView, a very lightweight browser. Phonegap and Apache Cordova are the most common solutions for packaging such apps and there are special frameworks to recreate native UI elements and interactions in HTML, such as jQuery Mobile, ionic, Sencha Touch, or Kendo UI. When the app is opened, a WebView gets initialised and your code gets executed on it. The advantage of these apps is that they can use the exact same code as your web app. In practice, however, you’ll be aiming to emulate a native look and feel, which means different code than you desktop UI and different code for iOS and Android – this is why the use of mobile UI frameworks is so common. The problem with WebView apps is that their interactions never quite feel like native apps. They’re usually slower and, according to the Facebook team, their attempts of rebuilding touch interactions in HTML5 never came close. Furthermore there’s some stuff you simply cannot do in a WebView that you can do in a native app – e.g. controlling certain hardware features.
Facebook has a history with WebView apps. In 2012 they rewrote their WebView hybrid app and replaced it with native apps. Zuckerberg called betting on HTML5 their biggest mistake. Others pronounced the web dead: Is the web really dead?.
The Sencha Touch team’s reaction was to rebuild Facebook’s native iOS app in HTML5: The Making of Fastbook: An HTML5 Love Story.
2. Compiled hybrid app
Solutions like Xamarin (C# to native code) or older versions of Appcelerator Titanium (!? see note below) take another approach. Instead of loading a bare-bone browser to run you HTML and JavaScript, they compile your code to native code so they can render directly to native views. Apps written this way have a more native feel since styling and behaviour doesn’t have to be rebuilt in HTML.
React Native and how it works
Apps written with React Native fall neither in the first nor the second category, but remain hybrid apps written in JavaScript and HTML that can be downloaded from the app store.
Like compiled native apps, React Native uses native views. You get the same platform-specific look and feel on Android and iOS that proper native apps offer (those written in Objective-C or Java). There is, however, no compile step involved. Similar to WebView apps, React Native requires an extra component to work, but instead of a WebView, that’s just a JavaScript runtime (JavaScriptCore on iOS).
Applications built with React Native use a special XCode/Android SDK container. When you load them, they feed your React code (JavaScript) to a JavaScript runtime that asynchronously communicates with a native thread (main thread). Asynchronicity is very important for performance but also means complex synchronous tasks in JavaScript are a no-no.
Pros of React Native
- Renders native views with native behaviour and interactions.
- “Learn once, write anywhere”; developers only need to know React and JavaScript to write apps for the web, Android, and iOS.
- Brings React’s architecture and concepts to native.
- Requires no WebView; the JavaScript runtime React Native uses is much smaller.
- There’s no compilation step – much better development experience and speed: you can build native apps like you develop web apps.
- Is already being used in production: Facebook Groups on iOS.
React Native development experience demo:
(Source: https://twitter.com/ryanflorence/status/561342337461125121)
Cons of React Native
- Dependent on API that React Native provides. You can only call native classes and methods (Objective C on iOS or Java on Android) from your React code (JavaScript) that are supported by React Native. You’re leaving the pastures of the open standards web.
- You will have more power and control – especially in terms of performance fine-tuning – when you write proper native apps.
- Requires a JavaScript runtime that pure native apps don’t need.
- Hasn’t been released yet 🙂 – but is coming in the next couple of weeks.
Most cons are negligible in light of React Native greatly empowering web developers to write native apps.
Learn once, write anywhere
React Native doesn’t aim to be cross-platform with one codebase. The React team believes “Write once run anywhere” is a pipe dream – or requires too many compromises. Here’s a snippet of JSX markup (React’s templating language) for React Native:
<View>
<Text numberOfLines={2}>
{this.props.movie.title}
</Text>
</View>
For web developers, View and Text are new, but once they know they are the equivalents of <div> and <span> in the browser, they’re good to go. The JSX doesn’t use <div> and <span> directly because <View> becomes a UIView on iOS and a View on Android. You may be dealing with similar entities but the native world is different from the browser and we should hence use different names in JSX as well. You’d have different JSX markup for each platform you target, but the JavaScript with your business logic will be shared. Furthermore, your code will be React all around, with the same structure, components, and best practices you know from the web. So once you know React, as soon as React Native’s been released you can not only write web apps but also native apps – this is what’s meant by “learn once, write anywhere”.
But wait, there’s another aspect to it.
Styling and layouting
In day 2’s keynote from React.js Conf, Christopher Chedeau demoed React Native and showed some implementation details. Being able to develop native apps in JavaScript with the comforts of React is one thing, but styling is another. WebView apps will render your markup and CSS just like a browser. With native views we don’t have that pleasure.
Luckily for us, the React team has reimplemented flexbox in JavaScript. Many reactions to React Native complain that this is a step in the wrong direction and that they should rather have implemented a constraint solver like GSS (Grid Style Sheets) (also known as Cassowary). Pete Hunt says he considered GSS and had a lengthy chat with the maintainer but decided against it because constraint solvers aren’t deterministic. He doesn’t look back and is happy with flexbox. Also see this brief Twitter discussion.
Conclusion
To sum up, React Native offers web developers a very promising new way to write native apps using technology they’re already familiar with – HTML, CSS, and JavaScript as the base and React as the architecture and library behind their cross-platform apps.
As usual when big announcements like this are made – especially when they’re coming from big, marketing-savvy companies like Facebook – we have to be cautious not to get overexcited and blindly hype whatever is the new tool du jour. The demos presented of React Native were simple but convincingly showed how to write native apps with code that doesn’t deviate much from normal React code. Although parts of Facebook Groups on iOS have been written with it, React Native remains alpha software that hasn’t been released yet. The reason it has only been made available to React.js Conf attendees is that it’s not ready yet.
Sadly still only private – but it’s good to see it exists:
If Ember had announced this…
When I imagine that the Ember team had just announced Ember Native, I’d have called them bonkers and yet here I am all excited about React Native. Why the difference I’m asking myself?
I have to digress and rant a bit about Ember, but I hope it helps you to see what makes React so special. It’s easier picking on a concrete target than talking in the abstract. Let me be absolved for ranting by telling you up-front about Alex Matchneer‘s much more informed and objective comparison of React and Ember: Ember.setState(this.get(React)).
“JS was crawling. jQuery was walking. Ember was taking the bus. @reactjs is like taking a private GulfStream and getting off into a R.Royce”
(@MattStopa on Twitter)
Note that you’re only taking, not driving the bus…
My general problem with Ember is that it’s a framework (“your code calls a library, a framework calls your code”) and the incredible lengths they have to go to to offer a development experience and architecture in the vein of Ruby on Rails (not that that didn’t take a while to build) in client-side JavaScript.
I tried getting into Ember when it was still known as Amber, then about 6 months later, and again another 6 months later or so. It never warmed up to me and the frustrations were always the same. Some stuff worked great, other stuff wasn’t even documented, poorly documented, had outdated documentation, or simply didn’t play well with all the other stuff I needed to run my app (an inflector!?). I’ve been told the documentation has gotten a lot better, but I’ve lost the motivation to play around with Ember.
What I took from those days, however, was a metaphor: a community trying to build the entirety of Rome all at once and without getting even the city centre in usable shape. I know this is harsh and highly subjective and probably only because I had a lot of bad luck with Ember, but this is the image that stuck – especially after this announcement. When David Nolen tells the Alan Kay analogy of building pyramids in software I’m a little reminded of Ember. Of course there’s also elegance in Ember and the team’s really clever – react-router was heavily inspired by Ember.
I wouldn’t believe in a native solution coming from a project like Ember. It’d feel like they were drawing a couple new city districts to-be on their drawing boards – and they already have to build the districts of HTMLBars, Ember Data, Ember CLI, EmberScript, and God knows what I haven’t heard about since I stopped following – all to offer the best possible programmer convenience “for creating ambitious web applications”. I’m glad that Ember exists and there are many great people behind it. It’s just that I for one find it hard believing in the Ember way.
Why believe in React Native then? Different town to build, different new district, but with the same problems!? Somehow React is different. Simpler to the core and a lot more elegant. More like building arches (with a nice picture of Cologne Cathedral, by the way). Where the Ember project seems to lose itself in a complex sprawl of bloaty intertangled parts (“Oh that doesn’t work because the documentation is out of date. Ah, now you need to update Ember Data to the latest beta, ah now add this undocumented feature…”) React shines with true simplicity. I can’t go into depth here, but “Removing User Interface Complexity, or Why React is Awesome” by James Long is a great starting point.
At first, Ember may be easy and convenient to use, but that doesn’t make it simple under the hood and you will feel the pain later when you have to fight against the framework. Simple ain’t easy.
I don’t think adding a new district to Reactopolis by starting React Native is gonna distract or slow down the React team very much.
And that isn’t just because a big company like Facebook is behind it. Of course it takes a lot of man power to build something like that. React’s advantage is less entanglement between all the stuff people build around it. Rich Hickey reminds us that complexity is about entwining.
But React proper won’t lose steam or gain a lot of complexity because of React Native. It’s rather an advantage that will help making its design even cleaner and more modular.
React became famous as “the V in MVC” but it seems like this label’s more and more missing the point.
‘React is the V’ just like my iPhone is just a phone. #reactjsconf @_chenglou on Twitter)
The Virtual DOM was just the first obvious revolutionary thing we got out of it. We’re only beginning to discover the possibilities React offers: its simplicity, its closeness to functional programming and the amazing things that brings with it – e.g. immutable data structures and amazing stuff like undo in 13 lines of code –, and so much more.
We’re in good company on this journey of discovery – even people like David Nolen initially wrote React off. Together we’re slowly realizing the promise and power of React.
These are truly exciting times – to get into React 🙂
Feedback
I hope you enjoyed this post. Please let me know what you thought by either sending me an email to [email protected] or by contacting me via Twitter: @wakkahari.
More stuff I wrote
- My Way into Clojure: Building a Card Game with Om – Part 1 – Om is a ClojureScript library built on top of React.
- React & Om – Slides from my Cologne.js talk.
- Alien Technology: Ideas from the Clojureverse
A Breakneck Journey through Functional Programming, LISP, Clojure(Script), Om, and React. – A talk I gave at last year’s Railscamp Germany.
I’m a little confused about the current state of affairs in Titanium – and I’m not the only one (more). My understanding is that the old Titanium Alloy used to have a compiler, then came Ti.next, which uses a JavaScript runtime as well, and which is what we have today!?!
More information on the differences between Titanium and React Native: HackerNews comment
Parts of the Appcelerator community were .. saddened .. by the release of React Native: http://www.tidev.io/2015/01/30/reacting-to-react-native
The people behind React
- Jordan Walke: original React developer.
- Pete Hunt: React’s “social media guy”, recently left Instagram/Facebook to found his own startup.
- Christopher Chedeau: React developer, reimplemented flexbox for React Native
- Jing Chen React & Flux engineer
- Bill Fisher React & Flux engineer
- Tom Occhino React project manager
Sources & Further Reading
- Adam Ernst’s presentations on the ideas behind React Native (source: https://twitter.com/Vjeux/status/562039379556712448)
Hybrid Apps
- “Four Ways To Build A Mobile Application”: Part 1: Native iOS – Part 2: Native Android – Part 3: PhoneGap – Part 4: Appcelerator Titanium
Title Image: “Meteorology research vehicle”. OSU Special Collections & Archives. https://www.flickr.com/photos/osucommons/6258266117.
