
React Native: Initial Thoughts - kaishin
http://unredacted.redalemeden.com/2015/initial-thoughts-about-react-native/
======
Kesty
When "The Bad" list start with the single word Javascript, it loses a lot of
credibility for any unbiased judgment.

~~~
lucian1900
But JavaScript _is_ a bad language, objectively. There's little debate on that
subject.

Most of us use it because we have to, even though there are much better
languages available.

~~~
ceejayoz
> Most of us use it because we have to, even though there are much better
> languages available.

Node's popularity is a pretty dramatic counterexample to that assertion.

~~~
smt88
> _Node 's popularity is a pretty dramatic counterexample to that assertion._

Popularity has nothing to do with quality. Node is popular because so many
people knew JavaScript anyway. JavaScript is popular because it was the only
widely-supported programming language for the browser (other than
ActionScript, which is itself an ECMAScript flavor).

~~~
shiggerino
> Node is popular because so many people knew JavaScript anyway.

Is that true, though? I see very few JavaScript developers with a solid
background in computer science or software engineering on the job market,
compared to the demand these days, as more and more stuff goes to the browser
or native HTML applications. Taking kids out of web design schools is too much
of a gamble unless you already have a senior JS dev on the team to keep an eye
on them.

But then again it might be different in places like Silicon Valley.

~~~
smt88
> _Is that true, though? I see very few JavaScript developers with a solid
> background in computer science or software engineering on the job market_

That's exactly my point. A huge amount of labor for developing web apps are
people who have _not_ come from CS/engineering backgrounds. They're self-
taught, and a lot of them started with web technologies.

So it was really easy for those people to transition into backend development
because they already knew JavaScript.

------
acdlite
> Flexbox. The authors missed the opportunity of offering a saner API and
> favored sticking to the official spec instead.

Flexbox _is_ the saner API we've all be waiting for, in my opinion. I'm
curious what the author's objections to it are. That's really my problem with
the whole piece — statements like this are thrown out there without much
justification or explanation.

~~~
thramp
I'd much rather be writing apps using constraint-based layout, much like
AutoLayout. It took me a while to grok it, but it's much simpler once you get
it.

~~~
acdlite
I disagree, but I suppose this a matter of preference. For whatever it's
worth, the React team did explore using a constraint-solver, but nixed the
idea. They explain their reasoning here:
[https://www.youtube.com/watch?v=7rDsRXj9-cU&t=14m20s](https://www.youtube.com/watch?v=7rDsRXj9-cU&t=14m20s)

~~~
thramp
Yeah, it is preference. I found that buying entirely into Autolayout +
Storyboards makes for a _really_ nice development experience.

And their reasoning makes sense. I totally get why they would avoid
constraint-based layout.

------
bryanlarsen
Component-based file structure is firmly in the "good" column for me. It makes
small components much more feasible.

If you're forced to split out your view, your template, your stylesheet, your
controller, your model, your business logic, et cetera into separate files you
are forced to keep components large.

However, if you have a component-based structure, whenever you notice a very
small piece of common functionality it becomes trivial to create a new
component for that functionality. You end up with a very large number of very
small, very easy to understand components, with clear areas of responsibility.

~~~
marknutter
> If you're forced to split out your view, your template, your stylesheet,
> your controller, your model, your business logic, et cetera into separate
> files you are forced to keep components large.

Why exactly does this force you to keep your components large?

~~~
bryanlarsen
A typical component in my React app contains about 3 lines of HTML. Have you
ever seen a 3 line HTML template?

~~~
ben336
I have. Not uncommon in Backbone development for instance to keep templates in
separate files from the views. If the templates are short you can inline them,
but sometimes its easier to just be consistent and give every template its own
file. It definitely does add friction compared to React though.

------
jk5_
> Flexbox. The authors missed the opportunity of offering a saner API and
> favored sticking to the official spec instead.

This is located in « The Meh » section. IMHO, it should be in the « The Good
». Using the official spec instead of reinventing the wheel is always a good
move.

~~~
Cshelton
I think in either the first or second keynote back to when React native was
announced they talked about their reasoning behind using flexbox. I think it's
also 'the good'. They were able to use a web technology and make it work in
react native just as if it's the browser, pretty impressive. If they had to
come up with their own 'css' style layout api I would then have put it in 'the
bad' myself.

------
aboodman
"Component-based file structure. Handling styles, view hierarchy, and business
logic all in one file is a step backwards. Poor style reusability is one
direct consequence of this approach."

If only there was some way to pull out a hunk of code so that it could be
reused. Hm. Somebody should invent that.

------
pjmlp
For me QML/C++ (or other C++ UIs) and Xamarin make much more sense for native
mobile coders.

\- Better native integration

\- Integration with the SDK tooling

\- Support of all three major mobile platforms

\- Performance

As soon as I saw what React Native offers, it was meh for me.

~~~
zura
I wish Qt Widgets (C++, not QML) was more mobile friendly... Xamarin will be
good when it finally becomes free (acquired by MS?), or at least gains more
indie-friendly license.

API-wise, MoSync really stands out. Unfortunately, it is dead now. Same goes
for Adobe Flex/AIR.

~~~
pjmlp
Xamarin prices are quite good when one takes into account developer salaries
and saved time.

Personally, I would also like more Qt Widgets love, but only due to binary
size.

------
tariqr
"StyleSheet is not CSS. You will be quickly disappointed if you adventure
outside the few CSS-inspired properties that React Native ships with." < I can
see how that can be quite annoying, everytime you want to use a property,
you'd have to go back and check if RN supports it.

Maybe there will be stronger overlap in the long run.

~~~
colinramsay
The one pain point I can see coming up again and again is that the way of
making something full-width isn't to specify "width:100%" but instead to use
flexbox. While that makes sense to me, I've already seen quite a few people
(on SO for example) tripping up on this.

For the rest of the properties I imagine anything that's really needed will be
coming - many seem trivial to implement.

------
ksherlock
I played around with it a bit over the weekend. You can call it native, but at
the same time, it's not completely native. For example, there is no
UITableView support. That's one of the most common ways to present data. Hell,
one of the first things I tried to do. (There is a bug report. They tried to
support it but the code was ugly and didn't really play well with react-native
so it was dropped).

You can create a ListView and the performance (and feel) are great, but it's
not a UITableView. You can draw a chevron and make it kind of look like a
UITableView but if you have to manually re-create the native UI, it's not
really native anymore, is it?

It certainly is slick to get instantaneous feedback when you edit your
javascript file, though.

~~~
woah
I don't ever find myself using the default uitableview much, usually it will
contain completely custom cells. Does their ersatz table view have any issues
beyond the lack of a chevron?

------
vjeux
> Styling nested view controllers is a pain. You are taken back to the root
> view controller after each refresh.

It's so interesting how once you get used to instant feedback loop, anything
that's longer is perceived as a pain. We want to find a solution for this
though :)

------
legacy2013
Why is Chrome Developer Tools meh?

It's something people are familiar with and has a full debugging suite

~~~
rickyc091
"Chrome Dev Tools. Browsers are doing too much already."

I think he's trying to convey that the browser is getting too bloated and that
there should perhaps be a native app to handle the debugging.

~~~
colinramsay
Which is daft, because to produce a separate app specifically for debugging
React Native would be a huge undertaking with zero extra benefit. Chrome's Dev
Tools are best in breed (IMO) and it makes sense to leverage them.

If there were things being added to Chrome Dev Tools specifically to support
React Native, that'd be different.

~~~
15155
Blink Devtools are used widely. node-inspector is another isolated use case,
and is quite popular.

------
bkurtz13
OP mentions you can enable auto refresh, instead of having to Command + R
every time I assume. I couldn't find that info anywhere, does anyone know how
to do that? I'm really used to that workflow now with Figwheel + Om.

~~~
bradleyboy
See:
[https://twitter.com/ryanflorence/status/582016664847290368](https://twitter.com/ryanflorence/status/582016664847290368)

~~~
bkurtz13
Awesome, thanks. That should really be mentioned in the Quick Start and/or
Tutorial in the docs. I think a lot of people would really appreciate that
feature. :)

~~~
bradleyboy
Looks like it got added to the Debugging page in the docs yesterday:
[http://facebook.github.io/react-
native/docs/debugging.html#c...](http://facebook.github.io/react-
native/docs/debugging.html#content)

------
agmcleod
I think these are fair concerns, but it also sounds like this person comes
from a more iOS native development background. Why not stick with that? I like
the idea of react native as i use react more and more in the browser, and I
enjoy the workflow.

~~~
edgyswingset
> Why not stick with that?

Eventually it'll be available for Android, so that's a valid reason.

~~~
agmcleod
I thought the APIs would still be different though. Maybe not. Either way, I
think it's great for people who do use native to try new tools. But yeah I can
accept that they will probably miss certain features.

------
badlogic
While react-native isn't for me, some of the features are really nice. Hotswap
for mobile development is definitely a very nice thing to have. I do wonder
how that handles app state. Is only the UI reloaded or all of the code?

~~~
colinramsay
At the moment I believe it's everything JS-side. It's not like webpack hot-
swapping where just the component gets replaced. The one caveat is that if
you've got a native module written in Obj-C obviously you'll need a full
rebuild to see any changes there.

------
UUMMUU
He knows they just released it right? A good number of "The Bad" should
probably be seen as coming soon. Probably could've named those "will be better
when..." Especially Stylesheet and Swift support.

------
tel
Is there an FRP library in iOS? The author states that React "feels superior"
than FRP, so I'm curious what the comparison was.

~~~
lazerwalker
ReactiveCocoa is a fairly mature FRP library from GitHub.

It strikes me as a funny comparison. I agree that the react approach can feel
like a better fit than FRP at the view layer, but it's not like there aren't
positive reasons to use FRP/signal-based programming in your model layer or
when wiring up your models to React views.

~~~
wahnfrieden
View as function of model isn't a concept foreign to FRP either - MVVM is a
common pattern together with ReactiveCocoa.

------
ExpiredLink
> _Immutable user interface. You no longer have to track state in both the
> model and the view; the latter is a function of the former. As soon as the
> model changes, React Native re-renders a virtual tree of the view hierarchy,
> then applies the delta to the native views._

The meaning of 'immutable' must have changed lately.

~~~
erikpukinskis
Can you help me understand which part of that you think stertches the
definition of immutability too far? The developer doesn't change the UI state,
it is just a pure function applied to the domain state. Is it the fast path
they implemented that does the diffing to speed up the function that bothers
you?

------
dheera
Has anyone compared React Native to Appcelerator Titanium?

~~~
ltb
It's a bit like comparing a particle accelerator to a bagel. Easier to explain
them each on their own. Try running through some sample code of both to feel
out the philosophy.

------
0x0
Any further thoughts on the apparently controversial PATENTS file?
[https://github.com/facebook/react-
native/blob/master/PATENTS](https://github.com/facebook/react-
native/blob/master/PATENTS)

~~~
colinramsay
It ruins every single discussion on the topic when armchair lawyers wade in. I
have no doubt that we'll see commenters now provide their own opinions on this
clause without having the faintest idea of what they're talking about.

If nothing else, the list of very large companies making use of React,
seemingly without concern, makes me unworried about this.

~~~
aggronn
I agree that having this issue dominate discussion is incredibly annoying,
however I have to say, Facebook needs to make this more clear. There should
not be confusion about this.

~~~
colinramsay
This, I do agree with. Like I say, I'm not bothered about this issue, but I'm
sick to death of seeing the endless stream of internet warriors throwing
themselves at it. A clarification blog post would help a lot.

