- 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
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
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
React Native and how it works
Pros of React Native
- Renders native views with native behaviour and interactions.
- Brings React’s architecture and concepts to native.
- 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:
Cons of React Native
- You will have more power and control – especially in terms of performance fine-tuning – when you write proper native apps.
- 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:
For web developers, View and Text are new, but once they know they are the equivalents of
<span> in the browser, they’re good to go. The JSX doesn’t use
<span> directly because
But wait, there’s another aspect to it.
Styling and layouting
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…
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 🙂
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.
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)
- “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.