
Introducing Create React Native App - anp
https://facebook.github.io/react-native/blog/2017/03/13/introducing-create-react-native-app.html
======
hasenj
I started a project in React Native a few months ago, then I left it for a
couple weeks, then when I came back to it, I did the usual chore of updating
libraries, and found that I could no longer compile/run the project. Purged
and re created my npm_modules folder to no avail. Things kept getting worse
and I simply have no clue what is going on. Started a fresh RN project and
even that would not run.

I got the feeling that it's layers upon layers of leaky abstractions and the
whole thing seems rather fragile.

~~~
lohengramm
I felt that way using React itself (for the web) - it was like writing code
upon so many layers I didn't have control to fix eventual hairy bugs anymore.
So I didn't even try Native.

~~~
spicyj
Were you using many other libraries? We try to keep React itself pretty simple
and recommend you start with that.

~~~
lohengramm
I am probably blaming React for more than it's responsible for, but I feel
that, in a real world project, it's rather difficult to not fall into that
zone where you have webpack, several loaders and complex configurations for
different environments, babel with plugins/presets, gulp, redux or something
equivalent, strange directory structures because all libraries purposely try
to avoid being associated with bad old big frameworks thus giving too much
freedom for the programmer to be "creative" when organizing his code, node for
SSR (and then taking care for everything to also work on the server), css
modules, react wrappers crashing because wrapped libs were originally written
with dom manipulation in mind etc. You know the list can go on, the last time
I remember my package.json had around 50 direct dependencies, and it is
possible to justify every one of them. All that to write magic JS code that
imports assets, transforms them, output obscure css classes and a client.js
file that eventually print some crazy warnings on line 53777 column 838383937.

I know I am just complaining like a grouchy old man and not really helping
understand and solve the problem, but that's what I can do right now. I would
say that maybe we are building too modular software and the complexity of
glueing everything together is becoming a problem? I feel like the existance
of several "react + this + that" boilerplates indicates something.

I can also be wrong and everything is OK and I am problematizing.

~~~
hasenj
I purposely avoid all this mess. The only thing in my "build stack" was
TypeScript and a small custom script I wrote myself to assemble things
together.

Before I joined that project they were using yoeman and angular and a bunch of
other useless crap. I got rid of all of it.

------
dikaiosune
Hi! I wrote a bunch of the code for CRNA (although it obviously builds on a
lot of great work from Facebook and Expo people). Happy to answer questions.

I'll be doing a brief demo during my lightning talk at ReactConf --
livestreamed at ~5:45pm pacific time today at
[http://conf.reactjs.org/livestream](http://conf.reactjs.org/livestream).

~~~
ChicagoBoy11
I remember buying a Mac in college because I was finally going to get into
Native development!! Well, that was almost 10 years ago and after many false
starts it just never happened... seemed like such an insurmountable amount of
cruft for even the most mundane things.

Then earlier this year I tried RN. And yes, I struggled mightily at times with
building/deploying/linking libraries, but when it came to the app it finally
felt closer to the level of effort I put in building web stuff. And then I
finally sent an app out the door with Camera integration and some pretty neat
UI elements. All thanks to this.

RN has lowered the barrier to entry in such a way that I have a feeling my
story is/will be incredibly common. CRNA is yet another great step in that
direction, so on behalf of us mostly part-time devs, thanks a ton!

~~~
sorenbs
I'm a fairly experienced backend and web developer. My first experience with
RN was exactly this.

During 24 hours at a hackathon I was able to build an app that would show a
live view of the camera, capture 5 frames a second to be analysed by an
external api, overlay recognised food items on the screen, send it all off to
the hello fresh api and display a list of recipes to the user that would use
the most food items from their fridge.

The fact that I was able to accomplish all of this in 24 hours with no prior
RN experience is just amazing to me.

~~~
sorenbs
Btw, GraphQL and React Native / Expo is a great combo
[https://www.learnapollo.com/tutorial-react-native-
vanilla/rn...](https://www.learnapollo.com/tutorial-react-native-
vanilla/rnv-01)

------
RubenSandwich
I'm a bit unsure about this decision. Because this is tying React Native to a
private entity, namely Expo, that has not open sourced it's toolchain used
here. Expo takes your code and builds it on their servers and then serves it
to you. That toolchain unlike React Native is not open source. This is
creating a walled garden around Expo who can easily decide to charge for their
server fees. Yes it is a much easier of an boarding experience then installing
Xcode and Android Studio but at least with Xcode and Android Studio you own
the whole toolchain. Because of this fact I don't think this is comparable to
React Create App, which is excellent.

Edit: Expo has open sourced their code, see below. And CRNA does not build
code on their servers, I assumed it had the same workflow as their XDE tool.
It does not. But I'm still unsure of this decision. It makes Expo a vital part
of React Native, or at least puts them in the position to have that position.

~~~
evv
I work on React Native Open Source at Facebook. We are not attaching React
Native to Expo in any way. This tool simply helps developers get started with
fewer dependencies than before. We are happy to collaborate with any company
that makes React more accessible- not just Expo.

~~~
zerr
I find React Native dev/build environment quite straightforward (and I'm not
even a "JavaScript developer"), so what exactly Expo adds to that?

Slight off-topic: is it possible to use C++ code cross-platform way for
performance-critical parts? i.e. to have single C++ code for iOS and Android,
in React Native.

~~~
evv
The native build environment is tricky for a few reasons. On iOS it takes a
slow download of Xcode and simulator, plus an Apple Developer account. Before
CRNA, there was no open-source way to get start building an iOS app on Windows
or Linux. As for Android, there are a long list of native build dependencies
and environment variables that need to be correctly established before you can
build your app.

It is definitely possible to create a cross-platform C++ library to share
performant across platforms, but unfortunately you need to do the plumbing for
each platform by hand.

~~~
zerr
As I remember, DropBox put some tool/lib for making plumbing (JNI & friends)
easier.

------
baron816
What are people's feelings towards React Native vs actual native mobile
development these days? Are people starting to get the sense that this is the
future and coding in Swift/Objective-C/Java for mobile is dying off?

~~~
stevepotter
I've been doing iOS and Android for about 6 years. My latest project uses
React Native. We just finished an app for both iOS and Android that has over
100 screens and did it in only 3 months with a small team. So I'm a good
authority on this subject.

I found React Native to be a mix of joy and frustration. I was amazed at how
quickly our devs, who came from the web, could build polished screens that
performed beautifully. Then I would become baffled at how, for example, you
couldn't do a background upload in React Native. Here - it does is upload a
file in the background: [https://github.com/Vydia/react-native-background-
upload](https://github.com/Vydia/react-native-background-upload)

In RN, you have to connect JavaScript to native code with "bridges". If a
bridge exists for, say, getting GPS data, you are fine. But if it doesn't,
welcome to the club. I finally became relatively adept at writing these
bridges, but I would have much rather have spent that time writing code for my
app.

Their build system is weak. For example, the build scripts hardcode 'dev mode'
unless you have a build scheme in iOS and Android called 'release'. It felt
like nobody else had built RN apps that have beta and staging environments.
Crash reporting sucks and we finally got it working with sentry.io and some
custom build scripts to upload source maps so we could get decent JS error
reports.

But that stuff will go away in time. I was blown away at the progress we made.
It was painless for web devs to jump right in an be productive. So for us it's
a net positive.

If you're starting something new, try it out. Make your platform choice
carefully. RN isn't the only game in town. See what works for you. And don't
get fooled into thinking that you don't need any native knowledge to make an
app. Maybe hello world, but nothing industrial grade.

~~~
DenisM
>RN isn't the only game in town.

What else is there that's similar? NativeScript?

~~~
sheraz
There is Appcelerator Titanium which has been in the javascript native mobile
app game for 5+ years.

[https://www.appcelerator.com](https://www.appcelerator.com)

~~~
tqkxzugoaupvwqr
I used Appcelerator Titanium to build a couple of apps a few years ago
(2011–2012).

The positive: If you know JavaScript, you can get started quickly because they
provide a JavaScript API and all your code is in JavaScript. Under the hood
the JavaScript connects to native code. So you get a native look and feel on
iOS and Android. You have a single codebase.

The negative: Back then it was impossibly hard to get an app working and/or
looking correctly on both iOS and Android at the same time because Titanium
was full of bugs. So many bugs. This is because for each platform they have to
provide native code. Sometimes their iOS code had bugs, sometimes their
Android code. It was absolutely frustrating. I often had to find workarounds
which caused a lot of delay so I had to double down to keep the deadline.
Titanium was a reason I quit that job after 1.5 years.

On paper it’s nice, but the implementation was terrible. I went back to web
apps and have since been happy.

~~~
mgkimsal
It seemed to me Appcelerator sort of abandoned the smaller/hobbyist/indie
market for enterprise. I was using it in 2013/2014 and went to one of their
conferences in 2014 - activity seemed to really slow to a crawl in public
(hyperloop was announced, and the demo looked great, but I never saw much
after that).

$40/month, but no visual builder. Eclipse-based IDE tooling (which was always
flakey ime). $100/month/seat to get hyperloop and visual builder. Still not
sure what 'arrow' is exactly.

The demos always looked good, but my day to day was... frustrating after a
while. Possibly could have stuck with it and justified with "sunk cost" but I
started looking more closely at cordova stuff. Yes, it's not pure 'native'
(why I liked titanium) but the ecosystem is more flexible (or so it seems).

------
donjh
Create React App was a great addition to the React ecosystem and definitely
made the library more approachable. Excited to check this out!

------
brilliantcode
Has the Android side improved with React Native? The last time I took a look
at this which was last year, the consensus was the Android result wasn't
optimal.

~~~
lacker
There's a ton of work going into polishing many different parts of React
Native right now. So "the Android experience" has definitely improved overall.
But it probably depends on what specifically you were running into last year
that was frustrating during Android development?

------
eeeze
Thanks for the great work on it! Will definitely check it out.

As for someone who was using Expo for a while, how's that different from the
exp start and the rest of the platform? Seems like an interface or another
entry point -question if necessary?

~~~
dikaiosune
The biggest advantages of CRNA right now are:

* Doesn't require an Expo account

* Faster to get started than using XDE

* Smooth 'eject' integration with react-native-cli, if you know that you're eventually going to need custom native modules

I'm sure I'll think of some others at some point. One goal we have right now
is to start bringing the same level of polish to the existing Expo tools.

------
hypercluster
Always interesting to see how cross platform is evolving (this and also
Xamarin update recently), wonder how the Google and Apple regard this. Anyway,
I just tried out the Expo App on iOS and noticed that the back swipe animation
does not seem to be native in the examples. Is there a reason for that?
(that's something I always try out of I want to check if an app is native).

~~~
brentvatne
Hello!

The examples use a navigation library that is implemented entirely in
JavaScript and it does not currently aim for 100% accuracy for platform
gestures and animations. Pure JS navigation is a work in progress with React
Native but, in my eyes, it's the ideal end-state (see a post I wrote here for
more info: [https://blog.expo.io/good-practices-why-you-should-use-
javas...](https://blog.expo.io/good-practices-why-you-should-use-javascript-
whenever-possible-with-react-native-26478ec22334#.8m1k008ip)), but to get
there we need some more powerful low level primitives such as a better gesture
API.

If you prefer to trade-off customizability for platform-specific animations,
you can use NavigatorIOS with Expo/CRNA - [https://facebook.github.io/react-
native/docs/navigatorios.ht...](https://facebook.github.io/react-
native/docs/navigatorios.html). If you eject, you can use a library like
react-native-navigation ([https://github.com/wix/react-native-
navigation](https://github.com/wix/react-native-navigation)) which bridges the
native navigation APIs, or an upcoming library from Airbnb which they use in
their app.

Also, I'm curious which examples stood out to you. The "Growler Prowler" app
intentionally pushes a screen on top without sharing a navbar, even though
this is possible, because this works better for the detail screen. See the
beautiful PocketCasts app
([https://www.shiftyjelly.com/pocketcasts/](https://www.shiftyjelly.com/pocketcasts/))
for the design inspiration there.

Hope that helps!

~~~
mwcampbell
It seems to me that you're repeating the mistake that caused Java AWT and
Swing applications to feel foreign on any mainstream desktop system.

[https://news.ycombinator.com/item?id=8965349](https://news.ycombinator.com/item?id=8965349)

A pure-JavaScript implementation of navigation might feel almost native on
today's mobile platforms if you work hard enough at it. But will it feel
native in the next release of the OS? And does it feel native for all users?
For example, when a user of the VoiceOver screen reader on iOS navigates to a
new page in your app, do they hear VoiceOver's "new screen" sound effect, as
they do when using a real UINavigationController? Also, VOiceOver has a
special gesture for going back. Will that work in your nav implementation?

My point is that when you start with cross-platform and try to tweak and tune
it until it's native, you might miss some subtleties, and it might still not
feel native to some users.

~~~
danabramov
For what it’s worth Airbnb just open sourced a React Native library that
implements navigation natively on both platforms. Check it out:
[https://github.com/airbnb/native-
navigation](https://github.com/airbnb/native-navigation)

------
andrewfong
Are there any tutorials or documentation on integrating Expo with a different
RN build process? For example, if we have an existing setup with TypeScript or
want to use Mocha instead of Jest or whatever.

~~~
ccheever
Hey!

Some people have set up some stuff for doing ClojureScript with Expo.

[https://docs.expo.io/versions/v14.0.0/guides/using-
clojuresc...](https://docs.expo.io/versions/v14.0.0/guides/using-
clojurescript.html)

You can find them in the #clojurescript channel in the Expo community Slack.
[https://slack.expo.io/](https://slack.expo.io/)

That might be the best place to start.

I also threw up a post in the forums that we just setup.
[https://forums.expo.io/t/integration-with-typescript-
mocha-o...](https://forums.expo.io/t/integration-with-typescript-mocha-other-
build-processes/33)

~~~
andrewfong
Thanks! I guess my actual question is -- what are the hook(s) Expo expects
from a React Native package?

I'm used to using Webpack or Gulp or Grunt to transpile source code into
something deployable on the web. The React Native / Expo packaging process
feels opaque to me though. It's not clear to me, for instance, whether Expo
uses [https://github.com/facebook/react-
native/tree/master/package...](https://github.com/facebook/react-
native/tree/master/packager) or whether it has some kind of different
packaging process.

Likewise, a newly created project with the XDE builds automatically using
Babel. But it's not clear from the project itself how XDE knows to use Babel.
Is Babel hard-coded in the XDE? Can I turn it off?

Expo apps also all seem to have a `registerRootComponent` function, but there
isn't any documentation on what this function actually does.

~~~
dikaiosune
Babel is on by default in the React Native packager, which is indeed used
under the hood by both CRNA and Expo's devtools. The template projects include
a .babelrc file.

The `registerRootComponent` function is essentially a facade to
`AppRegistry.registerComponent` but it also configures hooks for Expo's asset
system.

------
sprite
A bit off topic but how is react native performance compared to native? Lets
say you did an Instagram type timeline, would you be able to get the same
scrolling performance with RN as going native?

~~~
jwarren
I've run into a few problems with lower memory Android devices - even with the
optimised ListView components, there were crashes. However, there's a new
FlatList[1] component coming in (I hope) 0.43 which is waaay more performant -
it's practically solved all of my issues.

There are also ways of bridging over to native scroll views - see this
article[2] by Wix's Tal Kol for one example.

1: [https://facebook.github.io/react-
native/releases/next/docs/f...](https://facebook.github.io/react-
native/releases/next/docs/flatlist.html)

2: [https://medium.com/@talkol/recycling-rows-for-high-
performan...](https://medium.com/@talkol/recycling-rows-for-high-performance-
react-native-list-views-628fd0363861#.x98ryoo4t)

~~~
sprite
Thanks.

------
ourcat
Didn't Apple start rejecting apps recently which do 'hot code' pushes to
update apps remotely? (As the video on the Expo.io site says)

~~~
benhoyt
I believe that was only for apps that could talk to Objective C API's
natively, in other words, essentially bypassing the native code review
process. React Native can only do hot updates of JavaScript (which may call
existing Objective C API wrappers, but not create new ones).

~~~
LeoNatan25
It's exactly the same in the case of Rollout, they were also only updating JS
using JavaScriptCore, not using new native APIs.

~~~
jameside
Rollout exposes arbitrary Objective-C APIs to JavaScript (likely using
Objective-C's reflection capabilities), while React Native and Ionic/Cordova
WebViews require you to explicitly bridge your own native methods. That was
one of the key differences in Apple's concern.

~~~
LeoNatan25
Implementations already exist, such as react-native-invoke, that enable
similar functionality. The jump from "need to explicitly bridge" and
"explicitly bridge the runtime API" is very small, opening the possibility of
exactly the same features as Rollout.

The clause of the app store guidelines is not just about code; it also forbids
gaming the review process for adding features or changing the app purpose
without an explicit review. This is regardless of the language used to write
the app.

About react-native-invoke: [https://medium.com/@talkol/invoke-any-native-api-
directly-fr...](https://medium.com/@talkol/invoke-any-native-api-directly-
from-pure-javascript-in-react-native-1fb6afcdf57d#.60pyo15vg)

The GitHub page has been set to private for ... reasons I can't divulge, but
the NPM package is still public.

~~~
brentvatne
I'm confused what the point of your comment is. If you can do it natively you
can do it with React Native. "The jump" for any app from not including
Rollout-style invocations to including them is the same if it's a React Native
app or a normal native app, and these can all be determined by static analysis
by Apple during the review process.

~~~
LeoNatan25
The point is, saying "RN apps only push JS" is disingenuous. The exact same
technology is used to push JS, and that JS can do things that Apple does not
like, RN or not. It appears everyone working in the RN ecosystem is hellbent
to distance themselves from Rollout, but the gap is very small between the two
technologies.

------
fleshweasel
I don't see why there can't be React-like libraries written and used in
languages that compile to native. I'm not expecting to have JSX but I should
be able to write component classes and implement their render methods,
returning view trees written with some kind of object/array literal syntax.

To get as good of a development experience as React, it would require some
work by the compiler and runtime people to basically let you do something like
hot loading--Android has something like this now, and maybe Apple will get it
too, though I'm not holding my breath.

I think it's a no-brainer for web development these days to do React because
1. you can opt out of it for parts of the page it's not going to work with for
whatever reason and 2. the performance is pretty damn good compared to lots of
alternatives, including writing all the UI state management logic yourself.
However, I've not been convinced that the buy-in is worth it for native mobile
development. Can someone who knows more tell me: is it fairly easy to do
something like say "I can't/don't want to use React Native for this view
controller--I'm going to implement it in code and use it and everything will
just work."

~~~
jameside
Companies with large, existing apps that want to use React Native definitely
share the desires written out in your last paragraph. Facebook has this need
in their main app. And at React Conf today, Leland Richardson from Airbnb just
gave a talk on using React Native in "brownfield" apps and seamlessly sharing
a single navigation controller across React Native root views and
UIViewControllers and Android Fragments. The navigation library that helps a
lot with this is here: [https://github.com/airbnb/native-
navigation](https://github.com/airbnb/native-navigation)

------
Traubenfuchs
Crashed my phone (An infinite amount of "Loading js bundle" popups appeared,
creating a solid black background from all the shadows) and then it killed my
server (EDIS/waveride vserver -now unreachable from outside, probably some
kind of overusage protection).

Nice.

~~~
dikaiosune
Hi! Sorry you ran into problems. Was this just using the basic starter
project? If you want to include some platform information in a GitHub issue
I'd love to look into this.

~~~
Traubenfuchs
Yes, it was the starter project.

Additional information: I was connected to the Debian server via putty/SSH
with the js server open and that connection broke around the time where my
phone layered infinite "loading js package" messages above each other. I guess
you should at least do something to prevent that from happening on the client
side. The server side and connection problems are my own demons...

Could there be any logs on my phone or server that could help you? As for the
platform information, I will see what I can get once I can access the server
again. It's a Moto G4 with Android 7 and the server ran some old Debian and
node.js 7.x .

It worked perfectly fine on my local Windows computer.

~~~
dikaiosune
Hi! Sorry for the very late reply, there's been a lot of interest and I
haven't had time t get back to everyone yet.

I'm very surprised to hear about the behavior you ran into with the loading
messages on top of each other -- we haven't run into this issue in the native
client yet (I don't think). If you're interested, I think a GitHub issue may
be best so that I can have a reminder to look into this later on this week.

------
swah
Interesting, this probably kills Phonegap now :) :(

------
Kiro
Is there any reason to use this rather than "New Project" in the XDE if you're
already an Expo user?

~~~
dikaiosune
Probably not. One of the biggest advantages of CRNA is that we built it from
the ground up to not require integrating with Expo's accounts or services. If
you've already opted-in to those services, then you're probably getting what
CRNA offers plus a little extra.

EDIT: That said there are definitely some areas of CRNA that have had more
polish than Expo's current tools, and I'm going to be spending a lot of time
in the coming months bringing them closer to parity.

------
rtw1981
What is the difference between this and [https://facebook.github.io/react-
native/docs/getting-started...](https://facebook.github.io/react-
native/docs/getting-started.html#content)

------
sAbakumoff
What is it with React Native? HN's front page today:

2\. React Native Navigation Library (airbnb.io)

3\. Introducing Create React Native App (facebook.github.io)

8\. Wix Releases a React Native Physics Engine (github.com)

~~~
idointernet
react conference was today

------
intrasight
Serious question: Isn't React Native just a short-term fix while we wait for
WASM?

~~~
johncolanduoni
If you mean you'll write something in a language with a C-ish ontology (C,
C++, Swift, Rust, etc.), WASM won't help you much because you can already
compile these languages for both platforms and interact via bindings; WASM
won't buy you anything except for mandatory interpreter overhead on iOS. If
you mean a GC-ed language like JS or Java, WASM doesn't yet have native GC and
likely wouldn't be much better than JavaScript as a compiler target for these
languages even if/when it does.

WASM solves a totally orthogonal problem: running native-ish code in places
where native code is currently unacceptable (e.g. web, other low-trust
scenarios). Major mobile platforms can handle native code just fine, and WASM
does precisely zero to help you write bindings for platform APIs.

~~~
intrasight
>WASM solves a totally orthogonal problem

I disagree. I want to dump "native" and just have a more performance engine
than is JavaScript. I am assuming that more native hardware will be exposed
via WASM. I want the high-level language that is compiling to WASM to isolate
me from the platform differences. Perhaps is wishful thinking on my part.

~~~
johncolanduoni
What do you mean by native hardware? WASM's only goal is to expose some
"hardware" in the CPU itself, all of whitch is already available to (and
mostly used by) the existing JavaScript engines. Anything that goes through a
driver has nothing to do with WASM; its specification explicitly does not
define _any_ APIs that WASM code can access at all.

If you want more performant code than you're getting from hand-written
JavaScript, you need either (a) an improved JavaScript engine or (b) to write
code in a different language. WASM isn't some magic escape hatch for high
level languages.

------
kikimora
First of all - I enjoy using React in browser and consider it the best browser
UI tech out there. At the same time I've been working with desktop and mobile
apps for past 12 years and there are things that makes me very suspicious
about React Native.

1\. Native apps does not have anything like browser DOM. Most of complex
controls recycle views based on internal control logic. I don't see how
Virtual DOM idea can be mixed with that. UITableView does not care about
Virtual DOM and there is no easy way to apply Virtual DOM diff to a particular
cell. To make default iOS table Virtual DOM aware you will have to rewrite it
from scratch. Quote from here - [https://medium.com/@talkol/recycling-rows-
for-high-performan...](https://medium.com/@talkol/recycling-rows-for-high-
performance-react-native-list-views-628fd0363861#.so16r6s9j) >Recycling
previously allocated rows that went off-screen is a very popular optimization
technique for list views implemented natively in iOS and Android. The default
ListView implementation of React Native avoids this specific optimization in
favor of other cool benefits

2\. Running event handlers in a separate thread is very bad idea. Appcelerator
Titanium does same thing and it gave me all sorts of trouble in the past. For
example - you scroll UIScrollView and it generates scroll events. These events
_asynchronously_ delivered to JS thread. JS thread changes view position.
UIScrollView expect these changes during scroll event not after and does not
optimise for that. As a result you get gazillions layout/scroll events which
kills layout performance. You also get tons of locking/unlocking as a bonus.
In Titanium delay between UI event sending event and JS thread receiving it
was visible with naked eye. It was virtually impossible to create responsive
UI due to these delays. React Native seems much better in this area but I
suspect that complex cases like I described above will break.

3\. People have been trying to build cross platform UI for decades. There are
dozens of desktop technologies in this space. None of them got even close to
the point of replacing native UI. Maybe React Native will be first one but
statistics is not on their side. I think technologies which draw all UI
themselves does better than others which provide cross platform wrappers to
native controls. \- Java Swing, WPF, maybe QT - see some use, mostly in
enterprise. \- Java SWT, wxWidgets (I can add AWT here) - only SWT is being
used in Eclipse, others are pretty much dead.

So I'm really sceptical about React Native future as a replacement for native
UI. It might be useful in niche areas but polished apps might be very
problematic.

You might also find this interesting \- Bloomberg rewrite it consumer app with
React Native [https://www.techatbloomberg.com/blog/bloomberg-used-react-
na...](https://www.techatbloomberg.com/blog/bloomberg-used-react-native-
develop-new-consumer-app/) \- Customers rate it one star -
[https://itunes.apple.com/us/app/bloomberg/id281941097?mt=8](https://itunes.apple.com/us/app/bloomberg/id281941097?mt=8)

Couple of years ago I've spent few months digging into Appcelerator Titainum
which is also based on JS and in a few of ways similar to React Native. After
fixing few bugs in Titanium code base and even making myself familiar with
WebKit internals I can tell that Titanium is complete a garbage without any
hope for improvement. Major reason for this - they decided to run JS on
separate thread for performance reasons.

------
kikimora
First of all - I enjoy using React in browser and consider it the best browser
UI tech out there. At the same time I've been working with desktop and mobile
apps for past 12 years and there are things that makes me very suspicious
about React Native.

1\. Native apps does not have anything like browser DOM. Most of complex
controls recycle views based on internal control logic. I don't see how
Virtual DOM idea can be mixed with that. To make UITableView Virtual DOM aware
you will have to rewrite it from scratch. Quote from here -
[https://medium.com/@talkol/recycling-rows-for-high-
performan...](https://medium.com/@talkol/recycling-rows-for-high-performance-
react-native-list-views-628fd0363861#.so16r6s9j) >Recycling previously
allocated rows that went off-screen is a very popular optimization technique
for list views implemented natively in iOS and Android. The default ListView
implementation of React Native avoids this specific optimization in favor of
other cool benefits

2\. Running event handlers in a separate thread is very bad idea. Appcelerator
Titanium does same thing and it gave me all sorts of trouble in the past. For
example - you scroll UIScrollView and it generates scroll events. These events
_asynchronously_ delivered to JS thread. JS thread change view position.
UIScrollView expect these changes during scroll event not after and does not
optimise for that. As a result you get gazillions layout/scroll events which
kills layout performance. You also get tons of locking/unlocking as a bonus.
In Titanium delay between UI event sending event and JS thread receiving it
was visible with naked eye. It was virtually impossible to create responsive
UI due to these delays. React Native seems much better in this area but I
suspect that complex cases like I described above will break.

3\. People have been trying to build cross platform UI for decades. There are
dozens of desktop technologies in this space. None of them got even close to
the point of replacing native UI. Maybe React Native will be but statistics is
not on their side. Technologies which draw controls themselves does better
than others which provide cross platform wrappers to native controls. Java
Swing, WPF, maybe QT - see some use, mostly in enterprise. Java SWT, wxWidgets
(I can add AWT here) - only SWT is being used in Eclipse, others are pretty
much dead.

So I'm really sceptical about React Native future as a replacement for native
UI. It might be useful in niche areas but polished apps might be very
problematic.

You might also find this interesting \- Bloomberg rewrite it consumer app with
React Native [https://www.techatbloomberg.com/blog/bloomberg-used-react-
na...](https://www.techatbloomberg.com/blog/bloomberg-used-react-native-
develop-new-consumer-app/) \- Customers rate it one star -
[https://itunes.apple.com/us/app/bloomberg/id281941097?mt=8](https://itunes.apple.com/us/app/bloomberg/id281941097?mt=8)

Couple of years ago I've spent few months digging into Appcelerator Titainum
which is also based on JS and in a few of ways similar to React Native. After
fixing few bugs in Titanium code base and even making myself familiar with
WebKit internals I can tell that Titanium is complete a garbage without any
hope for improvement. Major reason for this - they decided to run JS on
separate thread for performance reasons.

