Create a gist now

Instantly share code, notes, and snippets.

@brentvatne /interview-4.md Secret
Last active Nov 17, 2015

What would you like to do?

React Native Newsletter - Community Interview #4

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.

Brent

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?

Clay

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

Brent

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?

Clay

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.

Brent

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?

Clay

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

Brent

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.

Clay

"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!

Brent

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?

Clay

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.

Brent

Is it just the chart views that you would leave in webviews, or are there others too?

Clay

Yeah, the limiting factor is the charts (which are implemented using Palantir's Plottable library http://plottablejs.org/)

Brent

Oh neat, I hadn’t heard of that library before it looks very clean and simple

Clay

Yeah, and it has a very component-centric way of thinking about the world, which makes it work well with the React mindset

Brent

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 :)

Clay

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

Brent

Are there any hard-earned lessons from the RubyMotion community that you think the React Native community could benefit from?

Clay

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.

Brent

Well if you ever feel inspired to write a blog post about that I’d love to read it :)

Clay

That's a good idea :)

Brent

Are there any particular areas where you feel like React Native has let you down?

Clay

No, actually - it's lived up to the hype

Brent

If you had a month of the React Native team's time to work on anything you choose, what would you ask for?

Clay

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

Brent

Are there any particular components or APIs that you think need some love?

Clay

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 :)

Brent

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.

Brent

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?

Clay

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

Brent

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?

Clay

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment