
First Impressions Using React Native - jlongster
http://jlongster.com/First-Impressions-using-React-Native
======
azakai
I think it's a very strong point that moving script code off the main thread
can help achieve smooth UIs. No more GC pauses, no more slowdowns if the JS
engine hits a snag, etc.

I think this is actually possible on the web as well. Someone could write a UI
framework which runs JS in a Worker, and sends messages to the main thread, on
which there is HTML and minimal JS to receive the messages and handle them.

I'm surprised this hasn't been done, or has it and I just haven't heard about
it?

If you're worried about the overhead of transferring lots of messages from the
Worker to the main thread, I think it can be pretty fast actually. I did an
experiment with proxying WebGL that way, which is a fairly high-traffic API,
with nice results,

[https://blog.mozilla.org/research/2014/07/22/webgl-in-web-
wo...](https://blog.mozilla.org/research/2014/07/22/webgl-in-web-workers-
today-and-faster-than-expected/)

For something rendering a UI, message passing overhead should be reasonable,
especially if the framework is smart enough to only send over what changes
(like React Native does).

~~~
jlongster
You are speaking my language! I would _love_ to see a prototype of this. I've
been thinking about it since I saw React Native.

I wonder if there's even value in something like an asm.js-compiled layout
system, which absolutely positions elements. One of the insights of React
Native is that to build apps, we really only need a small subset of the web's
layout algorithms. Only flexbox, really. So if we recognize this subset, and
remove everything else, there main thread can focus on really smooth
performance.

React Native even performs the flexbox layout on a 3rd thread, and tells the
main thread where to absolutely position stuff.

Obviously we want to re-use as much of HTML as we can, but there might be some
crazy ways to remove stuff from the main thread.

EDIT: It should be noted that Mercury, a React-inspired library
([https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)), has
examples of running in a web worker. It is pretty cool, but I think it needs
to be fleshed out more.

~~~
malandrew
We explored this at a previous company I worked at. The conclusion at the time
was that the message passing model was not yet efficient enough at the time
because of serialization/deserialization which nullified any performance
gains. Transferrable objects at the time were really new. If the support for
shared memory has improved, it might now make sense.

The biggest problems with performance are:

\- GC pauses

\- triggering reflow

\- marshalling data across interfaces (serialization/deserialization of native
types into strings and back again).

That last one is an absolute killer when it comes to applying 3D matrix
transforms. Basically, you're taking an array of floats, serializing them into
a string to do an element.style property assignment, so that the browser can
then take that stringified representation and convert it back into an array of
floats that it can apply. Huge perf hit here.

~~~
jordwalke
I haven't found serialization to be _anywhere near_ the bottleneck. How long
does it take to serialize/deserialize a 16 element array? I could see how this
would be an issue if you had hundreds of them per frame. But for most purposes
an entire 16 element array is overkill and you could probably come up with a
more compressed description of the transforms (scale, rotate, translate) and
consider adding a pooling layer.

People attribute pauses to GC, when it's sometimes just the browser container
environment acting up and there's nothing we can do about it - so it's easy to
write it off as GC. Not sure about today, but 1.5 years ago (i = new Image(),
i.src="http...") could block the JS thread for as much as 19ms. In a larger
app, it's easy to write that off as GC, but (at least on iOS) the performance
tooling is really lacking and it's tough to find the culprit.

Reflowing is a big deal, I agree.

~~~
malandrew
Basically if you want to prevent reflowing you end up making everything a
texture and that leads you to making many many CSS transform changes on every
frame. 60fps is easy to hit on a modern desktop, but mobile performance
requires more effort to achieve an effect that feels natural. The problem with
the marshalling is that it is comparatively expensive and a blocking
operation, which is not conducive to buttery smooth graphics performance on
all platforms.

------
jenius
> "This is _solid engineering_. And it completely reinforces the fact that
> _React.js is the right way_ to build apps."

This just comes off as really weird to me. Why would any sane developer make a
statement like this? It sounds preachy and brainwash-y and weird. If there's
anything we learn as developers it's that there never is and never will be a
single "right way" to do everything. Reading stuff like this makes me doubt
the entire article.

There's a difference between writing objectively about something that's
interesting that you enjoyed, and trying to lay down a dogma. TBH, the more of
this article I read, the more my view of it's goals swayed towards the latter.

~~~
serve_yay
I like having opinions. People can disagree with them, of course, as has
always been the case.

~~~
jenius
Look up the definition of the word "opinion" on google or a dictionary. Then
look up the word "dogma". Then re-read my comment. Fair? It's not the opinion
I'm objected to, it's the way of stating it.

~~~
serve_yay
You're really just complaining about the phrasing of it and saying that it
should have been worded in a mealy-mouthed way. That's silly, it's just an
expression of an opinion.

~~~
jenius
This is absurd. Are you serious? The way you express your opinions is
enormously important. It could easily be the difference between getting a
raise and getting fired. Expressing your opinions in a way makes sense to
other people and they take well to is the farthest thing from silly ever, it's
like a #1 essential skill for life. On top of that, phrasing informs the
message, and in this case I was not just complaining about the phrasing, I was
also complaining about the outrageous statement being made.

For example, saying "React is the best way to build all apps no matter what"
vs. saying "Compared to building native UIs with objective C, react-native
made for a much smoother experience for me because of X Y and Z" are not only
phrased differently, they are communicating different things. The first one is
an absurd overarching dogma declaring every other app-building technology to
be inferior to react with no backing whatsoever, and the second one is a
useful and specific analysis of react in one situation compared to an
alternative.

I can't figure out if you're trolling or not, honestly.

~~~
nkohari
> React is the best way to build all apps _no matter what_

When you alter a quote, you're only illustrating your own bias, not that of
the author.

------
danabramov
Declarative UI is boss.

I know Andy (former UIKit team) was quoted in the intro thread but I'll do it
again:

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

If you're averse to React because of JSX, “mixing templates and views” and
similar superficial “best practices”, you're missing out. Engineers embracing
React are not dumb. You should consider a possibility that they think it's
good for a reason, and that reason is something you should learn about instead
of armchair-rejecting it.

Try tuning out your inner rule-of-thumb linter for a weekend and really give
it a try.

~~~
Touche
It's too bad that you can't separate virtual dom, the innovative part of
React, from the rest of React which has its warts. They should receive credit
for coming up with the idea, but there are better, more reactive frameworks
using virtual doms now. React shouldn't win simply because they were first and
have a big company behind them.

~~~
rattray
You can: [https://www.npmjs.com/package/virtual-
dom](https://www.npmjs.com/package/virtual-dom)

You should also check out Mithril:
[https://www.npmjs.com/package/mithril](https://www.npmjs.com/package/mithril)

~~~
Touche
I'm aware of these. But React gets all of the attention despite its warts like
local component state or encouraging singletons for Flux.

~~~
malandrew
And those singletons will bite you hard the moment you try to do server-side
rendering because you will now have state shared across sessions.

The approach that raynos/mercury takes where state is fully decoupled from
layout/rendering is the way to go. In mercury, all the render functions are
composed together to make one large pure function. You give it the current
state and it deterministically will always render the same layout. So much
better than the react approach. Furthermore, the complete decoupling from the
rendering functions and the reliance on using bijective lenses with shallow
copying means you get time travel debugging for free (i.e. undo redo is
available right out of the box)

[https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)

~~~
rnbwd
I discovered React after using Om, and I believe that Mercury comes with a lot
of good practices enabled by default. But it's technically possible to achieve
the exact same 'decoupled-state-pure-shallow-etc' using React. It's just not
turned on by default and some additional boilerplate is needed, so it's harder
to achieve this in React. The only reason I use React instead of Mercury is
that React is battle-tested. No amount of testing can replace the real-world
situations.I choose a path of higher resistance because I trust React most
(due to it's popularity and usage), even though Mercury is better in theory.
Ultimately it's a pattern, and that pattern is associated with a level of
abstraction over the DOM as well as the way we write code. Mercury and React
are two examples of this. I would like to see more competition and libraries
to choose from, modular DOM abstractions, with declarative UI's and
alternative API's and jsx-esc transforms. That'd be awesome IMO.

------
yuchi
Seriously please stop making assumptions on Titanium without knowing a thing
about it.

> With the latter, you're also interfacing directly with native objects all
> the time, which is doomed to fail performance-wise. React Native actually
> performs the layout on a separate thread [...]

Wrong. With Titanium you work with proxies. And JS is in a separate thread.
The only actual difference between ReactNative and Titanium on this side is
the functional/fully-declarative/almost-stateless vs imperative DOM-like
philosophy.

Let me slip this through: «if you don’t know something then don’t make it look
like you do».

Sorry for the rant. I’m just very upset from yet another post like this.

~~~
jlongster
I have a friend that uses Titanium a lot, so yes, I only know of it second
hand.

The lack of a function/reactive componentized UI paradigm forces you to work
with native objects (the views) a lot. React can optimize how much it touches
the bridge because you don't interface directly with the UI. From what I've
seen, Titanium can't do nearly as good of a job as that because it's like the
DOM. You touch the UI in several places and it needs to always talk across the
bridge.

I never said it doesn't run JS on a separate thread. React performs _layout_
on a separate thread, providing the flexbox layout algorithm.

EDIT: It's all of these little details that can make or break something like
this.

~~~
yuchi
For sure there’s this «don’t cross the bridge» paradigm in the community, yet
I’ve never actually experienced this issue. In our biggest app, an SFA that
grew other time in a big fat ass app (project that I’m quitely waiting to chop
in different pieces/apps) the kind of performance issues we found we’re
related to managing tableviews of… 20'000 rows! And then we switched to
dynamically loaded listviews and boom. No perf issues at all.

------
api
I'm looking forward to desktop UIs also being supported by something like this
-- e.g. native Windows, GTK+, and Cocoa widgets. Then we'd have a true
framework for writing GUI apps that can share most of their code across the
whole range of platforms, which would make me literally stand up and start
singing right now. Lalalalalalala!

If you coupled this with conditional stuff around what kind of form factor
you're on (screen size, etc.) you could design mobile first UIs that
gracefully _enriched_ on a larger form factor. Lalalalalala!

I don't know of Facebook cares, but I WILL PAY FOR THIS! For a well-engineered
modern platform that did all of the above I would pay thousands of dollars. So
if the choice comes down to staying free and abandoning this effort vs. making
it a profit center, please for the love of all that is holy take my money.

Really when you look at the labor costs of developing parallel UI efforts on
many platforms, a cross-platform dev system that delivered a _high quality_
native-feeling experience across every major platform could be worth at least
tens of thousands of dollars to millions of people.

~~~
arxii
yep agree 100%. i have been thinking a lot about high quality responsive
hardware accelerated layouts myself and have actually been thinking and
experimenting on how to make something like that on a primitive level with the
technology at hand for making responsive apps.

I honestly believe you will be able to see something like that in the near
future as device gapping technologies gain more momentum.

------
saosebastiao
I love the concepts behind React, and I agree this is a huge deal...I just
wish it weren't javascript. It is a terrible language, and the languages that
compile to javascript are a poor substitute (bloated code sizes, interop
issues, poor runtime performance, etc). For a framework that is all about
state machines (a good thing! All UIs are state machines), I hate that there
aren't better ways to model them in the language. I would kill to be able to
do React in F# or OCaml.

~~~
driverdan
> It is a terrible language

As Douglass Crockford says, JS is a great language with some terrible parts. I
don't understand why some people can't get past that.

~~~
pdpi
Well, then. What about the language should make me think "wow, this actually
_is_ a great language"? And I mean the actual language itself, not the
ecosystem around it.

~~~
woah
With the exception of the bad parts that you have to remember to stay away
from, it is a very simple language.

~~~
pdpi
By definition, if I have to remember to stay away from the bad parts, it can't
possibly be that simple.

------
jobu
Sounds amazing... What are the challenges, limitations, and tradeoffs for
using React Native? There have been similar initial reviews of Titanium,
Phonegap, and Xamarin, but in my experience they all have serious issues that
make native development a better option in most cases.

~~~
jlongster
There's always going to be the big drawback of working in a separate VM
(JavaScript) rather than directly accessing native APIs. But React is taking
advantage of that as much as possible, making it easy to refresh everything
and allowing you bring everything you knew about React.js over.

But if you want to access an API, you still need to wrap it. Depending on the
API, you need to be careful performance-wise. Native React avoids a ton of
problems that other frameworks have though because they provide a solid
mechanism for dynamically working with UIs, and it's very efficient because
they only send minimal diffs across the bridge.

------
abalone
Probably the most useful way to get a read on this is to compare it to
Titanium, also a JS-to-native framework that runs JS on a separate thread. The
biggest problems with Titanium were not performance. A couple of the most
common complaints:

1) You don't have full access to native SDK functionality (e.g. all the latest
cool things in iOS8). You're going through a cross-platform API wrapper and
limited to the choices of the framework architect. So it can be frustrating to
go down this path only to find you still can't quite get the native experience
you want.

2) Debugging is harder because the native toolchain (e.g. Xcode) doesn't
understand the framework. You have to rely on tools provided by the framework.

AFAICS the author doesn't address these issues. He seems to focus largely on
the (theoretical?) performance optimization of not crossing the JS-to-native
bridge as much in React... by being even more isolated from the native APIs
and doing more work in JS. But even if true, performance was not the chief
complaint with the closest predecessor to this.

~~~
jlongster
They are working on web-like APIs so you don't have to necessarily deal with
the native platform for basic stuff like file/network access, etc. For more
advanced stuff it's super simple to make your own wrapper. But yes, this is a
constant downside to anything like this (only thing to compare is how
difficult it is to wrap, and they aren't done with that part yet).

For #2, there's actually a great story. You can literally run the JavaScript
inside an existing engine, like Chrome or Firefox, and serve it from there.
You can use the normal devtools and set breakpoints on the JS.

------
jordanlev
> the mess of HTML and CSS get in the way of frameworks instead of helping
> them

I totally understand where the author is coming from, and do agree... BUT
there is a flip side to this, which is that HTML and CSS enable us to come up
with and implement totally unique designs and interfaces. The lack of standard
layout and complex "widgets" is definitely a pain in the ass, but it also
enables a lot of unique-looking websites and designs. It's kind of a pet peeve
of mine when platforms/CMS's try to output markup instead of just providing
data to the view layer... they are always outputting the "best practice" (if
lucky) at the time they were built, and then a year or two later you want to
do things a different way and you're stuck.

So I'm super excited about React.js and love the simple mental model with flux
etc., but another part of me also worries that one can't dictate the markup
exactly the way one wants because it has to be recognizable to the virtual dom
as well (or the iOS view in native, or whatever other front-end React will
output to). Maybe someone with more React.js experience can enlighten me about
this though? (I've only dabbled).

~~~
danabramov
>one can't dictate the markup exactly the way one wants because it has to be
recognizable to the virtual dom as well

I'm not sure what you mean. On the opposite, with React, you specify _exactly_
the DOM (or UIView) tree you want to get.

You will build different components for React web and React Native, there's no
common ground between them. The platforms are too different.

~~~
jordanlev
I can't seem to find it now, but I remember seeing something a few months back
about support for some HTML tag being added to react. I could be wrong about
that, though (which would be great). I guess my question is this: can
React/JSX render _any_ kind of well-formed arbitrary markup? Like if next week
there is a <doohickey> html tag I want to use, will it work? Or would react
have to be updated to "support it" somehow?

~~~
danabramov
_> I remember seeing something a few months back about support for some HTML
tag being added to react._

It's just due to React <=0.12 using an HTML tag whitelist to tell native tags
from custom components. It's not an issue anymore in 0.13, where any HTML tag
(including custom Web Components) will work:
[https://github.com/facebook/react/pull/2830](https://github.com/facebook/react/pull/2830)

There's still an attribute whitelist, and that's a trickier problem to solve:
[https://github.com/facebook/react/issues/140](https://github.com/facebook/react/issues/140)

~~~
jordanlev
Ah, that makes sense. Thanks!

------
datashovel
I get this weird feeling that React Native has been created as a stand-in
until webview is truly ready to take over mobile. I can't imagine a scenario
where by end of 2015 (or early 2016) mobile webview technology won't be
sufficient for 99% of mobile apps.

------
mhd
So if this is native widgets etc., the main point is being able to write this
in JavaScript, right? Anything in it for those who don't consider this
inherently beneficial?

Souns a lot like GWT, s/Enterprise "architects"/Web "ninja"/ to me.

~~~
eliperkins
It's not about "Write once, run everywhere" but rather about "Learn once,
write everywhere". React-Native encourages better design patterns for UI,
especially on iOS.

This blog post summed it up perfectly for me:
[https://joshaber.github.io/2015/01/30/why-react-native-
matte...](https://joshaber.github.io/2015/01/30/why-react-native-matters/)

~~~
mhd
I don't get the "better design pattern" from that. And even worse, adding yet
another piece on top of the stack (a "better language" transpiling to JS)
instead of just doing "react" in the native environment?

~~~
eliperkins
Doing "react" in the native environment is hard, you have to fight UIKit
really hard to get to a good place.

[ReactiveCocoaLayout]([https://github.com/ReactiveCocoa/ReactiveCocoaLayout](https://github.com/ReactiveCocoa/ReactiveCocoaLayout))
is a good example of how much work it takes to get close to this pattern, but
the view lifecycle as a whole (adding and removing subviews, layout passes,
etc.) makes it hard.

From what I understand React-Native does this for you natively under-the-hood,
but using JS as an implementation detail.

I really don't think that anyone is advocating for JS being the "better
language", but rather one that has a framework (read: React.js) being used in
practice which will work with native view as well.

------
fidotron
OK, so how long before we backport the Android UI toolkit to WebGL using GWT
and get rid of HTML and CSS altogether? Or even just write a sane new one?

Very interesting that this stuff comes from Facebook, who have very little
concern about being indexable by search engines.

~~~
misuba
And yet React for Web browsers is the first framework in its class to do
server-side rendering out of the box... a feature Facebook doesn't even use.
Pretty funny.

------
jsprogrammer
The code style really reminds me of ExtJS circa 2.x (not sure what it's like
now), which was pretty good at what it set out to do. However, React Native
requires compiling down to various different platforms which means having to
maintain multiple compatibility layers to continually shift to keep up with
the native vendors. You're also pretty much stuck with proprietary
distributors as well. Fun. Fun.

This does look interesting, but honestly, I think this can either already, or
very soon, be replicated on the web, a platform which holds tremendous
advantages that native will likely never be able to catch up to. Perhaps
there's an argument that these apps can also be translated to the web when
their time comes, but I wonder what sacrifices are being made in the name of
going Native?

React Native seems to be an attempt to fight in the opposite direction (Web ->
native) while the real momentum is going the other way (native -> Web), and
the best part is, you don't even have to do anything to get it, the major
players are building that open ecosystem for us.

~~~
nwienert
I agree with the "swimming the wrong way" sentiment, in my own very biased
opinion. I'm working on reapp.io to solve just that. What's funny is react
actually makes it possible to make hybrid a real option.

~~~
jsprogrammer
That looks pretty interesting. Are there any plans to support responsive
designs? What I really need (don't we all?) is a unified desktop & mobile code
base.

------
swanify
As someone who has developed many apps using Appcelerator Titanium, I am
looking forward to getting my hands on this to see where the differences lie.

I know that it has taken Titanium years to mature, so I wonder if it will take
a similar amount for React to iron out the bugs - I'll be surprised / pleased
if they hit the ground running.

Hopefully they'll hurry up and make it public!

------
pothibo
I'm assuming React Native can load external JS files over the network? If
that's the case, then I understand why Facebook is building this.

They could have control of their application and behavior and make even more
changes than before without re-submitting to the App Store.

~~~
akx
Except, you know, the App Store rules explicitly forbid downloading new code
over the network.

~~~
misuba
_Unless it 's JavaScript._

...running in a WebView. So yes, RN apps will not enable this.

------
GrinningFool

        "React Native actually performs the layout on
         a separate thread, so the main thread is as free
         as it can possibly be to focus on smooth animations 
         (it also provides flexbox for layout,
         which something that no other framework provides)" 
    

Interestingly - though perhaps increasingly less relevant - this is how
BlackBerry 10 platform native QML-based applications work as well.

------
akrymski
I can't help but feel that all this energy would be better spent on improving
webkit itself (such as running JS in a separate thread to the UI)

------
Taig
For me the best of the web has always been HTML & CSS which I miss so often
when dealing with native widgets or creating my own. The only thing that used
to scare me off the web was JavaScript. Give me a HTML & CSS frontend, please.
But let me keep my beloved Scala or Swift ;)

------
serve_yay
I'm still very excited to try it. I agree that this is the way forward for
writing apps. I have attempted to write iOS apps before, and the problem is
not objc, I actually kinda like objc. The problem is the damn view layer.

------
falcolas
Didn't we do this already with Qt? Or Java? Or wxWidgets? Or OpenGL? Seems
like cross-platform UIs have been a reality for quite some time.

What does React bring to the table that these do not?

~~~
state
Isn't it just the specific platforms you can target? I think the point is that
there's nothing that can target the browser and the phone this successfully.

------
bsaul
Wonder if the ability to easily refresh the view will make a difference to ios
dev used to the wysiwyg approach by xcode for building views.

------
malandrew
This is yet another reason why you shouldn't use animations in CSS3 and should
do them in JavaScript. I honestly don't understand how behavior (which is what
animations are) got baked into a declarative style language.

Layout (which is also behavior if the layout changes with the dimensions of
the viewport) and animations are two things that need to be removed from CSS
and implemented in JavaScript.

~~~
untog
Well, "should" isn't a great word in this context.

Yes, animations probably _should_ be in JavaScript, but you probably _shouldn
't_ do them in JavaScript right now as they won't be hardware accelerated. The
reason it works well in CSS is that you're setting a property and letting
native code do the rest, whereas in JS you need to set a property in each
requestAnimationFrame() call. Not good.

------
arxii
sounds interesting. not a fan on reacts workflow because i use jade templates
w/ backbone that get compiled to html for me and its much less code, but
separating javascript and native components into different threads is a great
idea.

i believe we should be able to see javascript being used as a responsive
language portable across all devices and being used to control native
components as a separate layer.

im actually working with a flexbox xml/html wrapper framework for iscroll that
i might use to build a responsive app that not only does pc animations but
performs alot of nice mobile slider animations that seem to go at 60 fps on
modern handhelds, but its up to emerging gapping technologies like cordova and
this to make the use of future "responsive ui kits" which i believe should be
emerging soon.

------
regularfry
Soooo... Strap a code editor component on the front and call it Hypercard
9000?

------
crazychrome
Do a Ctrl + F, then type "android". How many matches have you seen amongst
122+ comments? 2, including this one!

------
crudbug
This made me think differently => JS can be used as a control layer and the
native components are the data layer.

------
eclipxe
Why not Titanium?

------
coldcode
Will React's concepts every make it as truly native code I wonder?

------
zkhalique
OK this DOM stuff is great but what about the other HTML5 interfaces, like
sending requests to the server, localStorage, etc. ?

~~~
peterhunt
There is an API-compatible XMLHTTPRequest so all libs that have those deps
(Backbone) work.

There is also localStorage (not in this release though), but it's not 100%
compatible because it has an async API.

~~~
Bahamut
Is the localStorage going to be something similar to IndexedDB (or localForage
perhaps?)

~~~
peterhunt
When I was at FB it was just getItem() and setItem() with a callback. The
Relay stuff announced at React.js Conf is closer to what you're talking about
(they run a local GraphQL engine which reconciles with the remote one iirc)

