
Use ReactJS to Build Native Apps - andyl
https://twitter.com/floydophone/status/560503411389390848
======
jordwalke
Hi, I'm Jordan from the React team. I'm happy to answer any questions about
React Native, but @vjeux will be giving a more thorough talk tomorrow that you
won't want to miss (if you're at ReactJSConf), so I might wait for him to
answer some of them.

This is not the DOM. This is not a web view. If you know ReactJS, you can
build native apps with React Native.

~~~
peterhunt
There will be more detail tomorrow, but at a high level:

* JS engine on a background thread

* Communicates via batched, async messaging protocol to a native (objc or android) server running on the main thread (basically create_view(), update_view(), destroy_view(), on_event() etc)

* Plug-in for React that speaks that protocol

* Tools to make cross-platform dev a bit easier (standard text component, cross-platform flexbox layout system)

* Designed to take advantage of native platform views, NOT be the next Java Swing

~~~
drcode
Please, please have constraint-based layout support- I know you want to have
it, given your work on react-gss :-)

~~~
gshearer
What would be awesome and truly useful is _real_ constraints, like in CAD
software. I should be able to express every width, height, x, and y value as a
variable, or as a function of other variables. So I call the device height
"A", the width "B", and express the rest of the UI in terms of those
variables. Then at runtime "A" and "B" are defined, and the rest of the layout
magically does its thing.

What Apple calls "constraint-based layout" is cool, but does not follow the
classical definition of what a constraint-based layout actually is. They don't
use variables anywhere in the IB UI. You can only define proportions in code
which is incredibly clunky.

~~~
mlvljr
QML has exactly this -- and you write the constraints (arbitrary complex,
almost) in Javascript :)

------
colinramsay
This is massive. Some more details:

"React Native: everything native, controlled by async batched JS put in a
background thread. Learn once, write everywhere. #reactjsconf" [1]

"Fb groups app in iOS App Store is powered by it #reactjsconf" [2]

"iOS and Android native using all the same ideas as React, all the power of
native." [3]

React has been gaining traction as I'm sure we're all aware, but this is next-
level stuff. I'm particularly interested in how styling's going to work; if
this is really translating into true native stuff then there must be a CSS-
analogue?

[1]
[https://twitter.com/AnnaPawlicka/status/560505089207463936](https://twitter.com/AnnaPawlicka/status/560505089207463936)

[2]
[https://twitter.com/floydophone/status/560504204343521280](https://twitter.com/floydophone/status/560504204343521280)

[3]
[https://twitter.com/voodootikigod/status/560503641920921600](https://twitter.com/voodootikigod/status/560503641920921600)

~~~
threepointone
ahem. my bet - [https://github.com/facebook/css-
layout](https://github.com/facebook/css-layout)

cannot wait for more details.

~~~
kirillklimuk
Seems like you won the pot. @vjeux will be giving a bigger talk about it
tomorrow and he's the biggest contributor to the css project
([https://github.com/facebook/css-
layout/graphs/contributors](https://github.com/facebook/css-
layout/graphs/contributors)).

~~~
bjr-
relevant talk by @vjeux: [https://speakerdeck.com/vjeux/react-css-in-
js](https://speakerdeck.com/vjeux/react-css-in-js)

------
spicyj
"I say with confidence as a former UIKit author: React's model for the UI
layer is vastly better than UIKit's. React Native is a _huge_ deal."

[https://twitter.com/andy_matuschak/status/560511204867575808](https://twitter.com/andy_matuschak/status/560511204867575808)

------
sudhirj
Summary of what I can make out so far:

* Write JS as usual. Write React as usual, but don't use the DOM JSX elements (or the React.DOM) factories - instead use the new 'NativeView' elements.

* The code you write runs in a Javascript interpreter on the background thread.

* The NativeView elements communicate transparently with a native server running on the main thread, which renders and fills native views based on the instructions sent.

* The JS runs react the usual way - I'm assuming the tree reconciliation happens the same way as well - the diff instructions are just sent to the native view server.

~~~
devgeeks
Has anyone asked if this can use other JS libs other than just React ones?
Also, if it's just using say JavaScriptCore and rendering native, I assume
this means speed limitations imposed by the lack of Nitro/etc on the UIWebView
are moot?

~~~
danabramov
JSC doesn't have JIT.

They claim perf is fine though (e.g. because render is always async, app code
is always in background).

We shall see!

------
mcao
This is awesome news. I've been working on a desktop application using React,
node-webkit and browserify and it's been a great development experience. Being
able to leverage web technologies to build native apps has been a huge time
saver. However, I'm relying on the NodeJS components in order to do things
like access the file system and fork commands. I'm wondering how React Native
will handle this functionality. Will it be an extended API or can you only do
AJAX calls? Either way it's very exciting.

~~~
amasad
Native APIs are exposed as JS modules. And XHR, for example, is polyfilled in
terms of whatever native capability exposed. You can totally use npm modules,
provided any module that it uses is polyfilled.

~~~
malandrew
My bet is that they are working with thrift for their transport layer. We're
moving the same direction. I should be landing a bunch of diffs over the next
week to the JS thrift libraries to support XHR and websockets in the nodejs
thrift library (for use with browserify).

------
e0m
"Learn Once Write Everywhere"

I this this is a great mentality over the classic write once run everywhere
approach.

We're currently building a native cross-platform desktop email client in React
+ Flux on Atom Shell. As Nilas thinks about mobile and other platforms it's
clear that the interaction design and information architecture are radically
different. While some code should be re-used most shouldn't. Having a reusable
architecture and way of building apps is definitely the better way to go.

~~~
scribu
> "Learn Once Write Everywhere"

I can't help but think about that other chestnut, "A determined programmer can
write Fortran in any language."

Of course it makes sense to apply a pattern that you know worked great in the
past. The tough part is deciding when it's worth trying something else.

------
joeblau
I can't wait to see more details about this. I hope this isn't another botched
attempt at trying to solve the cross compiled native app challenge. I've seen
and signed up for so many hype machines for solving this problem including
plain old responsive web apps, Adobe AIR, Phone Gap, Corona, and Famo.us. I've
invested time in learning about all of these platforms, but in the end they
all fell short in some way or another. I have high hopes for $FB though
because I've really enjoyed most of the projects they've open sourced
including React and Pop. Personally, it's been easier for me to just learn and
use Swift/Obj-C. The main caveat is that my apps are limited to running on
iOS.

------
amelius
Hi, I'm just reading through the ReactJS docs for the first time, and I found
something peculiar. Let me explain.

So, as I understand ReactJS invokes a render() method defined by the user
(programmer), and the result of that is diff'ed to previous results of the
same method, and as a result, the DOM is modified.

I can understand this, but... The DOM is _already_ incrementally rendered by
the browser. That is, changes to the DOM are not direct, but are performed by
the browser in a way that is as efficient as possible. So, why the need for a
render() method?

Also, the render() method itself could be quite big and thus could take a long
time to run, and almost completely nullify all advantages of incrementally
updating _only_ the display.

So, as you can see, I'm a bit confused...

~~~
yazaddaruvala
There are added benefits for an immutable / FRP style of building a UI, but I
think you're more interested in the rest of my answer.

Nothing to be confused about, you have a valid hypothesis: "Rendering and
Diffing in Javascript is slower than DOM manipulation". However, all
hypothesis need to be experimented before having any real meaning.

It just happens that testing this hypothesis and finding it invalid was the
foundation for React.

Watch this
video[[https://www.youtube.com/watch?v=XxVg_s8xAms](https://www.youtube.com/watch?v=XxVg_s8xAms)]
I think it does a good job discussing this hypothesis and why they chose not
to worry about it.

~~~
amelius
So let's assume I have a listbox with N elements in it. I assume the render()
method has to visit each of these elements every time an updates takes place,
so it is O(N). Please correct me if I'm wrong here.

Now for a certain value of N, things will become slow, unresponsive. I'm
guessing now that this value of N is above the value where the browser cannot
handle this number of elements anyway. Is this correct?

PS: I understand that it is possible to completely optimize the listbox case.
But that is not the scenario I'm interested in. I'm interested most and above
all in the typical use-case. I'm just using a listbox as an example here. Just
replace it by any other sufficiently complicated and customized UI component
if desired.

~~~
WickyNilliams
A render in react doesn't return DOM elements. Render is a pure function which
projects app state into a description of the view. Let's call this description
A, so render(state) -> A. When state changes and render is called a second
time we get a new description, render(newState) -> B. A diff is then applied
to them diff(A, B). The diff can then be translated to an update strategy for
the actual DOM (or in this case, native components). From this the smallest
set of changes are applied to bring the DOM in line with the current state. It
turns out it's far quicker to diff objects in memory than query the DOM. The
DOM is treated as a stateless rendering engine, with progressive updates
applied as app state changes.

Of course, in your example, there is a point where N gets so large that it
poses problems. This is true whether you're using the raw DOM or an
abstraction like React. The solution is the same in either case - cull non-
visible elements from the render tree (again react makes this as efficient as
possible).

EDIT: it's also worth noting you can skip updating entire subtrees in React
with shouldComponentUpdate hooks. This avoids the case where you go through
the render/diff cycle and it turns out there is no difference, and so nothing
to update. Paired with immutable data structures this method can be a simple
reference equality check (shallow equals) oldState !== newState, and therefore
can really get the most efficient rendering possible

~~~
WickyNilliams
Amelius, I cannot reply to you directly for some reason. Anyway...

So say you're rendering some long list of items. Because react is just plain
JS (no templates!), you will map the array of items to components in your
render. You give each item a key so that react can reconcile components across
renders. If component with same key is returned from render next time then
it's kept in the DOM (and any updates applied), if not then it's removed. So
the involved part becomes determining what is visible or not, and then slicing
your list of items to only map a subset. This is the more involved part. I
haven't built anything like this myself, but I'm guessing it basically boils
down to: listening to scroll events on container, determining y offset, get
height of contaoner and height of elements, use that to determine which items
in list should be mapped to components in render. That bit is the same whether
react or not.

See James Longster's epic blog post "Reducing User Interface Complexity, Or
Why React Is Awesome" [0]. Where he details this kind of approach with his
for-demp-purposes-only react-like lib.

[0] [http://jlongster.com/Removing-User-Interface-
Complexity,-or-...](http://jlongster.com/Removing-User-Interface-
Complexity,-or-Why-React-is-Awesome)

~~~
amelius
Thanks a lot for this detailed explanation.

If I get this clearly, then still:

render() -> returns N items every time it is invoked

And React will diff those N items against the DOM (using a key) every time an
update is required.

So, to me it appears that still O(N) amount of work has to be done every time
something small changes in the list.

This is not necessarily a bad thing. But here we assume that doing render() is
faster than actually building the DOM from scratch, even though they have the
same computational complexity, O(N).

Anyway, I'll have a look at that link. Very interesting, thanks again.

~~~
WickyNilliams
no, it doesn't compare to DOM, it compares to the last result of render - an
important difference performance-wise. the DOM is many times slower to query
than plain objects.

also remember big-O notation doesn't really capture the essence of the problem
here. looping through and querying N DOM elements is probably orders of
magnitude slower than doing the same with N objects in memory

------
aakilfernandes
What does this mean? Can't you use any javascript tech to build native apps
with nwjs or cordova?

Edit: looks like this isn't hybrid as I assumed but truly native

~~~
diverightin63
I am pretty confused as to what this actually does. How can it be native?

~~~
aakilfernandes
My guess is we're missing an important piece of the puzzle. Unless they have a
js to everything interpreter. In which case thats much bigger news than react.

~~~
taurath
Its more of a shiv to convert react elements/calls into native UI elements,
using a native server to receive streams/messages (unsure which) and convert
them.

------
jamesgpearce
Video of this keynote is now up: [https://youtube.com/watch?v=KVZ-P-
ZI6W4](https://youtube.com/watch?v=KVZ-P-ZI6W4)

------
TheAceOfHearts
Extremely excited about this!

I tend to prefer native interfaces over web interfaces, but found it really
bothersome to have to work with native toolkits. There's stuff like tint2
([https://github.com/trueinteractions/tint2](https://github.com/trueinteractions/tint2)),
but it's still not stable enough, IMO.

This is HUGE. I'm extremely excited to try this out. Being able to write the
interface with JS/JSX, and then switch between JS and native code as you see
fit or the need arises is truly the best of both worlds. For a lot of problems
JS is not your bottleneck, but if it _does_ become your bottleneck you can
rewrite it natively!

~~~
tlinton
What was the issues you had with Tint (just curious).

------
polskibus
I'm a big ReactJS fan, however isn't moving React to native a bit like old
school windows message loop ?

~~~
hardwaresofton
Yes, the whole system is just basically component rendering (react) + a
message bus oriented architecture (flux). The architecture is not novel, but I
think the big change between React Native (or whatever they're going to call
it) and any actual native application is the same difference between
approaches like Cordova (formerly known as PhoneGap) and node-webkit. Platform
independence.

The problem with "old school windows message loop" is the "windows" part (not
because I don't like windows, "mac" or "linux" or "freebsd" or "solaris" could
all go in there). Why haven't we abstracted presentation (functionality is a
harder/more nuanced proposition).

------
serve_yay
It occurs to me that, for years, web platforms sought to keep developers from
ever having to touch dirty old JS. I can remember all sorts of overcomplicated
ASP.NET widgets that were like that.

Now we want JS and don't want to deal with gross native APIs. Perhaps it's not
the same "we", though I personally am very excited about this. I love JS and I
think React's ideas are the right ones for building UIs.

------
chrisdevereux
Cool. I've always thought that the native view layer is better viewed
analagously to how web developers tend to view the DOM: a low(ish)-level API
upon which to build abstractions that better fit the domain.

Hopefully, we will come to view manual NSView slugging in the same way that
we'd now view building a single page webapp entirely with jQuery.

------
akfanta
Sorry for an ignorant question, but what would be the relationship between
ReactJS and React Native?

~~~
jrm2k6
React-native uses React code to build native applications.

------
sekasi
I have long questioned the validity of middleware (for the lack of better
terms, please don't be pedantic) to create native applications.

I get it, HTML can replicate performance of native apps to a certain extent
now, but it's also bound by restrictions that native apps aren't.

Speed of innovation being one. HTML5 is a large ship that takes a long time to
evolve (in comparison). iOS and Android aren't, by the same means.
Particularly iOS since Apple has a habit of introducing backwards
compatibility breaking new features.

I don't understand fully how hybrid made apps will ever be able to properly
compete with a native platform for this reason alone, not mentioning some of
the other problems that plague hybrid and middle ware apps.

~~~
RussianCow
React Native is not built on the DOM and thus is not "hybrid"\--it seems it's
fully native under the hood.

------
aceperry
This is huge. There are so many approaches to cross platform mobile
development, yet none of them really make it easy to integrate a full stack
web platform. This is one step closer.

------
tilt
Very promising! As a (past) Titanium developer, FB Groups being in the wild
for a while comes as a relieve to my hears.

I'd bet Angular going Native first, though, I guessed it was coming with 2.0

------
aoakenfo
So...a JS interface to a server that creates native views. I don't get it,
what is all the hype about? You've got an extra layer and level of abstraction
(read: complexity) in your pipeline. I don't see how you can abstract away the
idioms of a platform - they're _native_. 'Write once, run everywhere' has
failed time and time again. So marketing changed its tune to 'Learn once, run
everywhere' and now people are gushing how HUGE this is?

------
elwell
Cue Om Native...

~~~
arms
God, I would love to see this (or Reagent Native).

------
saosebastiao
Is there more information somewhere? Or just a tweet?

~~~
sehr
[https://twitter.com/fbOpenSource/status/560506714382802945](https://twitter.com/fbOpenSource/status/560506714382802945)

Looks like it's not being open sourced for a while, but apparently the
attendees are going to have some hands on tomorrow.

2015 seems like it's shaping up to be the year of React!

~~~
pjmlp
> 2015 seems like it's shaping up to be the year of React!

Something needs to replace AngularJS I guess, until the next big thing.

------
ryanSrich
As someone who is just getting into iOS dev is there any benefit (that's at
least known at this point) to using React over Swift for UI?

~~~
rickyc091
It really depends on what you are using iOS for.

If you already know ReactJS, then it'll probably be a lot easier for you to
learn React Native than Swift or Objective-C.

If you are working on a team with primarily JS developers, React Native is
probably a better choice to go with.

Will this cause Swift to be irrelevant? Probably not.

\--

If you are learning iOS and doing production / client work, you should be
aware that using a third party framework could actually break your app. I'm
interested in React Naive, but also very weary about it. Facebook released a
framework called Three20 back in iOS 2.0/3.0 days and abandoned the project
shortly afterwards. Of course being open source there is bound to be people
who take over the project, but it's something to think about.

------
kin
This sounds promising. I've been building something with Ionic recently and
it's great 'cause it's just Angular but the documentation is a bit
inconsistent and outdated. If React Native were to execute and deliver, I'd
definitely love to switch over.

------
yuchi
Seasoned Appcelerator’s Titanium Mobile SDK dev here. Looks like that a lot of
people here is comparing this announcement from the react team to the Titanium
Mobile SDK. I’d like to give some info to shed some light on the differences,
and probably anticipate the challenges they have to (or _had_ to) solve.

## Architecture

Both Titanium SDK and this Native React thing _do have_ a JavaScript runtime
behind the curtains.

Both frameworks will run the JS runtime on the background, on a different
thread from the UI. This is incredibly important to remind.

Titanium SDK follows an OOP-ish, imperative approach. You create views using
factories (`Titanium.UI.createScrollView({ })`) and you add those views to
parent views (`parent.add(child)`). This is very similar to a browser DOM, and
in fact it’s cumbersome to work with. They built an xml preprocessor called
Alloy which does a better job at exposing the view hierarchy right in the
source, but it just compiles down to JS, `create()` and `add()`.

This is important for the evaluation _at least_ for the following reason:
every time you update a property on a view (actually on a proxy object to the
real view) you’re _crossing the bridge_ and you have to pay that penality. The
bridge is the void between the JS runtime’s thread and the main, UI’s one.
This is incredibly painful when trying to do JS animations, sometimes if
you’re not careful you can get hurt very badly. You can still do great things,
but it’s way better to use the native `.animate()` methods, which cross the
bridge only twice (at start, and at the end as a callback invoking).

On Native React you should not have this kind of problems because changes will
be batched and updated on a update loop basis or at least debounced. Or at
least optimized in some smart way. I believe.

## Layout

One big problem will be the layout. Given that they don’t want the developers
to understand every layout system every platform provides, they have to
normalize it somehow. Titanium SDK has it’s own layout system, incredibly easy
to understand even from a web-only dev experience:

a) by default everything is absolute positioned,

b) you can get a vertical flow layout by setting the 'layout' property on the
parent view or

c) you can get a horizontal flow (inline-block-ish) by setting 'layout' to
horizontal.

Native React will probably follow a more intimately web-ish approach, just
look at this JS/C/Java implementation of the box-model and flex-box
specification by Facebook itself [1]

[1]: [https://github.com/facebook/css-layout](https://github.com/facebook/css-
layout)

## Support and limits

Titanium SDK is always criticized for being to limited in what you can do with
it. This actually comes from two different issues:

1) they have to (almost) manually implement every API you might need, by
proxying from native-land to JS-land;

2) they have to follow every release of the platform’s SDK;

3) you cannot just put native code along-side your JS code, so you cannot go
where they didn’t.

Let’s see how Native React will solve this issue.

Titanium SDK is undergoing an heavy lifting refactoring to solve exactly this
issues. The project is code-named Hyperloop and is already working behind the
curtains for the Windows 8 version of the SDK.

## Conclusion

Because I shamelessy want to karma-drift this topic, I’ll stop here.

It’s interesting, but until they show us some (native) code... it’s just
ideas.

Follow me on twitter (@_pier) and github (@yuchi) for Titanium related stuff.

Also my company, SMC, does a lot of great opensource things for Titanium (on
gh we’re @smclab)

~~~
doublerebel
Titanium comparisons are some of my top thoughts too.

1) How do they access the native API?

If there's no abstraction, just a translation, then the apps must be different
for each platform. If there is an abstraction, then how much of the native
platform do they cover? It can't be 100%, and the native APIs change with
every OS version. Basic calls are easy, integrating things like device
keychain, intents, and services are not so easy -- we learned this with
Titanium.

2) How will React Native do cross-platform local data storage?

Being able to easily import, retain, and sync remote data is an absolute need
for today's apps. Titanium uses SQLite on both sides, and has modules for more
(like TiTouchDB). Not abstracting data storage would be a major mistake IMHO.

3) Can we use standard npm modules?

JS's killer feature is the module ecosystem, it's no good having a JS engine
if we have to reinvent common modules to match a new API. V8 is the gold
standard here, fingers crossed.

4) Debugging?

Speaks for itself. Debugging both JS and native code together bridged from a
device is _hard_. Hopefully they are adapting existing tools and IDEs like
node-inspector and Sublime Text.

~~~
yuchi
Exactly. As Haynie stated on tw, it’s sad that they didn’t included them in
the design process. They already solved a lot of challenges.

BTW, did you have a look at titaniumifier?
([https://github.com/smclab/titaniumifier](https://github.com/smclab/titaniumifier))
it’s a tool we built to port node packages to titanium (a declination of
browserify, actually).

------
vertAlign
Everyone felt that in terms of Javascript rendering on mobile you guys had the
best shot.

Did you feel that JS had hit it's limits with rendering and wasn't strong
enough for mobile sites/apps?

Looking forward to hearing more about React Native!

------
xasos
Nilas[1] is using React with Atom Shell to build a native desktop mail client
for all three major platforms on top of their API. Awesome stuff!

[1] [https://www.nilas.com/](https://www.nilas.com/)

------
b5i
I didn't attend the conf. Is there a way to get access to the repo?

------
debacle
Facebook, destroying the edifices of the Internet, one technology at a time.

Very excited for this. I have been looking at React for a while, now it's
certainly time to take a plunge.

------
psulatycke
How does React Native handle OpenGl ES calls? Does it convert Webgl calls to
native OpenGL or provide an interface to directly make native OpenGl calls
from javascript?

------
kenshin03
On iOS I'd imagine this uses the underlying Webkit JavascriptCore engine. How
about Android? Do I need to embed a V8 in my app if I want to use React
Native?

------
crudbug
I see React effectively as the controller of UI state changes. This can be
applied on any datapath, i.e. model to view rendering - web / native / games.

------
arms
This is very exciting. I've been using React for a bit now and have found it a
pleasure to work with. I can't wait for more details on React Native.

------
csulmone
Does this include desktop apps?

------
ZZB
Doesn't it violate the apple policy about updating the app without reviewing?

------
thasmin
I would love to see React added to mobile app frameworks like Apache Cordova.

~~~
andyl
You can use ReactJS now with Cordova/PhoneGap - no problemo.

This announcement is about replacing html elements (div, h1, img, etc.) with
native elements. Should be faster going native than via web elements.

~~~
pbreit
So does it use PhoneGap or something like it?

~~~
zpao
No, it skips the DOM entirely and works with native elements (iOS views)
directly.

~~~
diverightin63
This is where I get confused. How is it compiling to these elements?

~~~
smadge
One possibility: You have a JS interpreter running your React code. You
generate a virtual DOM and hand it off to React. React sends the virtual DOM
through a message bus to native code. So far, nothing crazy here, this is how
frameworks like cordova work. That native code dynamically translates the
virtual DOM into native UI elements.

------
sz4kerto
Will it work with Reagent?

------
_pb
This is really exciting! Can't wait to use it.

------
michaelmcmillan
Coupling your app to any framework has proved to be a really bad idea in the
long run, to me this is a step in the wrong direction. If I've understood this
announcement correctly.

------
shripadk
React is the Future. Period!

------
danr4
oh boy now i can call myself an app developer too

