
What do you dislike about React Native? - daanavitch
https://github.com/react-native-community/discussions-and-proposals/issues/64
======
throwaway66666
I will probably be heavily downvoted but here goes nothing. I have not used
React Native yet, but I followed and was heavily invested in the "write once
deploy anywhere" trend between 2009 - 2014.

From phonegap (before it became cordova), to Adobe Air with it's bad
performance and "native extensions", to Appcelerator Titanium that put a
nodejs server in your phone and even had Windows Phone 7 support, to cordova,
to Haxe, to sencha and others. Appcelerator Titanium was the only ones that
did real native for some cases like scrollviews, Haxe used custom C++ apis,
the rest used webviews, and adobe air was basically flash emulated that ran
like shit.

Write once deploy anywhere, meant write once, deploy somewhat anywhere, spend
double the time to make that promise true. Kinda like having to do IE6 support
in the past. I was deep in that madness up until mid-2014. At that point I
decided to buy a macbook and give native development a try (obj-c for ios and
java for android -- When I say native I mean real native and not React
Native).

What a magical experience! Things that are tough to do in web even today, like
real never-ending scroll lists, are a breeze in native with their reusable
cells. Things like standard headers and modals, are already built in and a few
lines away. And I actually prefer the touch event handlers on both ios and
android to the web's "mouse/touch/PointerEvents" ones.

I do not understand why web developers have such a knee jerk reaction to
native development. ObjectiveC/Swift and Java are actually easy to write.
Tooling (especially for ios) is fantastic. In my experience, it is much faster
to write UI interfaces in Objective C and Swift (I never use xcode's UI
builder) than html+JS. But the real joy is being able to harness the real
power of your phone. I run some C++ algorithms on both ios and android (I
guess C/C++ is the original cross platform) that on android are faster than
the built-in Java apis themselves! And of course, true multithreading!

But here we are, non-stop chasing the "no! I want javascript in my frontend,
and in my servers, and javascript in my ios apps and android too!" dream.

Perhaps React Native accomplishes that. I hope it really does and solves that
decade-long promise of "write once deploy anywhere". I guess all what I 'm
trying to say is, don't be afraid of native people! Web devs are willing to go
through insane hoops and loops instead of just... giving the real thing a go.
So weird.

~~~
rolleiflex
Everyone intrinsically understands that native is better, and I'm saying this
as somebody who runs a 120k LoC Electron app
([https://getaether.net](https://getaether.net)) myself.

I'm painfully aware that native is better, all day, every day.

The problem is this: I'm a solo founder. I am both the engineer and designer
(and PM). The alternative for me would be not to write a Mac app, a Windows
app, and a Linux app separately, and have them work.

The alternative would be for Aether to _not exist_.

You're expressing a sentiment that everyone feels, but you're off on why —
it's not change aversion, but the simple fact that these technologies make
trying new things cheaper, things, by definition, that would be too expensive
to try in slower-to-build tech.

In my case, a compromise I found worked was to use JS for just the UI and
write all code that does something in Go. Since that code is native binary,
it's fast and efficient. Vue in Electron handles the 'client' UI, and
interacts with the Go app binaries via gRPC.

~~~
SneakerXZ
But why Electron? There are other cross-platform solutions with great
performance.

~~~
devwastaken
There are no equivalents to electron. You either use a browser, or you get
stuck in someone else's lacking UI, like qt. Electron just works, and that's
why it's everywhere.

~~~
IloveHN84
Qt actually performs better than Electron and works everywhere and

~~~
d0m
What you want is cross-platform:

    
    
      - Web (IE, Safari, Firefox, Chrome, and older versions of those browsers)
      - Web responsive (When you access it from small screens or access the web from your phone's browser)
      - Android (old devices to recent ones)
      - iOS (old devices to recent ones)
      - And, eventually, get to a desktop app, ideally on windows, mac and linux.
    

Say you're the tech lead and you need to make a decision about the stack to
support all these platforms, and you're a team of 2-3 devs, yourself included.
What stack do you pick?

~~~
fitpolar
The fact is, only very rarely are you in a team of 2-3 devs and you need to
support ALL of these platforms. If that’s the case for a small startup,
serious strategic errors and lack of focus is being made by the founders!

Even Instagram didn’t even have an Android app until they were acquired, and
then it still took them another couple of years to support web. Their focus
was their success.

~~~
elithrar
To be fair, Instagram didn’t have an Android app a long while ago. The Android
market & demographic has changed a lot since, with high-end Android phones
sporting great screens, cameras and costing nearly as much as the iPhone.

An Instagram launching today would see much greater pressure to be on Android
sooner rather than later.

~~~
fitpolar
That’s true, and a good point that I should take into account when confronted
with this decision in future.

------
JoeCortopassi
Companies and teams don’t usually pick non-native solutions because they're
better tech. Non-native solutions are picked so that teams can be more
efficient with their time/resources. For some teams, that means delivering an
app cheaper. For other teams, that means being able to spread resources
thinner and stretch budgets. This doesn't have to be a bad thing per se, it's
just a business decision.

As a former iOS engineer, I for one really enjoy React Native. But I feel like
it's focus is trying to maintain/supersede native development, where it's time
and attention would be better served focusing on the efficiency of average
developers on average tasks

~~~
holografix
Great insight. How can we use something similar to Interface Builder to create
React Native apps?

------
pauliusj
For me it feels like RN is still not ready for an enjoyable development
experience (it feels more around alpha/beta version), which maybe it is
because the version is 0.57 or somewhere around that. The main problems I have
with RN are:

* Cryptic error messages. Out of maybe hundreds of errors/crashes I had while developing a medium sized app, only a few of them provided useful info about what/where happened.

* Lot's of outdated/abandonware/low-quality libs in the ecosystem. You really have to be careful when picking the dependencies.

* Fragile and complex builds. You'll have to use dependencies to make anything more than a basic app (unless you want to DIY), so get ready for some "fun" when upgrading the project because not all of the dependencies will be upgraded at the same time, might also often have the APK/IPA or development builds fail because of dependencies not properly installing or not playing nicely with one another.

* Lots of little stuff. For example, I had the ios simulator logs not work out of the box when launching with "react-native log-ios", so had to use a third-party solution for that. Metro bundler sometimes just breaks. I still have a problem of the app randomly closing down after some time on iOS, which I did not look deeply into yet but will have to solve before release. Constant issues with nesting scroll views on android. Hard to predict cross-platform inconsistencies in layout behaviour in some places. Can't name everything right now but they played on the nerves throughout the development.

I hope it gets better some day, but until then I'll probably look for
alternatives for my next project as I wasn't very happy with RN.

~~~
JofArnold
This is a good and fair summary. It is a frustrating developer experience for
sure - especially Android.

------
pier25
I tried RN in early 2016 but Android support and documentation were not great.

Honestly, I've always thought that RN (and similar approaches) is kinda a
hack. Yes, it solves a problem of reducing developer time across platforms,
but it introduces other more obscure problems. A JavaScript engine with it's
own set of problems giving orders through some bridge to the native part... I
don't know, it's a lot of moving pieces.

I feel Flutter is so much more solid in this respect. The approach has been
used countless times by game engines such as Unity, UE, etc. The part where
Google has to replicate the UI elements of each platform is not amazing, but
otherwise I feel it's a much more solid approach than RN.

~~~
darpa_escapee
I got a similar impression from ReactNative: it felt like a hack, and the hack
came apart at the seams if you tried to debug it.

Similarly, Flutter felt much more like a cohesive solution compared to RN.

------
dep_b
* Javascript

* NPM

* It's still 0.59 or something and things are constantly breaking

* Because of that every piece of information older than 1 month should be distrusted

* App size

* It doesn't play well when you try to gradually replace or add RN screens to an existing application.

* There are multiple ways to do the same thing

* It adds another layer on top of the iOS and Android builds

~~~
EpicEng
* Javascript

* NPM

* It's still 0.59 or something and things are constantly breaking

* Because of that every piece of information older than 1 month should be distrusted

* App size

* It doesn't play well when you try to gradually replace or add RN screens to an existing application.

* There are multiple ways to do the same thing

* It adds another layer on top of the iOS and Android builds

~~~
dep_b
Thanks! Fixed it.

------
malvosenior
You can develop native apps in languages that range from ok, to really good
(Java -> Swift). Javascript is a terrible language for many reasons (lack of a
decent standard lib, weak typing, foot guns galore, psychotic build pipeline
and tooling...). React Native encourages more JS development so I dislike it
for that reason.

~~~
cityzen
Thanks for "foot guns". Have never heard it but like it!

------
vmarsy
it'd be cool if there was a simple way to create typescript react-native app,
similar to create-react-native-app[1] without a dependency on Babel[2]

[1] [https://facebook.github.io/react-
native/blog/2017/03/13/intr...](https://facebook.github.io/react-
native/blog/2017/03/13/introducing-create-react-native-app)

[2] [https://facebook.github.io/react-
native/blog/2018/05/07/usin...](https://facebook.github.io/react-
native/blog/2018/05/07/using-typescript-with-react-native)

------
debt
It would be tight if we could purge from the web all posts and threads related
to unsupported and outdated ReactNative versions.

It's actually quite interesting to see the almost in real-time development of
ReactNative through the lens of hobbled and broke-ass solutions to problems
associated with deprecated RN versions posted on StackOverflow or Medium.

~~~
burtonator
This is actually a problem that could be solved by naming actually.

Angular has a similar problem because if you search for an olde version of
Angular you get 2.x and they're up to 7 now...

I think at some point it makes sense to rename the project to avoid the cruft
of the past when it really deserves it.

~~~
EpicEng
I'm emphatically _not_ a front end dev, but recently I've needed to do some
front end work on an existing AngularJs project. It took me about an hour to
realize that AngularJs != Angular. A bunch of examples weren't working and I
just couldn't figure out why...

------
reverite
A few friends and I have noticed that applications that are using React
Native, even in the best of situations in optimizing, it still drains battery
life faster (sometimes far faster) than something written in Java/Kotlin or
ObjC/Swift.

~~~
fitpolar
Do you have any examples of that, and how do you determine which apps are
built with RN?

I've noticed a similar thing, but have nothing to go on but my gut instinct.
For instance, I'm pretty sure that the food ordering app Ritual is using RN,
it just doesn't feel quite native.

~~~
reverite
I'm a little late to reply. I use Discord and Slack a lot which uses RN but
I've noticed that there are frame stutters when scrolling or when viewing
gifs, and other chat applications like Telegram (native) do not have this
problem. The stuttering is how I notice if they're using RN or not here.

------
shujito
app bloat, the app size is too big for a simple example

------
alsothrownaway
I think it's constructive to point out that maybe the entire project, being a
"hack" of sorts that tends to breed more hacks and more debt, ultimately isn't
useful or valuable. The idea is wonderful, but in practice I still have to
maintain cross-platform code that has nothing to do with wireup, and honestly
think everyone should seriously consider writing portable code and plugging it
into truly native projects.

React Native multiplies the complexity of a project so much that IMHO it
completely negates its own usefulness.

