
State of React Native 2018 - acemarke
https://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018
======
plopz
The biggest problem I've run into with React Native has been their handling of
issues. Far too frequently I'll google an issue I'm having and click a link to
a bug report that matches the exact problem I'm having and provides a repro
only to see that the issue was closed for inactivity. Never mind the issue is
still valid, and the comments on the issue will ask for it to be re-opened and
the response is to open a new issue.

So then you start this goose chase of hunting down the current issue since it
starts getting into this loop of closed, open a new issue, closed, open a new
issue, closed, open a new issue, etc. And everytime this happens relevant
information gets lots because its not transferred to the new issue.

And then you finally find the newest, currently active iteration of the issue
and find out that its still not fixed and the workaround is to stop using the
React Native version and re-implement the feature yourself natively on both
ios and android.

~~~
hysan
I remember asking about this on Reddit and got a response from someone on the
RN team.[1]

> In practice this means that we have issues coming in, but we never close
> them when they are fixed, causing them to pile up. So we decided that the
> best thing we could do is mark them as stale and close old issues that
> nobody has commented on in a while. If we mistakenly closed something that
> is still an issue, the community will let us know and we can reopen it.

The discussion I had with them was interesting, but it didn't leave me feeling
like anything would really change. Seeing your comment reminded me of this and
I guess the status quo has remained.

[1]
[https://ps.reddit.com/r/reactnative/comments/7wqxjy/why_are_...](https://ps.reddit.com/r/reactnative/comments/7wqxjy/why_are_so_many_issues_being_closed_without_being/)

~~~
ak39
I can't seem to understand what the problem with "pile up" is? The whole idea
of logging issues is to see how long they're open for! In fact good projects
take the painstaking exercise to coalesce tickets that are in fact the same
with an original item IN ORDER TO track the correct age of the ticket.

This sounds totally backwards.

~~~
workinthehead
Nope, wrong on all counts. You need to delete stale issues, it's no good
having an endless backlog of someone's nice-to-haves that they no longer even
care about.

And, the "whole idea" of logging issues is not to see how long they are open
for... it's to, you know, log issues, because they can't be fixed
instantaneously. Measuring how long they are open for is just a pointy-haired
boss side effect, because those are the kind of idiots that would think that
kind of metric means anything.

~~~
allthenews
>Measuring how long they are open for is just a pointy-haired boss side
effect...kind of metric means anything.

I don't think such cynicism is warranted. Open issue time is a useful metric,
at the very least over time, of how quickly developers are fixing problems and
how complex they are becoming.

Certainly not something for a pointy haired boss to optimize exclusively for,
but a useful bit of data to be taken into consideration with other
measurements of performance.

~~~
bonesss
Of all the KPIs for development teams, how-f-ing-long-will-it-take is a pretty
'key' one, IMO.

It's not the only factor, it's highly product dependent, but it is very
relevant to most outward facing activity...

------
rawrmaan
Lots of negative or neutral posts in here, so let me chime in: I love React
Native.

It’s not perfect, but it’s very damn good. One of the most impressive pieces
of software I’ve encountered in 9+ years of mobile and full stack development.

I do all my projects in RN now, and I believe it gives me a 2-3x iteration
speed advantage over my competitors with indistinguishable-from-native
interactions (using react-native-navigation) and the ability to be on all
platforms. For a solo dev, these advantages are insanely powerful and are the
major reasons that my business is viable.

Last year I rewrote my game Falcross in RN and I’m so happy with my choice.
Seriously, check it out and see if you can tell it’s a “hybrid” app: [App
Store]: [https://itunes.apple.com/in/app/falcross-logic-
puzzles/id500...](https://itunes.apple.com/in/app/falcross-logic-
puzzles/id500195713?mt=8) [Google Play]:
[https://play.google.com/store/apps/details?id=com.rawrmaan.f...](https://play.google.com/store/apps/details?id=com.rawrmaan.falcross&hl=en_US)

At 5k+ DAU I believe it is the largest production game written in RN.

There are more apps but I’m on mobile and it’s too hard to link them.

Major kudos to the RN team for all their hard work. RN makes me feel very
dangerous as a solo developer and honestly makes mobile development more fun
than I have ever imagined (especially paired with TypeScript). Thank you!

~~~
amake
I tried your game on my Pixel 2, and aside from the performance issues already
mentioned by other posters, there are very clear 1px misalignments (buttons
borders, screen edges) that make it fairly clear (imo) the app is not native.

~~~
rawrmaan
I don't have a lot of Android devices to test with, though it looks perfect on
the ones I have. I would love to see screenshots of the imperfections you're
talking about, it would be a huge help! If you see this, please send them to
rawrmaan [at] gmail [dot] com. Thank you!

------
com2kid
My largest issue with RN is that despite being "cross platform" there are
numerous times it is not, and the documentation may or may not reflect this.
From the image cache policy for remote objects not being obeyed on Android,
resulting in all images being cached all the time (open for multiple years,
never even acknowledged), to basic features like tiling an image just now
coming to Android. Heck even making something as simple as the keyboard not
occlude the field being typed into is not cross platform, with the docs just
saying that some props may work better than others on android versus iOS.

That and just how very fragile the entire JS eco-system is. Running NPM Update
ranges from doing not much at all, to breaking my entire system making
deleting all of node_modules the only realistic fix.

React Native is partially magic, and JSX is really nice to work with. But the
complicated things take minutes[0], and the simplest things take hours[1].

All that said, I'm still thankful to Facebook for putting out this project.
Even if it does behave... weird at times.

[0] Networking? Stupid easy. Even if my linter is unhappy about 'fetch' not
being declared anywhere. Great libraries mean things that are normally a
nightmare, like, authentication become really easy. And the community has a to
of tutorials.

[1] Want to make an image responsive? Or just learn how to render an image
properly at all? It is the opposite of intuitive. Also React-Navigation is
bad-but-getting-better to work with.

~~~
davidjnelson
> Running NPM Update ranges from doing not much at all, to breaking my entire
> system making deleting all of node_modules the only realistic fix.

Why not just pin your dependencies to specific versions, ie - “somepackage”:
“4.2.9” ?

~~~
Tehnix
Having to delete node_modules to “fix” it is indicative of a poor package
manager. Although not entirely the same, it reminds me of cabal hell, in
Haskell many years ago.

~~~
always_good
I've had to do that with every package manager though.

~~~
theWheez
After working with pip and gradle I have never encountered that issue

------
invaliduser
I have been working on a commercial RN project for 2 years now. As of today,
the project is ~50kloc, and provides builds for Android, IOS, Windows, and
Macos platforms. I started it using RN after prototyping with an early Ionic2
version and checking Xamarin.

The code share between IOS and Android is very high, almost 100% (except a few
simple home-made native components), and we are above the 85% of shared code
between the mobile and desktop versions (mobile is RN, desktop is react-
native-web + rewriting of several components on a Qt WebEngine with native
versions of a few RN components rewritten in C++). The C++ part is actually
very simple, and under 2Kloc. Note that we use Typescript everywhere on the
React side, and we consider it very valuable.

Overall, everything works great, we have a few performance issues here and
there, but nothing we can't deal with. However the biggest flaw is how
indigent the build system is (combining all the flaws of npm and the issues of
android upgrades), we still do not manage to have reproducible builds, and
it's been sometimes very painful to fix an issue a few weeks later because it
would just not build and require a few hours to make it build again.

~~~
mwilliaams
> all the flaws of npm

Can you not use yarn?

~~~
spinningarrow
What flaws of npm does yarn fix?

~~~
Humphrey
Oh my where do I begin -- Yarn (to me) appears to be faster, and breaks less
(if ever). With NPM I kept finding things not working, and having to delete
node_modules and re-installing. Yarn just works, and I haven't even considered
using NPM since installing yarn.

~~~
passivepinetree
Do you have any actual issues yarn solves for you besides an anecdotal “it
just works”?

~~~
Klathmon
I do.

It caches locally and doesn't hit the net for most redownloads, the lockfiles
are significantly more reliable, there's the ability to "force" a transitive
dependency to another version, the workspaces system lets you work with
monorepos with multiple packages much easier, tools like "upgrade-interactive"
are built in and make upgrades much easier, and more that i'm probably
missing.

------
Shinchy
So I just thought I would put my thoughts into this, I've been using React
Native to create a number of Apps for a very large company for a few years
now. These Apps are used out in the wild and I get to see them being used. As
a codebase I think it's great - a really nice way of working and creating
something. It's got great integration with tools and the general code setup is
really nice.

However; If I'm being honest I don't think I've ever seen a worse managed
project in my career. Each version that comes out seems to be completely
incompatible with the previous one. Getting the App to simply run can take far
longer than it takes to actually build the app. There is no locking of library
versions so things conflict constantly. Often times the team will update React
Native to use some new feature, this makes all backwards compatibility with
Xcode incompatible. I think I drew the line when the advice was, just update
your whole OS, download the latest Xcode, Yarn and then this latest version
will work.

To be frank, it's infuriating - and I know it's not yet 'officially' released
but if this is the state of how they plan to manage React Native in the
future, I can't see much hope in it. And that would be a shame, because as a
framework I think it's fantastic.

~~~
LeoNatan25
Indeed. The project has been in development for 5 years, but feels like it is
five months old. Full of bugs, every release breaks something major.

~~~
yeeeeeeeeee
You've got to give them credit though, it's pretty ambitious (and very useful
for some cases).

------
KenanSulayman
A few years back I was working with Titanium SDK to build apps in my spare
time; so it was a pretty obvious choice for me to checkout React Native. It's
pretty cool at first but once you dig a little bit deeper and try to tweak
things here and there, add extensions, third-party frameworks, ..., the pain
becomes very real.

In fact, I learned iOS app development using Swift & Xcode just to not work
with React Native anymore.

~~~
LeoNatan25
And I am sure your users appreciate it!

~~~
allover
Why? Do you think users would really notice the difference between React
Native and native?

~~~
mephitix
I think the commenter is saying something I've felt about cross plat for most
of the 10 years I've been working in it... ultimately the best user experience
is delivered by the native platform and tools.

Cross platform tools can get you really close but you'll be spending a non-
trivial of your time tinkering/tweaking shared code to fix or create different
issues on different platforms. That's time that takes away from creating a
great user experience on a single platform.

That's not to say Cross-platform tech is all bad. Just that you have to be
aware of the tradeoff that you won't be able to 'give it your all' towards
_the best_ user experience on a single platform.

PS - the one tech stack that gets you really close from all the ones I've
tried (Mono, C++, hybrid web apps, RN) is Unity. But that's for an entirely
different use case than apps :)

~~~
postfacto
The huge myth about cross-platform mobile development using web technologies
isnthat it gives you a faster time-to-market.

The reality I’ve seen, developing both hybrid and native, is that native has
the faster time-to-market because all of native stuff (debugger, GUI builder,
etc) works out of the box and all the time saved by a shared codebase is eaten
up with tweaking the shared code, having to do stupid JavaScript tricks, and
dealing with all the bullshit of the web that hybrid development brings into
your app.

------
warpech
My problem with React Native is lack of proper ES6 support on Android. The
issues are closed on GitHub instead of being addressed. See
[https://github.com/facebook/react-
native/issues/11232](https://github.com/facebook/react-native/issues/11232)

~~~
ljm
> No updates but if you'd like to help financially sponsor the work to get
> this done...

For a project coming from Facebook, this is a bit rich. It's basically saying
"you can pay us to build it for you," which isn't wrong, but it's not what you
expect from filing an issue on an open source project.

~~~
madeofpalk
What is very well known and understood with React Native is that Facebook has
surprisingly limited resources to work on it, so Facebook developers mainly
work on parts of React Native that Facebook uses. It's understood that if you
have a feature or use case that Facebook also doesn't have, you should be
prepared to contribute that yourself.

~~~
danabramov
It's not a case of limited resources. There's twice more people on React
Native team than people working on React itself, and that doesn't count all
the neighbor projects that RN relies on (Metro, Yoga). And still this isn't
enough.

At some point you can't "throw more people" onto the problem. Facebook can't
just add a few hundred developers to the RN team and expect them to
collaborate well. But that's more or less what you're asking about.

Realistically, several companies "scratching their own itches" as referred to
in a sibling comment reply tends to work better because it creates focus and
areas of responsibilities around real use cases.

------
valuearb
React Native is hot garbage. I work on a commercial project and it's
unbelievable that it can't even compile without hundreds of warnings. Talk
about low quality development work.

And every few weeks I shudder to pull a new version, knowing something will
have change that broke our builds.

Now let me tell you about debugging in poor network conditions. Ugh.

~~~
myguysi
That doesn’t seem to be something I’ve seen any of the core contributors
acknowledge and is often overlooked. As a relatively inexperienced developer
it seems like a bad thing on the face of it but the builds still succeed...
what’s the tradeoff?

~~~
valuearb
I'm actually a native developer. I'm responsible for a framework that supplies
the react app with features it can't implement on it's own (or can't implement
efficiently enough). So when I do builds, I need to know if I have any build
warnings in my code, but it's almost impossible to see mine in the mass of
React build warnings.

It also makes me wonder how compatible react apps will be, for example one
build warning about a deprecated iOS feature I inherited actually causes a
crash on iOS 12. We have over 400 warnings from the react code alone, how many
of those are future land-mines? Quality development dictates your builds have
few, if any, compiler warnings. Even if they are things you know will never be
a problem you fix them or adjust your warnings so they don't potentially
obscure other, more dangerous warnings.

That's a good rule for any professional development project, but when you are
developing a shared class library for other developers to build professional
products from, it's far more important. The React team's failure to clean
warnings makes me question their actual ability and commitment.

~~~
HectorRamos
If I recall correctly, many of these warnings come from the default settings
provided by the starter Xcode template. As we mostly integrate React Native
into existing projects here at Facebook, this is something that we're mostly
blind to.

As it happens, someone sent a PR the other day that fixed a bunch of these
warnings just in time for the new release candidate we just cut this week.
Please give 0.56.0-rc a try. If there's any warnings that still need to be
addressed, send a PR or open and issue and ping me. This is something we want
to actively clean up :)

------
spicyj
Hi! I'm the author. Let me know if you have questions that aren't covered in
the post.

~~~
mephitix
Hi - What's the latest philosophy/best practices on interop with React web?

Is the philosophy still 'learn once write everywhere'? There are so many
different approaches now to reuse React Native with React, like react-native-
web and react-native-dom, it's confusing.

Some of those solutions are non-starters for me since I started with a React
webapp and want to now have a React Native app that shares most of my existing
code.

My gut feeling is just stick with HOCs, SFCs, proper isolation of the views
and I'll be able to share the bulk of things like action creators, reducers,
etc. Is this reasonable? Are there other good practices?

~~~
spicyj
Your plan of sharing business logic sounds good. We don't currently have any
recommended way to share code between web and iOS/Android, although I'm
hopeful we will at some point in the future.

~~~
madeofpalk
I'm actually curious - how does the React (Native) team feel about such
efforts? Initially RN was pitched not for cross platform app development, but
" _learn_ once, write anywhere". I guess this is the reason why sharing more
code between RN and web hasn't been prioritised by the FB RN team, but do you
see your team wanting to encourage this?

------
akavel
Question to RN experts: does anyone of you know where in the RN codebase can I
find the exact code which generates the claimed _" single JSON message that
lists mutations to perform"_? I'm super interested in pinpointing it, but I'm
having serious trouble with that :(

(Cross-posted this question to:
[https://stackoverflow.com/q/50873408](https://stackoverflow.com/q/50873408))

------
tspike
Any plans to fix the hundreds of build warnings RN causes and the broken
configuration settings that make parallel builds impossible? Huge pain points
in our hybrid native/RN app.

------
vbezhenar
My dream is react native reimplementation (not just bindings but complete
rework) with Kotlin. It could compile to Android, iOS, Browser as a native
target without any need to bridge between JavaScript and native code, work
faster and having first class sane language. I think that only big corporation
could make it, Jetbrains, hear me :)

~~~
LeoNatan25
Why not check Xamarin? It’s already on a modern language (C#), great cross
platform capabilities (Xamarin Forms), but can also directly interop with
native APIs when needed (they are always needed).

~~~
tluyben2
I like Xamarin but I do not like the dev process yet for the frontend. I think
if that would be leaner (more Core2 and potentially command line and reloading
instead of recompile: only for dev ofcourse) it would be more popular. Now it
is a very heavy process; thats not because of c# or f#; they can both be very
dynamic. Not sure why not more work goes into making development smoother.

Having said that, I for one like working with Forms+renderers and a reactive
framework a lot more than RN. I can go for years and have my code work fine
after updates; I find npm such a nightmare and RN feels too driven (logically)
by FB needs.

------
zitterbewegung
This seems to dissuade some of the rumors on HN about React Native not being
supported by Facebook.

~~~
threeseed
Also Flutter is getting a lot of traction right now.

The development experience is incredible (probably why Facebook mentioned
instant reload), lots of companies are trying it out e.g. Evernote and the
community is buzzing with new plugins. Plus it doesn't wrap native components
so the core of it just works cross-platform.

~~~
woolvalley
I think the flutter approach is probably the better one, since the ux stack
has more control over how things are done.

Instead of being wrappers around complicated native UI libraries, it's a 'game
engine' over a lower level graphics layer. It's a smaller surface area to
screw up on and create abstraction leaks. You don't have to be a iOS/Android
and react native expert to fix hard issues, just a flutter expert for the most
part.

It's just too bad the language run time is dart and it's run by google, which
is infamous for being fairly ADD with projects.

~~~
Apocryphon
Flutter is at least open source, here's hoping that the dev community gets
organized enough to have the will to adapt annual iOS updates into the
Cupertino widgets once Google drops support for the project.

~~~
threeseed
1\. Apple doesn't refresh the UI components annually. In fact the last time it
happened was 3 years ago. Not to mention that the Cupertino widgets are very
limited in nature.

2\. This project definitely feels different compared to some of their others.
The experience is just so much better than writing iOS or Android code that I
think they would be insane not to support it.

~~~
Apocryphon
Maybe they don't do full-on refreshes a la iOS 7, but perhaps they tweak
little animation physics here and there. I'm thinking of this article's
critiques of Cupertino widgets feeling a bit off:

[https://harveynick.com/2018/05/21/an-ios-developers-
opinions...](https://harveynick.com/2018/05/21/an-ios-developers-opinions-of-
flutter/)

------
pier25
I'm curious if RN will go the way of Flutter and implement their own renderer
instead of giving commands to the OS for every little thing.

~~~
symlinkk
God, I hope not. They would have to re-implement every tiny little detail of
every button, textbox, and every other widget on each platform. Then they'd
have to keep it up to date every time the platform updates. That's just an
impossible task.

~~~
exacube
It's pretty possible, and has been for a while: 1) Flutter already implements
the Material spec and Cupertino spec, so the biggest cost, the upfront cost,
is satisfied. In fact, the Flutter team found inconsistencies with the
Cupertino spec vs. what iOS' animation kit implements and filed bugs for them.
2) It's OSS; this problem will minimize as more people are contributing and
using Flutter.

~~~
pjmlp
You mean just like people are contributing and using Ionic, Cordova, Qt,
Xamarin?

------
oculusthrift
Everyone’s “biggest problem with react native” seems to be different. Not sure
what that means but don’t think it’s a positive sign.

~~~
allover
I think sadly a lot of it is just FUD. Refer to the comments about npm I'm
addressing elsewhere in this thread. They're just ill-informed, or
deliberately throwing shade.

------
finchisko
One of my main issues (as RN plugin developer) is build system being so
fragile. Plugins are usually declaring different library versions. Same thing
with gradle versions itself. Currently RN is using gradle 2, but some plugins
started to use gradle3, which lead to even more incompatibilities.

I also have several suggestion for RN, but have bad experience with ignoring
my issues. React team recommends react-native.canny.io for feature request,
but those are pretty much ignored too (not seen official response to any of
those).

This is very frustrating as plugin developer who really want RN to progress
forward and works for free in my free time.

------
mychael
Its very unfortunate that that there is not built-in library for navigation in
RN or Expo. React Navigation is a capable tool, but the API is very awkward
and convoluted, even for doing very basic things like opening modals.

~~~
morenoh149
use this [https://reactnavigation.org/](https://reactnavigation.org/)

------
clarktank
I moved a way from react-native to flutter because developing react-native is
frustrating. Note: I love React and Redux but I HATE react-native!

a) Flutter's hot reload is a much better experience than react-native or Expo.

b) I am more confident with Flutter (React-native makes me feel incompetent
since I have no idea about native stuff). With Flutter, I feel that I am in
charge of my code, because dart compiles to native arm code.

c) I have OCD and don't like RN's console warnings when I am compiling the
code.

d) Flutter UI widgets are so consistent that I don't even bother testing on
both platforms. (one is enough)

e) I dislike RN's ecosystem. I don't even bother making canny request on
react-native's canny, due to lack of response. None of the most popular
planned FRs from last year are done yet ! [https://expo.canny.io/feature-
requests?sort=top](https://expo.canny.io/feature-requests?sort=top)

f) React-native's libraries are out of date.(I prefer corporate backing over
community support)

g) lack of response on stack overflow

If I wear react-native, I would take Flutter's approach instead of bridge.
Completely modernize JavaScript, get rid of its bad parts and compile it to
arm. SKIA is open source and if Dart can compile to it, so should JavaScript
with more tweaks of course.

------
apeace
I recently started building an app using Cordova. I chose Cordova because I'd
used it before and enjoy using VueJS (have used React and have no problems
with it, just really enjoy Vue).

What a mistake.

I run into problems with the build on a weekly basis. I generally have very
good debugging skills but in many cases could not figure out what was wrong.
Usually `cordova platform remove ios && cordova platform add ios` fixed it.
There is a ton of state in there and it's never been clear to me how to make
it reproducible from the configs.

Many plugins simply don't work as they are outdated and not compatible with
new iOS/Android versions. Using Firebase for notifications is one example.

Of course, I greatly appreciate the open-source authors who built all this and
I don't expect them to solve my problems for free. I'm just pointing out my
own mistake in choosing to use this tool, which doesn't solve as many problems
as I thought it did.

Can any developers here say whether they've had a smooth experience using
React Native? I'll definitely be trying it out soon...

~~~
solidr53
There is a small step to get all the build tools into your mindset, xcode and
gradle. For me the javascript side of things has been very stable.

I have built couple of native like applications with react native, and my only
recomendation is using native navigation, it is key.

[https://loremipsum.ueno.co/using-react-native-to-build-a-
pro...](https://loremipsum.ueno.co/using-react-native-to-build-a-professional-
consumer-apps-7c9c99cd0605)

------
harrisreynolds
Added React Native to our developer dashboard tool at Chart.ly.

Project is definitely healthy in terms of activity both in terms of commits
and contributors. Here is the dashboard:

[https://chart.ly/github-dashboard/facebook/react-
native](https://chart.ly/github-dashboard/facebook/react-native)

Would love some feedback on our dev dashboards if anyone here is interested!

~~~
rhizome
That looks like a great tool for micromanagers, and I'm not sure what other
uses those numbers could have.

~~~
harrisreynolds
Well... the streaks are intended to show consistency in progress of a project.
Great for anyone with a vested interest in the project.

Also great for just seeing activity in one place. GitHub's website is great,
but not really geared to providing much of this information in one place.

~~~
rhizome
I suppose, but maybe I'm inexperienced: in what context is "longest streak" a
useful number?

~~~
harrisreynolds
You are right about that one... more of a "glamour" metric than something very
useful (like when longest streak equals current streak which is the case for
our internal dashboard [1]). In this case you know you've been very consistent
over that time period. We will probably remove that one soon.

We do believe that at least with our product this kind of information it will
inspire more confidence in our users when we publicize this information more
(vs. lots of products that end up stagnating over time).

[1]
[https://www.dropbox.com/s/86jik7dvxwzdddd/Screenshot%202018-...](https://www.dropbox.com/s/86jik7dvxwzdddd/Screenshot%202018-06-15%2013.13.47.png?dl=0)

------
je42
how do people feel about that FB is not using the github build themselves ?

and the fact that the opensource build is RED for roughly a year now ?

------
rglover
Excellent news. I've had the opportunity to work with the framework while
mentoring a customer and the experience has been pretty enjoyable. Hopefully
these upcoming improvements will be backed by better documentation—that's the
only area that really felt lacking.

------
hiram112
Can someone tell me how React Native is actually working?

My initial guess is that it is basically running the same JS in a browser
wrapped into a native GUI widget (win32, X, Cocoa, etc).

Maybe I'm getting long in the years, but seems like we've played this game
many times.

~~~
75dvtwin
@hiram112. React native works in a 'conceptually' similar way as wxWidgets (if
you are familiar with with that). It uses platform's native APIs. It does not
rely on a web browser on your mobile device. The integration is also not just
for widgets, but underneath it abstracts out Image, network api, basic
storage/preference primitives, screen rotation, etc.

For the things that it does not abstract, it let's you write a native module,
that you register with RN runtime, and then the APIs for your native module
will be avialable to your RN java script code.

There is an active opensource ecosystem of RN-modules that you can leverage,
that will work on Android and IoS , abstracting the platform specific things
that RN does not do yet themselves. Everything from non trivial camera
interactions to bluetooth specific things. Eg

[https://github.com/Polidea/react-native-ble-
plx](https://github.com/Polidea/react-native-ble-plx)

------
je42
i also wonder about the 64 bit support on android ? if they are really
supporting it, i would expect more movement in that area...

------
je42
they also mention async rendering. cool. but they also did in ways that breaks
the Detox e2e testing framework ,if i am not mistaken, in a way that is
difficult to fix without proper support from RN code itself.

this kind of stuff is awkward. do something new cool, but break major
functionality for some users of RN.

~~~
rhizome
"Move at a medium pace and break things."

------
neals
I need to interact with a very specific SDK that Bluetooth stuff, is React the
going to be able to handle that?

~~~
reimertz
Sure you can.

Either you find an native module like this: [https://github.com/Polidea/react-
native-ble-plx](https://github.com/Polidea/react-native-ble-plx)

Or implement a Native Module yourself([https://facebook.github.io/react-
native/docs/native-modules-...](https://facebook.github.io/react-
native/docs/native-modules-ios.html)), then you can use any native frameworks
available.

------
75dvtwin
I have very positive experience with React native, and also with React Native
Web. Being able to share source of full pages/activities/forms across both
Mobile platform + Web browsers, while having Native look and feel -- is
incredible.

Very rewarding not just being able to use the same 'code base', but also
leverage same paradigms to manage UI Layouts between native and web (with
flux).

As a side note, I absolutely despair when I have to fall back to CSS or even
bootstrap.

Once I, finally, 'groked' flux -- it was huge productivity booster and I can
rely on that learn-once-use-in-many-places knowledge across not just my app,
but also when building small web-sites (in web tech only).

My approach for the app, is of a 'hybrid'. That is, my app starts out as
Native, and then, for some 'activities' (in Android-speak) -- I use react-
native.

I have implemented native modules to get access to platform specific elements
from React native code (eg networking apis, security, hardware device access,
device-preference/database stores) -- while basic forms/widgets and navigation
logic for some pieces are in React, leveraging React-native and react-native-
web underneath.

I think the UI paradigm introduced by React is a sweet spot for UI development
(concentrating on state as first-class-citizen).

I am hoping same paradigm (and similar abstractions) are adapted by MS
toolchain for desktop and console UI in .NET-based solutions.

Another side note (not RN specific) : C# is really a much better language than
JavaScript, but until browsers can supports C#-subset, JavaScript is the only
game in town for the 'modern' cross-platform dev efforts (eg. cross mobile,
desktop and web-browsers) ).

In terms of some challenges I have experienced with RN:

a) build system. Creating a release build is a major undertaking. As the
solution has to merge the 2 worlds: native and JavaScript-specific asset
management pipelines.

Error messages are obscure (eg I ran into issues, for example, where a path
for an Icon file was too deep, moving it to shorter path, solved that one).

Guides are for primitive (and non-hybrid) approaches.

b) Lack of standard (RN and RNWeb ) support navigation component.

c) Small things like: no Checkbox component for IoS..

d) Cross-platform app-store compatible icon management is not built in. I use
react-native-vector-icons -- so that solves that problem for me. But app-store
compliancy like this should, ideally be part of such platform.

e) As the article points out, the integration bridge between RN and native is
not efficient for 'constant interaction'. Because it requires you to serialize
data structures back and forth. So impossible to write 'hybrid' apps where
small parts are in RN -- instead it has to be 'bigger things' that would not
require too much back-and-forth.

f) the Debugging with Chrome over TCP bridge -- is basically a
horrible/slow/barely working. Navigations from one screen to another take like
2 seconds, while the debug mode. Because my components work on web browsers,
thanks to React-native-web - I end up, most of the time, debugging my RN logic
using React-native-web within browser debugging tools (rather than starting up
the native app and then spawning the debugger with Chrome bridge).

~~~
andrewmcwatters
> I am hoping same paradigm (and similar abstractions) are adapted by MS
> toolchain for desktop and console UI in .NET-based solutions.

You're at least a couple of decades late, there, and the other way around:
instead of `Winuser.h`, it's `react.js`.

~~~
75dvtwin
I do not think we had something similar prior to React Native.

I programmed MFC, Delphi, YACL (if folks remember..), wxWidgets, Borland OWL,
Dojo toolkits.

There was never a concept of State-as-first-class citizen for UIs.

And there as never a cohesive multi-screen layout engine story, like we have
now with flexbox (via RN and RNW).

So in my view, the data binding via explicit state-management paradigm that
React introduced -- will survive for decades, and will be copied to other
programming environments.

Same, probably for flexbox as a layout management model...

Although, there, I wish that it would be more 'typefull' where various
incompatible layouts could be flagged as errors or warnings at compile time.

Perhaps (and may be this is is far fetched) with the advancements in practical
category theory, compute power (including at compile time) -- we should be
able to do 'shape' management as algebraic concepts -- where layout engines,
should be able to treat layout definitions as composeable, multi-variable
functions.

WRT javascript vs C#, I was just noting, that, in my view C# is just a much
better language, and I wish it would have been a de-facto web-standard and not
javascript. This way something like React, would not have been conceived in
javascript.

------
ItsMe000001
Will React Native finally support exchanging BINARY data (ArrayBuffer,
TypedArray) across the bridge?

Thus far I have to send binary data as base64 encoded strings! See react-
native-fetch-blob for an example, when I read a file.

Current state:

Example, issue: [https://github.com/facebook/react-
native/issues/1424](https://github.com/facebook/react-native/issues/1424)
(closed but not solved, quote: "We are trying to keep issues focused on bugs
and this is more of a feature request")

Documentation for native modules, which kinds of data can be sent back to
Javascript: [https://facebook.github.io/react-native/docs/native-
modules-...](https://facebook.github.io/react-native/docs/native-modules-
ios.html#argument-types) (here the iOS docs, but it's the exact same for
Android/Java)

~~~
nikki93
I’ve managed to do this with direct access to the JSC C API — you could
probably write an interop w/ Obj-C / JNI.

~~~
ItsMe000001
Any pointers or code?

~~~
morenoh149
[http://devdocs.io/react_native/native-modules-
android](http://devdocs.io/react_native/native-modules-android)

[http://devdocs.io/react_native/native-modules-
ios](http://devdocs.io/react_native/native-modules-ios)

[http://devdocs.io/react_native/communication-
ios](http://devdocs.io/react_native/communication-ios)

~~~
ItsMe000001
That's the regular RN documentation - which is of ZERO help here. Please check
the topic of this sub-conversation - you missed it.

Hint: The parent mentions the "JSC C API". You point to Java and Objective-C -
that alone should give you a hint that something is wrong with your links,
that they don't quite fit into the conversation. That's the equivalent of a
physics question where you want Watts and get Newtons - a unit mismatch as an
indicator that you solved the wrong problem or the problem wrong.

And just to say that too, I'm the co-maintainer of a popular native package
for RN, so I'm already quite familiar with the RN native API for both Android
and iOS.

------
robotkdick
Facebook can make software great because they have great engineers, but
they've suffered a major case of scope creep, which leads to more than a few
loose ends as the company assigns their best engineers to [choose your own
adventure]:

\- maximum profits (woohoo!) \- reaction to potential regulation \- unwanted
press attention \- wanted press attention \- the shiny new thing

That's why I never switched to React. It's a good way to organize things and
was clearly well engineered from the start, but there are other choices
besides React (and RN) where leaders have demonstrated their willingness to
stick with it through thick and thin because...it's all they do.

~~~
spicyj
This is a pretty unrealistic view of how big companies work. Engineers aren't
fungible, and no one has been "pulled off" of React or React Native to
anything like you suggest.

React is my full time job (I was also the #1 committer before joining FB) and
no one is planning to abandon it. Even if Facebook company leadership decided
for some reason to divest, React would live on with the support of its
community similar to other projects without corporate backing.

~~~
robotkdick
While it may be your full-time job, you're still participating in a larger
mission, right?

Take the case of the legal problems with the React license that eventually
were ironed out or the privacy issues facing the company more recently.

Neither of those would have been a factor in your day to day life if React was
its own thing, right?

If no engineer has left the team, through their own will or through
enticement, you have my apologies.

I'm not arguing that you're not committed. I'm arguing that working for a
large company is a distraction, which is true of all large companies. Would
you agree that the licensing issue was unnecessary and distracting?

Don't get me wrong, I think you're doing great work and React isn't going
anywhere, but there's a broader mission there that is distracting from doing
that one thing. Do you ever wish it were it's own thing (if money weren't
involved)?

~~~
spicyj
Certainly there are downsides to any setup, but due to React Native's large
ambitions I'm unsure if it could have ever been created by an independent
community. There is a _lot_ of work that goes into it and the abundant
availability of complex real-world problems (to a greater extent than I've
seen anywhere else) spurred by this setup pushes React Native to be a more
capable project.

~~~
robotkdick
Thanks for the insight. I can tell from how you write about React, you're very
dedicated, and I feel your passion.

Upper-level managers at the large companies I've worked for universally saw
these types of projects as "cost centers" and tended to interfere in ways that
demonstrated a basic misunderstanding of the value. I hope that's not true in
your case.

