

A Deep Dive on React Native [video] - arasmussen
https://www.youtube.com/watch?v=7rDsRXj9-cU

======
joemaller1
I'm very excited about this, but can someone _please_ write something down?
The videos are nice an all, but information-wise they're incredibly low-
density. If I have an hour to spend on React Native, I'd rather read for 10
minutes and experiment for the remaining 50...

~~~
iamdanfox
If you have to watch a video though, try increasing the playback speed (it's
in the little settings gear on the YouTube player).

I normally listen for a few minutes at double speed, then drop down to 1.5 if
necessary.

~~~
sandyarmstrong
Did you try that with this video? I had enough trouble with the speaker
rushing words in a thick accent at normal speed (not even meant as a
criticism...just one of those things you come across at these conferences).

Sometimes speeding up just isn't a viable option. I'm glad I had the time to
watch the whole video last night, but I too am looking forward to blog posts,
documentation, and code releases. Way easier for me to digest quickly, and at
my own pace.

~~~
pluma
I actually don't find him that difficult to understand at 1.5x. But it's
probably a matter of exposure -- as a German living in Europe I'm used to all
kinds of European accents in English and common mispronunciations, whereas I'd
probably barely be able to keep up if it was an Indian accent, for example.

------
yazaddaruvala
I'm curious about animations. That is one thing React hasn't _really_ figured
out on the web. I think the last experiment I saw was to do all the animations
manually using component state. I wonder if this is the same on Native?

Ideally a cross pollination of ideas about animations would make both
ecosystems better.

~~~
rpwverheij
yes, this is a good question. I still have to implement drag and drop in a
react project, and it seems the way to go is do this all through state? Which
means none of the existing drag and drop solutions will work (any DOM
manipulation without react knowing about it will cause trouble), and since
react is relatively new there is seems there is still a need for good reusable
animation components/mixins, and in the mean time, it's all a bit more manual
work.

~~~
mikewhy
> Which means none of the existing drag and drop solutions will work (any DOM
> manipulation without react knowing about it will cause trouble)

Um, we totally use jquery-ui's drag and drop in a React component in
production and nothing bad happens.

~~~
rpwverheij
Ah, ok. Good to know. You just listen to the drop events and then update the
state of react?

~~~
mikewhy
Yup, but it's not necessarily UI state that gets updated, just something that
maps draggables to where they've been dropped.

~~~
rpwverheij
yes, like updating the position in a sorted list you mean right. And did you
also get it to work with touch events on mobile? I have an open question about
that on SO [http://stackoverflow.com/questions/27837500/drag-and-drop-
wi...](http://stackoverflow.com/questions/27837500/drag-and-drop-with-touch-
support-for-react-js)

~~~
mikewhy
Simply adding jquery-ui.touch-punch[0] monkey patched jquery-ui without us
having to do anything else.

[0]: [http://touchpunch.furf.com/](http://touchpunch.furf.com/)

------
pavlov
React Native is a cool project, but the deafening hype is slightly puzzling.

Creating and calling native UI components from JavaScript is nothing special
in itself. It's obviously possible to do it from JS just as well as from any
other language -- you just need to provide the API. There you have two
choices: either a bridge that translates the native API directly, or a wrapper
class hierarchy.

Examples of bridges include Xamarin's Mono that lets you build iOS user
interfaces in C# code, and RubyMotion that lets you build Mac UIs in Ruby.
Because these are bridges, the entire Cocoa API is exposed. The downside is
that the bridge does nothing to smooth over platform differences: you can
write in C# on all platforms, but you still have to learn Cocoa.

A prominent example of a wrapper API is Titanium Appcelerator that lets you
build cross-platform mobile apps. Another good example is GTK+ for desktop
apps: it's smart enough to leverage native Windows components where possible,
but the GTK+ API is higher level than that of native Win32.

React Native is primarily in the latter category. Based on jordwalke's comment
in another HN thread, they currently have cross-platform wrappers for View and
Image:

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

But it appears you can also create platform-specific views, and for that they
presumably have some kind of bridge. (It could also be that they provide
manually written wrappers for platform-specific views, e.g. UIMapView becomes
a <Map> and so on.)

In sum: React Native doesn't magically translate your JS+HTML app into a
cross-platform native app. They're a long way off from having a full cross-
platform API (unless your app is so simple that it can be described in terms
of <View> and <Image>). And, like all wrapper APIs, there is a degree of
impedance mismatch between the underlying platform implementation and the
cross-platform interface on top.

There's a lot to like about React Native, though. The layout model and binding
logic seems cool. The React team's accomplishments in the browser environment
are impressive. With time, React Native could become for mobile what Qt is on
the desktop -- and that's high praise in my books.

~~~
mercer
I think the hype is partly because many people (myself included) _really_
like, even love React (and Flux). So being able to use it for native apps is
great news for us.

~~~
RivieraKid
Exactly this. I don't care about cross platform development. But I'd love to
be able to develop UI's on Android using a similar paradigm I can do on the
web with React. The main downside for me is that it's JS, not Java.

------
jdub
Keep in mind that this is _NOT_ (primarily) about cross platform application
development. As the developers say, "Learn once, write anywhere".

It's about building native applications in the React style (declarative,
componentised), with very rapid turnaround because much of your logic and
layout is defined in JavaScript. Instead of recompiling your app's native code
all the time, you're just reloading JavaScript within it.

It's possible that some components could be shared between platforms, but
ultimately I think most of them will be different, reflecting the UI structure
of the target environment. There's probably more scope for sharing higher
level non-UI-element components.

------
pmontra
All of this looks great and I'll give it a try as soon as I get some spare
time, but there are a couple of things I didn't understand.

1) Is this cross platform or are you still going to have separate code bases
for the UIs of iOS and Android? Looking at the code in the demo there are
components like View, Text and Image. As basic as they are, are they the same
on iOS and Android (same behaviour, same arguments)? It was pretty clear from
the first minutes of the video that View is build on top of the native view of
iOS (he showed the objC code). Is that React code building for Android?

2) I guess that one must still be proficient in iOS and Android, unless they
make the monumental job of rewriting all the iOS and Android documentation for
the React components they implemented. I expect to have to reference the
native docs to understand the meaning of the arguments and do the job of
mapping React to native. That has always been a pain point in many UI
abstraction layers.

~~~
rpwverheij
View, Text and Image should be cross-platform, and might even be targeted for
web at some point. And more components could be. But they emphasised that you
should be able to _choose_ how much code you want to re-use cross-platform,
and that you should always put energy in targeting and perfecting for specific
platforms

------
lemming
This looks really nice. One question that I've found conflicting information
about - is JavaScriptCore JITed on iOS 8? I know it isn't on iOS 7 and
earlier, my understanding was that it was on iOS 8 but it's hard to find a
definitive answer. Anyone know?

~~~
lbradstreet
The new webkit view (WKWebView) is JITed. I'm not sure about using
JavaScriptCore independently of it though.

~~~
spicyj
JavaScriptCore isn't JITed, even on iOS 8.

~~~
shawn-butler
Pretty sure I heard them say exactly that it was at WWDC. I wrote it down in
my notes anyway. ~04:30 in the WWDC video "Introducing the Modern WebKIT API"

It was stated it used 4th tier LLVM JIT (FTL) [0]. Do you have evidence to the
contrary? What did you do to test? If you can outline what you did I will be
happy to help out and investigate.

[0]: [https://www.webkit.org/blog/3362/introducing-the-webkit-
ftl-...](https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/)

~~~
spicyj
Sorry, you probably misunderstood me – WKWebView runs in a separate process
and does have a JIT (discussed in that video); JavaScriptCore runs in the same
process and does not.

------
epaga
The 5-minute demo at the end (22:24) is incredibly impressive:
[http://youtu.be/7rDsRXj9-cU?t=22m24s](http://youtu.be/7rDsRXj9-cU?t=22m24s)

That just seems SO much easier, quicker, and more efficient than storyboarding
and coding UIViews. I am very much looking forward to being able to play
around with this and discover downsides, because there have to be
some...right?

------
m1el
I see that they're using display:flex for layout, for _all_ elements, which
makes things like inline styles impossible or extremely inconvenient.

[http://jsfiddle.net/u8wd8kdL/5/](http://jsfiddle.net/u8wd8kdL/5/)

If I am wrong, please provide me an example of how to layout that text with
display:flex.

~~~
madeofpalk
I think it's worthwhile to note that they aren't using CSS, they're using a
CSS-like syntax as a constraint solver. This means they're able to define new
properties or reinterpret things to suit the native platforms they're building
for.

------
thoman23
I'm definitely interested in seeing what React, and React Native, can do, but
I have to say these people cheering like Ofrah just gave them a free car are
kind of turning me off.

"This is a native component". "WOOOOOOOOH!!!" "YEAH!!" <high fives>

~~~
rattray
It's a speech. People cheer during speeches. Also, it's pretty mind blowing
that they're actually calling native components from JS if you ask me.

~~~
ErikHuisman
It is rendered native (described in js) not in a webview. Otherwise they
should call it web components.

------
wildpeaks
They picked a great timing for the announcement because I needed to use native
components with a React app, similar to how Ejecta
([http://impactjs.com/ejecta](http://impactjs.com/ejecta)) reimplemented the
WebGL API to run js apps without DOM/WebView) but had settled with Cordova
plugins because it would have taken probably too long to implement otherwise,
so I have high hopes for React Native :)

------
pj4533
Since I already know ObjC & Swift, the most interesting part of this is at
8:17. "What if we could server-side run native apps? ...we could do it".

Hmmmm.

An interesting idea, however Apple might have something to say about that (App
Store Review Guidelines):

2.7 Apps that download code in any way or form will be rejected

2.8 Apps that install or launch other executable code will be rejected

Still...I like the idea of pushing the boundaries of native iOS development.

~~~
wildpeaks
JavaScriptCore executes javascript embedded in the app, it's not like a
webview that would download an arbitrary webpage/script, so it wouldn't
conflict with the guidelines

~~~
pj4533
Yeah thats how the Groups app works now, but I was referring to his forward
thinking "server-side run native apps". Thats way different.

------
pandeiro
Has anyone who's seen the actual code comment?

From what I understood on the video, this is going to be distributed via a
repo that is essentially already an iOS or Android template?

There wasn't much talk about the compilation process. Maybe the details (for
the open source version) haven't been ironed out?

------
oliyoung
I've been down on "cross platform native apps" because they're always the
lowest common denominator of the language and platform, but this looks
intriguing.

------
JamesSwift
The next logical step here is that this gets wrapped by an Om-like and then we
are writing native apps in clojure! That is pretty exciting to me.

------
lynndylanhurley
The one thing that's prevented me from using flex-box is browser support.

Because flex-box has been re-implemented in JS, does this mean that the css-
layout project [1] will provide flex-box support for older browsers?

I looked, but I couldn't find a "compatibility" section anywhere in the repo.

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

~~~
albertoleal
From what I can tell, it can support older browsers, since the CSS output is
very primitive.

My current issue is how to measure text sizes:
[https://github.com/facebook/css-
layout/blob/master/src/__tes...](https://github.com/facebook/css-
layout/blob/master/src/__tests__/Layout-test.js#L755-L760)

------
mandeepj
[https://www.infinum.co/the-capsized-
eight/articles/running-j...](https://www.infinum.co/the-capsized-
eight/articles/running-javascript-in-an-ios-application-with-javascriptcore)

This article have lot of details about how JS is getting executed on the
Native platform. Lot of components are provided by Apple like JS VM

------
bohol
I get that people are excited, but it seems like time and time again these
abstractions fail to solve the underlying problems.

It's like how we never got a fix for making cross platform applications. And
regardless how much people wants the new way of doing things to work, the
results speak for themselves. Atom, the editor, can't even handle window re-
sizing smoothly.

~~~
rattray
Did you watch the video? They're taking a genuinely new approach here. It's
not "lowest common denominator" like Xamarin, Qt, etc, and it's also not a
WebView like Atom or Ionic (Cordova).

It's actual native components, with the intent that you "learn once, write
everywhere" rather than try to jam iOS and Android into the same codebase.

~~~
danabramov
To be fair, Xamarin isn't "lowest common denominator" either.

It's all native and even with xplat Xamarin.Forms you can customize code for
each platform.

------
gosia-m
Seems like the time has come for the synergy of native + JavaScript. React.js
are not the only ones working on it... Tabris.js works on a similar principle
(combine the best of native and web) and offers features like instant
debugging of JavaScript on your device. It's currently invite only.

------
Nilzor
I'm not sure I got how the Javascript code executing? For the case of Android,
is the library spinning up a WebView to get access to the V8 engine?

~~~
ianlevesque
Doubtful, they can just include a compiled JavaScript runtime.

~~~
Nilzor
I thought JavaScript was interpreted? Seriously, are there Linux JavaScript
compilers existing - which don't depend on Node or any other JIT-compiler, and
which can be integrated in Android projects?

~~~
ianlevesque
I meant compile an open source java script interpreter and bundle it, not
compile the javascript.

------
bsaul
i'm not using react for the web so maybe this is a silly question, but how do
you pass data from your obj-c controllers ( or any native object) to those
reactjs views ?

Also, the constraint solver could be a good riddance but is there going to be
any support for uikit dynamics ?

------
morenoh149
This looks really exciting. The fast code edit to relanch time is a really big
deal to me.

