
Going Mobile With React Native - Fermin
https://blog.clubhouse.io/going-mobile-with-react-native-891e1a602465
======
LeoNatan25
“When you build your application in React Native, you are still running native
code in an native app using a native framework. The Javascript framework is
just handling the business logic.”

No, this is incorrect. Using merely UIView objects does not mean it is native.
It’s not just an abstraction over native. Unlike something like NativeScript,
the “great” minds at Facebook have decided to not only offer a JS wrapper
around the native, but actually reinvent the wheel on everything. Tables?
Let’s have a horrible implementation in JS. Gestures? In JS. Navigation? In
JS. Animations? Core Animation you say? Nope. Even simple stuff like buttons
are not native UIButton objects. There is nothing “native” in React Native.

Also, the single threaded model of JS just does not scale. The larger the app
gets, the more and more it starts to lag. UI is rendering at 60 FPS, sure, but
the lag comes from a constantly busy single JS thread.

And that’s before mentioning things like accessibility, large type support,
basic iOS concepts such as margins and layout guides, etc. that are sorely
missing from RN.

You want a ‘great’ tip? Don’t cheap out; hire native developers. Otherwise
your users will suffer a lackluster and inferior product that looks nothing
like the platform it’s running on.

~~~
whizzkid
[https://facebook.github.io/react-
native/showcase.html](https://facebook.github.io/react-native/showcase.html)

I use some of the apps that are listed above, and I don't really have a
problem with the performance.

Can you explain little bit more on how not using the native components can be
big problem when your app gets bigger? I am asking because i really consider
using React Native.

Or maybe give an example under which circumstances will those app fail to
perform?

I used Cordova and the "lag" makes it clear from the first 5 seconds that it
is not a native app. But i haven't experienced it from the apps that they
listed on their page.

~~~
martinald
The single threaded nature is a big problem. I have led teams building large
RN apps and it is then #1 problem we experience at scale.

The worst bit is that you can only pass strings between threads in JS. Which
means you have a lot of serialisation and deserialisation overhead, which can
become the cause of UI slowdowns itself, which is a whole world of pain.

~~~
JustSomeNobody
What does "at scale" mean in this context (mobile application)?

~~~
LeoNatan25
It means an application that is beyond displaying a short list in a two —
three screens. Once you start having a real business logic, you hit the
relatively low ceiling. And the usual advice of “if you need more, just write
a native component” — a. does not scale in performance either and b. what’s
the point, just write in native in the first place and save yourself the
headache of having to learn or hire native developers at moment of crisis.

~~~
atoko
Delegate the business logic to a server, I'm not sure what kind of "real
business logic" needs to live in a mobile app

~~~
LeoNatan25
Then you don’t understand mobile development. There is absolutely no need to
run business logic that can run on mobile on a server. Mobile devices today
are more powerful than the majority of laptops out there.

~~~
atoko
Such as? Still no examples, I see.

Without a real architecture you don't get to complain that a hamhanded
solution is less than optimal

~~~
LeoNatan25
For example, a mail app, a chat app. Would not scale at all with RN (or mobile
web in web view). Imagine having to preload hundreds or thousand messages or
other existing content while the user is viewing or typing. None of that is
applicable to "server side business logic". Not if you want a quality app.

~~~
doublerebel
This is false, mail and chat apps work fine with multiple hybrid app
frameworks. I've created plenty of hybrid apps that have 100s of items in
lists, this is what ListViews are designed for. There's no limitation inherent
to hybrid apps that prevents holding 1000s of objects in memory. This also
works fine on mobile web if it's designed right.

If the mobile client can't handle 100,000 messages (probably more an issue of
bandwidth or latency than local memory), then page them from the server.
That's where serverside becomes relevant, at huge scale.

I'm not sure you understand how architecture of a mail or chat app would work.

~~~
LeoNatan25
In the past, I have built both a large enterprise-grade mail/calendar/contacts
app which interfaces with Exchange, as well as a chat app:

[https://www.checkpoint.com/products/capsule-
workspace/#overv...](https://www.checkpoint.com/products/capsule-
workspace/#overview)

[https://itunes.apple.com/il/app/check-point-capsule-
workspac...](https://itunes.apple.com/il/app/check-point-capsule-
workspace/id522091441?mt=8)

RN list views are terrible, as all the data is held in memory. For a chat or a
mail apps, that's catastrophic. "Paging on the server" is not a solution;
users want all their data on the device.

In my previous comment, I actually meant a different scenario than displaying
a list. Take any proper mail client or a chat app; the first thing they do
once a user logs in is start preloading previous data that can be found in
cloud / on the server. Depending on the amount of data available, that is a
very serious undertaking in and of itself, doing it efficiently enough in the
background while updating the UI where needed upon insertion. This is just not
possible in a single-threaded JavaScript.

Your mindset of only holding a small subset of data on the mobile is erroneous
and is empirically not what users want; it's a web mentality and has no place
in any app development but web. We went with this approach, albeit for
security reasons. The result was the vast majority of users were unhappy.
Users wanted a full blown Outlook in their mobile, and there was no reason not
to give it to them.

~~~
doublerebel
I don't see how any of this is a limitation of React Native and not a result
of poor app architecture. If a list is too big to fit in RAM, but not too big
for the device, page it from the local SQlite DB. All kinds of web and mobile
apps asynchronously fetch remote data while keeping a responsive UI. There are
also service workers and other ways to prioritize UI.

The vast majority of popular chat and email apps keep at least some of the
data on the server by default -- Gmail, K9 mail, Outlook itself -- so I don't
see where there is proof that users want something different.

~~~
martinald
The problem is paging the local SQlite DB requires you to use the main UI
thread without causing nasty bugs.

The main problem is large redux objects, which you're right - needs major
refactoring. It's a pain.

------
pawelwentpawel
I work with both native iOS and React Native on daily basis. Both had their
own (dis)advantages and it's hard to have a definite answer on which is
better. It all depends on the nature of the app you want to build, your budget
and trade-offs you are willing to take. RN is moving fast and has improved a
lot in the recent months but still has some pain points:

\- If you want to build a chat app, forget about well working sticky text
input. ([https://github.com/facebook/react-
native/issues/371](https://github.com/facebook/react-native/issues/371))

\- All the dev time you have saved with hot reloading will be lost if you hit
the infamous 4968 ([https://github.com/facebook/react-
native/issues/4968](https://github.com/facebook/react-native/issues/4968))

\- Multithreading, but that has been covered in other comments. If you're
obsessed about buttery smooth UI you'll have some unpleasant time.

Also :

\- I find RN's ecosystem feeble and don't trust packages. Triple check
everything you run npm install on.

\- Using solely RN/JS is not an excuse to completely avoid learning native
development. It bites in the future.

\+ ScrollViews are great.

\+ Build times are shorter, you get quicker feedback especially for UI small
modifications.

\+ I really enjoy working with RN's Animated API.

~~~
udfalkso
This is a good list of pros and cons. I'd just add this:

\+ App also runs on Android (and even web, and tvos)

I'm always surprised when people don't list this massive benefit when
discussing RN. It's really the core value proposition. The fact that it's even
in the conversation when developing for only one platform seems like quite an
endorsement of the developer experience with RN.

~~~
pawelwentpawel
Definitely. That is also my main reason for mentioning the budget - building
one app for multiple platforms is (usually...) cheaper.

------
prodtorok
As a professional JS and iOS developer, I have to say that React Native is not
the way to ever go unless you need to quickly prototype proof-of-concepts. I'm
in love with React, but not RN.

Apps just don't feel right (like something is off but you can't tell what),
annoying bugs, hacky open source modules, and the fear that it will never live
up to it's hype or be able to keep up with native apis.

If you need a quick poc, then use what you're most comfortable with. If your
app is simple enough to make in RN, then do it in native. If your app is
complicated then you won't be able to do it (successfully) in RN anyway.

------
wimagguc
It's not really tips, is it, it's just a high-level React-Native-exists
article. While I'm on though, what I'd really want to see in the next great-
tips article are:

(1) How to make a project more future-proof? (Try it yourself: download any
React Native demo app from the past 1-2 years, and see how many of those
compiles without complaining about version, platform, what-not.)

(2) An actual cost analysis of a React Native project. My experience is that
since most developers are still just learning RN, the good ones are too
expensive or too busy, and you'll actually end up paying more for the same
app.

~~~
mkalygin
I can confirm the (1) problem. Recently I've tried to compile the app which
was built in March 2017 and this was unpleasant and painful process: lots of
build errors, version inconsistencies, etc.

Regarding (2) I think that good developers are always expensive, no matter
which technology they use.

------
k__
React-Native is pretty good, mostly feels like doing regular React (web)
development.

And if you get perf problems, just write things in the native languages with a
bridge.

Not THE way to do mobile apps, but if you already know React, it's the way to
go.

------
mcbobbington
The newer react-navigation is actually a decent router. Before that the
routing options were pretty bad

