Clay Allsopp (twitter) (github) (medium) works at Palantir, where he uses React Native in Production. I loved this blog post, so naturally I had to spend my Sunday morning catching up with him and I'm so glad that I did! Usually I describe people's background here but since that's covered below, let's get on with it.
Your history: RubyMotion (BubbleWrap, FormMotion, PragProg book, etc), Propeller - according to sparse information I can find on the web now seemed to be a drag&drop tool to make mobile apps, and now Palantir (by means of acquisition) where you're using React Native. Is there anything that I'm missing or that you would like to elaborate on?
That sums it up - before Propeller, I worked at a social startup called LikeALittle, where I worked on Android and iOS apps, and before that I hacked on some small apps on my own
You have a lot of experience working on/with tools that aim to make the mobile development experience better so I'm really happy to get a chance to talk to you and get some insight :)
I think a lot of web developers understand at a surface level that native mobile apps take a lot of time and are pretty hard to do well. If you had to explain to a web developer what makes something like React Native valuable, how would you go about doing that?
That's a really good question.
So a question that comes up early when making a mobile app is "Do we use web views, or do we make this natively?" Using web views is tempting because the ecosystem around web development is enormous; there are probably more web engineers than any other platform, and I'd bet that will always be true.
So if you choose to use web views, your team can get started immediately with their current skills and tooling. The downside is that apps that use web views feel tangibly different, and sometimes worse for users, than apps made natively.
React Native removes this dichotomy by letting you leverage web technologies to build native apps. There's no more trade-off between development speed and quality.
From the end of your article: "It might have some limitations, and may not be the right tool for everything" - let's break this down into a few questions for you
1 - What would you say the limitations are? Which of these do you think are insurmountable or extremely difficult to solve using React Native's approach?
1 - I'm skeptical (but very interested) if you can build a heavily gesture-driven and fluid app like Paper with React Native. My gut is that you start hitting limits because of the asynchronous communication channel of React Native, and also the limitations of having one thread in JavaScript. You could probably do it if you were expertly skilled at both the iOS and React sides of things, but I don't know if you could do it only knowing React Native/JavaScript
I think that's what a lot of the "limitations" come down to, actually
You can probably do anything if you know both things very well, but I think the ceiling is lower if you come into it only knowing JavaScript and React
I think that's what a lot of the "limitations" come down to, actually you can probably do anything if you know both things very well, but I think the ceiling is lower if you come into it only knowing JavaScript and React
2 - What would you consider it to be the right tool for? And the wrong tool? As a kid I was a fan of mad libs (I mostly just filled the blanks in with silly answers), so I invite you to fill out my React Native version of it:
If I were to build --feature--, --feature-- or --feature--, I would not use React Native, I would use --name of a tool or technique--, because --reason--.
If I were to build --feature--, --other feature-- or --another feature--, I would definitely use React Native.
"If I were to build a feature that is heavy on text and image layouts, I would definitely use React Native." Doing non-trivial content layouts on iOS is a huge pain, there's no performance penalty for using React Native (you might even seen gains because the layout happens off the main thread), and it's more natural to express layouts with Flexbox than Auto Layout IMO.
So like "things that look like the Facebook Newsfeed" come to mind as a lot easier to build in React Native than the native APIs
And not really sure how to describe this, but features dealing with lots of API vs. client state are easier to reason about with a Flux-ful architecture than anything I've seen in the iOS ecosystem
"If I were to build a features involving charts, I would not use React Native." This hits close to home - we build an app involving data analysis, so naturally we tend to use charts, and those are actually much easier to render using web views. There's nothing quite like D3 in the iOS ecosystem, and I don't think you could easily re-implement it with React Native either.
But hey, maybe you could use the WebView React Native component to embed them!
I think a big barrier to that is that ReactNativeART doesn’t have built-in hit detection right now, so even if you use it for rendering a chart you will be limited in interactivity I agree that’s still a great use case for WebViews :)
If you were to rebuild the app that you mentioned in your "React Native In Production" post, knowing what you know now, what would your technology choices look like?
So right now our technology choices for the view layer are roughly 10% Objective-C, 60% Web Views, 30% React Native - I think a rebuild would look like 50% Web Views and 50% React Native.
We started the app before React Native was around, but if I started today all of the Objective-C views would be in React Native. There's a cost to splitting your app between so many different technologies, and consolidating those is something we're pushing towards.
We also think about the cost of having content in web views where it's not as performant (to the user) as doing it natively. There are some web views that are heavily chart based, and I don't see a future where we do those in React Native, but there are other views which are text/image layout-heavy and don't feel so slick in the web view. We're exploring moving those to React Native.
Is it just the chart views that you would leave in webviews, or are there others too?
Yeah, the limiting factor is the charts (which are implemented using Palantir's Plottable library http://plottablejs.org/)
Oh neat, I hadn’t heard of that library before it looks very clean and simple
Yeah, and it has a very component-centric way of thinking about the world, which makes it work well with the React mindset
Do you use the api described in the docs or do you wrap parts of your charts in React components? I could imagine actually having a renderTo function that could generate ReactART components :)
We basically use the technique describe here, which isolates the non-React code into another abstraction: http://blog.siftscience.com/blog/2015/4/6/d-threeact-how-sift-science-made-d3-react-besties
We've been playing around with a stronger integration with React, where like each Plottable component acts a normal React component, but haven't shipped anything yet
Are there any hard-earned lessons from the RubyMotion community that you think the React Native community could benefit from?
Definitely - personally, I learned the cost of using (and encouraging) leaky abstractions between the native APIs and "wrapping" them in Ruby APIs. For non-trivial APIs, consumers basically have to learn both implementations, which can be frustrating. There's a good talk which touches on the cost of using additional abstractions/APIs unnecessarily https://www.youtube.com/watch?v=4anAwXYqLG8
An example of this in the React Native world is something like NavigatorIOS, where there are lots of native APIs and it's unreasonable to expose them all via React Native.
I think the React Native team gets this concern, and has specifically designated the APIs they maintain/use (i.e. Navigator over NavigatorIOS). Providing community-maintained APIs, with that caveat, is a good way of helping out folks who really do want to use the wrapped API.
Well if you ever feel inspired to write a blog post about that I’d love to read it :)
That's a good idea :)
Are there any particular areas where you feel like React Native has let you down?
No, actually - it's lived up to the hype
If you had a month of the React Native team's time to work on anything you choose, what would you ask for?
Hm, nothing comes to mind, most of the problems we've had are entirely of our own creation :) The React Native team seems to be doing a great job on their own, so I'd let them do their thing.
Maybe some of the documentation could be improved, especially around like the props of each component, but no huge features or anything
Are there any particular components or APIs that you think need some love?
I've been poking around Navigator recently, and features I had to just look at example code (or read the source) to find out about, specifically around bar customization
I feel like Navigator is beefy enough that it needs its own tutorial or multiple documentation pages :)
Agreed, there is a bunch of work being done on improving Navigator right now so maybe after that settles I’ll try to improve that area of the documentation.
I saw this tweet today: https://twitter.com/dbanfield/status/640434966527123456 @dbanfield: Ow my head hurts from researching hybrid/native. Start to see where things are heading at least #ionic2 #angular2 #nativescript #reactnative
It seems like there are tons of options out there already and it’s pretty confusing for web developers who want to take the leap into mobile to choose what tool to go with. Where do you see this space converging? And what do you think is preventing React Native from being an obvious choice?
Unfortunately I don't know if I see it converging to one choice for everyone - it'll probably be somewhat fragmented, but with a popular leader. I hope the leader will eventually be React Native - React itself is the best way I've seen for wrangling UI development complexity, and that resonates with developers with or without mobile experience
I think what's stopped React Native from being that leader tomorrow is that it's not 1.0 yet (in terms of API stability), and not enough folks have shipped big apps with it yet. You want to be able to point to an app and say "That [popular app] is made with React Native" and have folks think "Whoa, I never would have known." I don't think that app is out yet, but hey, React Native is only a few months old
It’s been an absolute pleasure catching up with you this morning Clay! Do you have any shoutouts you’d like to make or any other comments?
Yeah it's been a great chat, really good questions :) Shout out to the folks at Palantir who have gotten excited about React Native even when it's in a relatively nascent state.
I'm super excited about React Native, folks can follow me @clayallsopp on Twitter if they want to see what's on my mind.